Test automatizados

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 viinvolucrado. 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 nuestraprofesió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 calidady 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énpuede 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 pasarimportantes 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 10personas 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 ydisparando 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íancambiado. 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 nose 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...