Acomodando o Forzando Scrum para Equipos de Testing

Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.

------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),

y la empresa “Y” lo prueba y certifica

Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

• un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
•  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –

dice: “yo voy a probar usando Scrum”

¡ ¡ ¡OMG!!!

Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:

• Planeación
• Ejecución
• Revisión
• y Retrospectiva

Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:

• El Product Backlog es todo lo que hay que probar
• Casos de uso
• Historias de usuario
• Requisitos no funcionales
• El sprint backlog
• Es lo que se selecciona a probar durante el ciclo
• El team es un equipo de testing
•  Product Owner y Scrum Master conservan sus definiciones.

Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características

• Todos los casos de prueba de la HU o del CU diseñados
• Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
• Reporte de incidencias encontradas actualizado.

Y la DEFINITION OF READY:

• Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
• Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:

• Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
• Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.

Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.

**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)