¿Qué patrones de testing son posibles para evolucionar de una gestión clásica a Scrum?

Recordemos que los incrementos resultantes de un sprint solo están finalizados cuando cumplen con la definición de hecho (DoD), definición que incluye pasar todas las pruebas con éxito. Llegar a obtener incrementos con todo el testing realizado implica una gran madurez en Agilidad. Después de 50 años de ingeniería de software hemos llegado a la conclusión de que las pruebas son un buen lenguaje para especificar requisitos funcionales, y es por ello que los criterios de aceptación, que se traducen en pruebas, toman tanta importancia en las historias de usuario. La mejor solución hasta hoy en día para garantizar pruebas completas dentro de un sprint, son la integración continua y las pruebas automatizadas. Implementar esta solución, TDD (Test Driven Development) o BDD (Behavior Driven Development), tiene sus dificultades que requiere una madurez que no es fácil de alcanzar.

Recientemente fui co-trainer de Mike Beedle en uno de sus cursos y en este describió 6 patrones de pruebas, los 5 primeros con soluciones gradualmente más cercanas a las necesidades de Scrum.

1. Sprint de integración y estabilización: en esta solución se dedica un sprint entero a hacer el testing de varios sprints anteriores. Esta solución se parece a trabajar en cascada y por ello se le da los nombres de ScrumFall o WaterAgile. La desventaja es que el sprint de pruebas puede ser una auténtica bomba de relojería que puede destapar una avalancha de incidencias.
2. Un equipo de pruebas testea después de la planificación del siguiente sprint: de esta manera cada sprint tiene su fase de pruebas, pero tiene la desventaja de que las incidencias entran en sprints posteriores afectando a estos de manera imprevisible. Una avalancha de incidencias puede romper un sprint.
3. Un equipo de pruebas testea antes de la revisión del sprint: esta fase de test al final del sprint produce estrés adicional a la entrega y se produce un constante peloteo entre equipo de desarrollo y el de pruebas. El equipo de pruebas se queja de la mala calidad del equipo de desarrollo, y este, de que constantemente el equipo de pruebas está rompiéndoles con las incidencias su ritmo de trabajo, agravado por el sentimiento de que otro equipo está destapando los errores propios.
4. Build diario con un equipo de pruebas en otro turno horario: cada mañana el equipo se encuentra con las incidencias detectadas, tiene la desventaja de que el equipo se encuentra cada mañana con una pila de sprint cambiada y que también se produce algo de peloteo entre los dos equipos.
5. Build diario con un equipo de pruebas a última hora del día: tiene la ventaja de que se detectan las incidencias de forma muy rápida pero la desventaja de convertir los días del equipo de desarrollo en días muy largos, ya que seguramente poco antes de que tengan intención de irse a casa ya reciban incidencias del equipo de pruebas y se pongan a resolverlas.
6. Integración continua y pruebas automatizadas: se pueden realizar a petición docenas de pruebas automatizadas cada día. A petición, el sistema efectúa de forma automática el juego de pruebas completo y en cuestión de minutos el equipo de desarrollo tiene un reporte completo con las incidencias, pudiendo resolver estas en caliente con la mente aún inmersa en el código testeado.

En febrero asistí a un meetup en el que el Centro de Innovación del BBVA compartió sus experiencias con BDD y automatización de las pruebas. Allí vi de primera mano como una compañía había implementado integración continua y pruebas automatizadas.

Meetup "Cucumbeando, que es pepino" en el Centro de Innovación del BBVA

La herramienta que utilizan es Cucumber, un software de test que ejecuta las pruebas al estilo de BDD. La primera tarea de un desarrollador es escribir las pruebas en Gherkin, un lenguaje que usa Cucumber y se escribe desde el negocio, un lenguaje específico que permite describir el comportamiento del software sin detallar cómo se implementará ese comportamiento. Una vez escritas las pruebas el desarrollador empieza a codificar y cada vez que tiene una parte testeable lanza las pruebas automatizadas para probar su código. Cuando pasa todas las pruebas el sistema da garantías de un software sin incidencias, aunque no de que haga lo correcto.

Tengo la convicción de que dentro de 10-20 años todos trabajaremos con pruebas automatizadas y las personas solo efectuarán aquellas en que aporten valor como las pruebas funcionales complejas y las pruebas exploratorias. Muchas de las pruebas ejecutadas por personas serán para entonces prehistoria y anécdotas del pasado.