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)