En muchos equipos que dicen trabajar con Scrum, el testing sigue siendo el último paso del sprint: desarrollo termina el último día y QA se queda con un montón de historias por probar. Eso no es agilidad, es una cascada en miniatura. Integrar QA en Scrum de verdad significa que la calidad se construye a lo largo de todo el sprint, no se inspecciona al final.
El rol de QA cuando Scrum no menciona a QA
Scrum no define un rol de tester como tal: el equipo es multidisciplinar y la calidad es responsabilidad de todos. Eso no significa que sobre la especialización. En la práctica, las personas de QA aportan el conocimiento técnico en pruebas, se aseguran de que los criterios de aceptación sean verificables y ayudan a que el equipo piense en riesgos desde el principio. Su trabajo se parece menos al de una aduana y más al de alguien que se sienta en la mesa mientras se diseña el trabajo.
QA en Scrum, ceremonia por ceremonia
Todo empieza en el refinamiento del backlog. Ahí es donde se puede evitar la mayor parte de los defectos: revisando que cada historia tenga criterios de aceptación claros y comprobables, preguntando por los casos límite y señalando dependencias o riesgos antes de comprometer trabajo. En la planificación del sprint, QA aporta estimaciones que incluyen el esfuerzo de pruebas, que casi siempre se subestima, y avisa si una historia necesita datos o entornos especiales.
Durante el sprint, lo ideal es probar las historias a medida que se terminan, en lugar de esperar al final, y colaborar con desarrollo en pruebas unitarias y de integración mientras se deja preparada la automatización en paralelo. En la revisión del sprint, QA ayuda a presentar lo construido y a validar con negocio que cumple lo acordado, y en la retrospectiva aporta datos, que es lo que la hace útil: bugs encontrados tarde, cuellos de botella, pruebas inestables.
La Definition of Done, tu mejor aliada
Una Definition of Done que incluya calidad evita muchísimas discusiones. Suele incluir que los criterios de aceptación estén verificados con pruebas, que las pruebas unitarias y de integración pasen, que no queden bugs críticos abiertos en la historia, que las pruebas automáticas relevantes se hayan añadido o actualizado y que el código se haya revisado. Con eso, "terminado" deja de ser una opinión.
Cómo probar sin frenar las entregas
Las historias pequeñas se prueban antes y reducen el cuello de botella final. Probar en paralelo al desarrollo, sin esperar al "terminado", es una de las claves, igual que automatizar la regresión para liberar tiempo y poder dedicarlo a lo nuevo. El pair testing, con desarrollo y QA revisando juntos, acorta ciclos, y tener entornos disponibles y estables evita una de las mayores pérdidas de tiempo que existen: esperar un entorno.
Los errores más repetidos son dejar a QA solo para el final del sprint, escribir criterios de aceptación ambiguos que nadie puede verificar, aplazar la automatización (la deuda de pruebas crece sprint a sprint) y ver a QA como un policía, cuando la calidad es del equipo. Y si siempre os quedáis sin tiempo para probar, revisa el tamaño de las historias, incorpora a QA desde el refinamiento y automatiza la regresión; casi siempre el problema está ahí.
Si quieres que tu equipo aprenda a integrar el testing en sus sprints, pide información en el formulario de contacto y te contamos cómo lo trabajamos.
¡Hasta la próxima!