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)