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?

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

  1. Pingback: Bitacoras.com

  2. Hola Javier!
    Suena controvertido… 🙂
    No hay receta mágica, pero automatizar pruebas suele ser una buena práctica, eso sí, no en modo «atracón». O empiezas desde el primer día poco a poco, o parar el mundo para tener el juego de tests tampoco es realista.
    Mi visión: empieza a meter tests en cada iteración, poco a poco, primero unos pocos, luego más, y en unos meses serán un buen número.
    Claro, la inversión en testing cambia si estás trabajando en proyectos o en producto. En nuestro caso (Plastic SCM), creamos una release cada día y cada release pasa por 24 horas de testing automático (paralelizadas en unas cuantas menos). Sin esos tests automáticos, las releases no tendrían sentido: ¿cómo sabes que son estables? No puedes saberlo.
    Para mi los tests automáticos son:
    * Claves para tener una solución de respaldo
    * Claves para aumentar la visibilidad (no es «estamos al 70%», es pasan tantos tests de nosecuantos)
    * Un requisito en modo ejecutable (la repanocha, vamos :P)
    Nosotros hacemos un test siempre que hay un bugfix, y cada nueva funcionalidad lleva siempre automated tests asociados.
    Eso sí, no paramos ahí, también hacemos exploratory testing.
    Os paso un link a nuestro ciclo:
    http://codicesoftware-es.blogspot.com.es/2012/08/ciclo-de-trabajo-de-codice-software-iii.html

  3. Hola a todos.
    Claro todas las empresas creen que automatizar sustituirá el trabajo del tester como tal, sin embargo en empresas que se trabaja sobre un mismo producto el cual se realizan mejoras, es considerable automatizar las opciones mas estables, entonces entramos en controversia, ya que que caso tendría automatizar pruebas para un fragmento de código que no fue modificado, sin embargo esto no es en todos los casos.
    En base a mi experiencia considero que las empresas que trabajan software a la medida que siempre están justos con tiempo, no da tiempo ni es viable la automatización, sin embargo en México es una cultura que aún no se comprende, y el cliente no pagará mas tiempo de desarrollo de pruebas automatizadas.
    Es mi vaga opinión, no se si este en lo correcto, si no es asi haganmelo saber, por favor.
    Gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba