Scrum fue una de las cosas que más me sorprendió cuando empecé a formarme en QA. Venía de un mundo completamente diferente y la forma en que los equipos organizan el trabajo en sprints, con ceremonias y roles definidos, me pareció muy eficiente desde el principio.
En este artículo te explico cómo encaja el QA Engineer en un equipo Scrum y qué se espera de ti en cada fase del proceso.
Qué es Scrum y por qué importa para un QA
Scrum es un framework de trabajo ágil que organiza el desarrollo de software en ciclos cortos llamados sprints, normalmente de dos semanas. En cada sprint el equipo planifica, desarrolla, testea y entrega un incremento de producto funcional.
Para un QA Engineer, trabajar en Scrum significa que no hay una fase de testing separada al final. El testing ocurre dentro de cada sprint, en paralelo al desarrollo. Eso cambia completamente la forma de trabajar.
Los roles en Scrum y el lugar del QA
En Scrum hay tres roles principales: el Product Owner, el Scrum Master y el Development Team. El QA Engineer forma parte del Development Team junto con los desarrolladores y otros perfiles técnicos.
No es un departamento separado que recibe el producto cuando ya está terminado. Es parte del equipo que lo construye, y su responsabilidad es garantizar la calidad durante todo el proceso, no solo al final.
Las ceremonias de Scrum y el papel del QA en cada una
Sprint Planning
Al inicio de cada sprint el equipo se reúne para planificar qué se va a desarrollar en las próximas dos semanas. El QA Engineer participa activamente en esta reunión.
Su rol aquí es revisar las historias de usuario que entran al sprint y hacer preguntas que el equipo quizás no ha considerado: ¿qué pasa si el usuario no rellena este campo? ¿Cómo se comporta el sistema si la conexión falla a mitad del proceso? ¿Cuál es el comportamiento esperado en este caso de borde?
Detectar estas ambigüedades antes de que empiece el desarrollo es mucho más barato que encontrar el bug después.
Daily Standup
La reunión diaria de 15 minutos donde cada miembro del equipo comparte qué hizo ayer, qué va a hacer hoy y si tiene algún bloqueo.
El QA comparte el estado de las pruebas: qué está testeando, qué bugs ha encontrado y si necesita algo del equipo para continuar. Es una forma de mantener al equipo informado y de desbloquear problemas rápidamente.
Sprint Review
Al final del sprint el equipo presenta el incremento desarrollado a los stakeholders. El QA Engineer ha validado que todo lo que se presenta funciona correctamente y cumple los criterios de aceptación definidos al principio.
Sprint Retrospectiva
La retrospectiva es la reunión donde el equipo reflexiona sobre cómo ha ido el sprint: qué ha funcionado bien, qué ha ido mal y qué se puede mejorar.
El QA tiene mucho que aportar aquí: si han aparecido muchos bugs en una área concreta, si el proceso de testing ha tenido cuellos de botella, si los criterios de aceptación eran suficientemente claros. Esta información es valiosa para mejorar la calidad del proceso en el siguiente sprint.
Qué es la Definition of Done y por qué es clave para el QA
La Definition of Done es una lista de criterios que debe cumplir una historia de usuario para considerarse terminada. Es uno de los conceptos más importantes de Scrum para un QA Engineer.
Una buena Definition of Done incluye criterios de testing: los casos de prueba han sido ejecutados, los bugs críticos han sido resueltos, los tests automatizados están pasando en CI/CD. Sin estos criterios, el equipo puede dar por terminado algo que en realidad no está suficientemente probado.
El QA Engineer es quien normalmente define y defiende estos criterios dentro del equipo.
Cómo se organizan las pruebas dentro de un sprint
En un sprint de dos semanas, el trabajo de testing se organiza aproximadamente así:
Los primeros días el QA prepara los casos de prueba basándose en las historias de usuario del sprint, mientras los desarrolladores empiezan a codificar.
A partir de la primera semana, cuando los desarrolladores empiezan a entregar funcionalidades, el QA comienza a ejecutar los tests y reportar bugs.
Los bugs encontrados se añaden al backlog y el equipo decide cuáles se corrigen dentro del sprint y cuáles se dejan para después según su severidad.
Al final del sprint, el QA valida que todo lo desarrollado cumple los criterios de aceptación y está listo para la Sprint Review.
Herramientas que se usan en equipos Scrum
En un equipo Scrum real, el QA Engineer trabaja habitualmente con estas herramientas.
Jira para gestionar las historias de usuario, reportar bugs y hacer seguimiento del trabajo del sprint.
Confluence para documentar los casos de prueba, los planes de testing y las retrospectivas.
Playwright o Selenium para la automatización de pruebas E2E que se ejecutan en cada sprint.
GitHub Actions para la integración continua, ejecutando los tests automáticamente en cada pull request.
Postman para el testing de APIs durante el desarrollo.
Lo que más valoran los equipos ágiles en un QA
Trabajar en Scrum requiere un perfil de QA proactivo y comunicativo. No es suficiente con ejecutar casos de prueba — hay que participar activamente en las ceremonias, anticipar problemas antes de que ocurran y colaborar estrechamente con los desarrolladores.
Las empresas que trabajan con Scrum buscan QA Engineers que entiendan el proceso ágil, que sepan priorizar según el riesgo y que puedan adaptarse a los cambios rápidos que son habituales en los sprints.
Si quieres saber más sobre cómo encaja el QA en una empresa o startup, puedes leer cuándo necesita tu startup un QA Tester o qué esperar al contratar un QA Tester freelance en España.
Y si necesitas ayuda para implementar un proceso de QA en tu equipo ágil, puedes ver mis servicios en fatimaqa.com.