Automatizar las pruebas puede ser lo peor que hagas en tu vida. Te lo explico con una mala experiencia real

Nunca olvidaré el primer y mayor proyecto de automatización de pruebas en el que me vi involucrado. Ni el fracaso que supuso. En aquellos tiempos, trabajaba en una empresa de desarrollo software, perteneciente a un grupo empresarial bastante importante.
Como es típico en nuestra profesión, el desarrollo del producto estrella iba con retrasos y por temas comerciales tenía que salir a producción si o si en la fecha prevista.
Viendo las fechas, y los más que visibles problemas de calidad y fiabilidad provocados por el “desarrolla como puedas”, a uno de los responsables se le ocurrió una maravillosa idea: pongámonos ya a automatizar todas las pruebas. Automatizar las pruebas… ¿A quién puede no gustarle la idea? Tener un botón que al pulsarlo, automáticamente, sin personas, se pruebe toda la aplicación. Eliminar a testers que consumen horas, dinero, espacio y se dejan pasar importantes pruebas. Así empezó todo.

Cuando faltaban unos seis meses para el paso a producción, se pidió un prototipo de la aplicación a desarrollo, se compró una herramienta y se contrató un equipo de 10 personas que empezaron a destajo a crear scripts de pruebas funcionales.
Y aquel proyecto de automatización de pruebas acabó hundiendo la ya resentida productividad del equipo de desarrollo y disparando los costes del desarrollo.
Hundió la productividad porque el equipo de testing empezó a mandar masivamente incidencias a desarrollo… de funcionalidades que unas veces no existían y otras habían cambiado. Como el control de versiones y la gestión de configuración software no funcionaban, y cada equipo trabajaba con una versión diferente, las incidencias detectadas en la versión de testing no se encontraban en la versión de desarrollo y al pasar los test automatizados a la versión de desarrollo la mitad no funcionaban. Con lo que los dos equipos acababan como locos intentando detectar que fallaba, si el test o la aplicación.
Y no fue hasta los últimos meses cuando los responsables se empezaron a dar cuenta que ahora tenían dos problemas, dos códigos a gestionar, uno el propio desarrollo, y el otro el voluminoso código generado para automatizar pruebas, que generaba sus propias incidencias (test que no funcionaban), sus propios problemas de versionado y demás.
.
.
Constantemente escucho a responsables de proyecto que en un momento de desesperación, bien por problemas de fiabilidad o por los costes que conlleva el testing, piensan que automatizar las pruebas sería la solución a sus problemas. Antes de meterte en un problema mayor, piensa detenidamente las consecuencias y:
– Sanea primero tu proceso de testing manual, teniendo claro cuáles son los casos de prueba, y cuales son más estables e importantes, para determinar el subconjunto de casos que es rentable automatizar.  Y sanea antes procesos básicos como el control de versiones.
– Recuerda que automatizar es generar código, otro código, que igualmente tiene los problemas y necesidades de cualquier código.
– Se consciente de que nunca puedes automatizar 100%, y que es imposible asegurar que una aplicación software no va a fallar. Busca ese 20% de automatización que te da el 80% de beneficios.
– Aún así, en cualquier automatización de este tipo, siempre necesitarás personas, no sólo para mantener la automatización, sino también para detectarlos casos de prueba críticos, elegir los valores de entrada más determinantes, etc.
Algunas experiencia similar?