¿Cómo realizar testing a caballo entre gestión clásica y Scrum?

Un patrón de testing semi-ágil

En uno de los equipos que acompaño la especialista en pruebas, dependiente del departamento de testing de la compañía, aportó su experiencia para dar solución semi-ágil al testing en un equipo trabajando con Scrum en un entorno tradicional.

La idea es hacer las pruebas en dos momentos, pruebas de desarrollo durante el sprint y las pruebas de testing a lo largo del siguiente sprint mientras el equipo construye nuevas historias de usuario.

Las pruebas de desarrollo se realizarán al acabar cada una de las historias de usuario del sprint para asegurarnos de que todas las historias de usuario cumplen con los criterios de aceptación, y se hará una batida general al final del mismo. Estas pruebas no se recogerán ni documentarán en herramienta de pruebas alguna, quedan dentro de la "cocina" del equipo.

A lo largo del sprint se ejecutaran pruebas unitarias, funcionales y exploratorias en el entorno de desarrollo, y/o en algunos casos en alguna máquina local. Antes de la entrega de las historias de usuario, en la revisión de sprint, estas se subirán al entorno de test, recordemos que para entregar necesitaremos un entorno donde el Propietario del Producto y su equipo de negocio puedan recepcionar las historias de usuario y hacer sus pruebas de aceptación. En este momento se hará una nueva batida para asegurarnos de que también en test alcanzan los criterios de aceptación, se harán pruebas de integración y pruebas de humo para asegurarnos que todo encaja y para tener una revisión de sprint sin sorpresas.

Posteriormente a la revisión de sprint, y antes de las pruebas de aceptación de usuario y sin exceder para ambas el tiempo del sprint, se realizarán las pruebas de testing del sprint que acabamos de entregar. Estas serán pruebas más exhaustivas, más cercanas a lo que percibe el usuario, entre ellas las pruebas funcionales completas y las pruebas de regresión. Si los resultados de estas pruebas implican trabajo por parte del equipo, estas se agregan en forma de historias técnicas en la pila de producto.

También será el momento de realizar algunas pruebas no funcionales; de seguridad, de carga, de usabilidad, de rendimiento, de escalabilidad, de mantenibilidad, de portabilidad, de compatibilidad, de calidad... las que se consideren según las necesidades del proyecto.

Dada la característica semi-ágil de este patrón de pruebas es usual que las pruebas se registren en una herramienta de pruebas, como Testlink, y los posibles defectos descubiertos en un gestor de incidencias como Mantis.

La experiencia esta siendo positiva y está funcionando, pensemos que la transición hacia Agilidad puede ser un camino largo y lleno de piedras dependiendo del tamaño y de la cultura de compañía.

Mis agradecimientos a María Jesús, una Senior Software QA-Tester que compartió su experiencia con el equipo y conmigo :-)