Software Ágil: ¿Automatizamos las pruebas de regresión?

Trabajo en una aplicación en la que cada vez que mis usuarios piden un cambio, el costo de hacer el cambio es mucho menor que el costo de probar. La aplicación no tiene automatizada la prueba y no es modular.

Esta situación la he escuchado y vivido muchas veces en mi carrera. Ante esa situación, hay varias acciones posibles:

Tenemos que hacer de nuevo el sistema, y esta vez lo haremos bien.
Redefinamos el sistema para que sea más fácil probar.
Automaticemos la prueba.
Contratemos más testers.
Sigamos sin cambiar durante algún tiempo.

No puedo en este post analizar todas las alternativas, pero voy a seguir una linea de razonamiento posible, asumiendo algunas creencias, básicamente que las prácticas de desarrollo ágil me pueden ayudar en este caso (Más información sobre estrategias en Working Effectively with Legacy Code).

Entonces, la secuencia de pensamientos sería:

Me gustaría hacerlo bien, pero no puedo tirarlo y empezar de nuevo, el negocio debe seguir operando y la aplicación se debe seguir adaptando. Entonces, trabajaremos en hacerlo bien, pero en forma incremental.
Para redefinir el sistema sin romperlo, y dado que trabajaremos incrementalmente (muchos pequeños cambios) necesitamos pruebas automatizadas, al menos de nivel funcional. Esto permitirá que probemos a bajo costo cada versión del sistema con un nivel aceptable de calidad. No reemplazamos las pruebas manuales, pero al menos distribuimos las pruebas entre dos ciclos: uno automatizado, rápido y frecuente, otro manual, costoso y que corremos antes de liberar versiones.
Hacer bien la aplicación implica modularizar, tener pruebas automatizadas unitarias y calidad interna. Estas importantes ideas y prácticas no las estoy tratando en este post, pero suelen tener como precondición las pruebas funcionales automatizadas a las que me refierno en este post.

Vemos muchas equipos y empresas que siguen esta linea de pensamiento. Entonces el problema se puede reeplantear.

Quiero automatizar las pruebas de regresión, ¿cómo lo hago?

Quiero automatizar las pruebas de regresión, ¿cómo lo hago? ¿Qué herramientas uso? ¿lo hago con personas del equipo o contrato fuera? ¿cómo cambian los roles, que tenemos que aprender? ¿qué y cuánto tengo que probar para lograr confianza?

La respuesta a estas preguntas: Depende.

Bien, pero ¿de qué depende?

El equipo ¿tiene cultura de calidad?

Algunos miembros del equipo se ocupan de la calidad, dedican tiempo a pensar como probar y manejar los riesgos. Ya se hacen pruebas, y el problema es como automatizarlas.

¿Cómo es la estructura y cuales son los conocimiento del equipo?

La prueba manual la realiza un grupo externo, o los testers del equipo (hay personas cuyo puesto o posición es Tester), o las pruebas las realizan varias personas que cubren el rol de tester, pero también otros roles (analistas, programadores, diseñadores gráficos).

Los que cumplen rol de tester, ¿tienen conocimientos sobre programación o les interesa adquirirlos?
Funciona el equipo como un Whole Team en el que todos toman responsabilidad sobre el resultado conjunto y no sobre un subconjunto ("yo pruebo, no programo" o viceversa)

¿Cómo es la tecnológicamente la aplicación?

Para disminuir la curva de aprendizaje y mejorar la aceptación de las nuevas herramientas, es conveniente que la tecnología de la prueba automática sea cercana a la utilizada para la aplicación. ¿El equipo trabaja con .Net, Java, Ruby, Python?

Nuestra respuesta

Cada equipo debe explorar qué organización, herramientas y conocimientos les servirán para su caso.

Lo que encontramos desde Kleer (en este caso Nicolás Páez, Juan Gabardini, Carlos Peix), es que solemos repetir, al inicio de las consultoría de estos temas, una mínima nivelación de conocimientos y del abanico de posibilidades en cuanto a prácticas y herramientas, para facilitar a los equipos tomar decisiones. Pensamos que sería útil extraer esto en una serie de talleres cortos (medio día cada uno):