El Framework Scrum: Perspectiva de QA
Scrum es el framework ágil más adoptado, utilizado por aproximadamente el 66% de los equipos ágiles a nivel mundial. Como ingeniero QA, casi con certeza trabajarás en un entorno Scrum en algún momento de tu carrera. Entender cómo el testing encaja en Scrum no es opcional — es esencial.
Esta lección cubre Scrum desde la perspectiva del tester: no solo qué es el framework, sino cómo contribuyes activamente en cada ceremonia y artefacto.
Roles de Scrum y QA
Scrum define tres roles. Entender cada uno te ayuda a saber con quién colaborar y cuándo.
Product Owner (PO)
El Product Owner gestiona el product backlog y prioriza el trabajo según el valor de negocio. Como ingeniero QA, trabajas estrechamente con el PO para:
- Clarificar criterios de aceptación de user stories
- Identificar casos límite que el PO puede no haber considerado
- Proporcionar evaluaciones de riesgo que influyan en la priorización
- Demostrar features probados durante el Sprint Review
Scrum Master (SM)
El Scrum Master facilita el proceso y elimina impedimentos. Desde la perspectiva de QA, el SM ayuda cuando:
- Los entornos de prueba no están disponibles o son inestables
- Las dependencias entre equipos bloquean el testing
- El equipo necesita mejorar las prácticas de testing (planteado en retrospectivas)
Development Team
En Scrum, el Development Team es multifuncional. Esto significa que los ingenieros QA son miembros plenos del Development Team, no un grupo separado. Compartes la responsabilidad de entregar un incremento terminado cada sprint.
Punto clave: En Scrum, no hay un “equipo de QA” separado. Los testers están integrados dentro del Development Team. Todo el equipo es responsable de la calidad.
Eventos de Scrum y Actividades de Testing
Scrum define cinco eventos. Los ingenieros QA participan en todos ellos.
Sprint Planning
Duración: Hasta 8 horas para un sprint de 4 semanas (proporcionalmente menos para sprints más cortos).
Actividades de QA durante Sprint Planning:
- Revisar user stories y criterios de aceptación
- Estimar el esfuerzo de testing para cada story
- Identificar dependencias de prueba (datos, entornos, servicios de terceros)
- Señalar stories de alto riesgo que puedan necesitar testing adicional
- Ayudar al equipo a determinar cuánto trabajo pueden comprometerse
Consejo de QA: Si los criterios de aceptación son vagos, haz preguntas durante el planning — no dos días antes de que termine el sprint.
Daily Standup
Duración: 15 minutos máximo.
Contribución de QA:
- Reportar qué stories estás probando actualmente
- Plantear bloqueantes (entorno caído, datos de prueba faltantes, requisitos poco claros)
- Comunicar qué stories pasaron o fallaron el testing
- Coordinar con desarrolladores sobre corrección de bugs
Anti-patrón a evitar: El standup no es un reporte de estado para el Scrum Master. Es una reunión de sincronización para el equipo. Habla con tus compañeros, no con el SM.
Sprint Review
Duración: Hasta 4 horas para un sprint de 4 semanas.
Actividades de QA:
- Demostrar features probados a stakeholders
- Presentar métricas de cobertura de pruebas e indicadores de calidad
- Destacar riesgos en features que no fueron completamente probados
- Recopilar feedback que pueda generar nuevos escenarios de prueba
Sprint Retrospective
Duración: Hasta 3 horas para un sprint de 4 semanas.
Temas de QA a plantear:
- Cuellos de botella de testing que ralentizaron el sprint
- Mejoras de calidad (oportunidades de automatización, estabilidad de entornos)
- Problemas de colaboración entre desarrolladores y testers
- Mejoras de proceso para el siguiente sprint
Testing a lo Largo del Sprint
Un concepto erróneo común es que el testing ocurre solo después de que el desarrollo está completo. En Scrum, el testing es una actividad continua:
Días 1-2: Escribir casos de prueba y preparar datos de prueba mientras los desarrolladores comienzan a codificar. Revisar criterios de aceptación con el PO.
Días 3-7: Probar stories a medida que se completan. No esperes a que todos los stories estén listos. Prueba cada uno cuando los desarrolladores lo marquen como listo.
Días 8-9: Ejecutar pruebas de regresión. Verificar correcciones de bugs. Realizar testing exploratorio en features integrados.
Día 10: Validación final, actualizar documentación de pruebas, prepararse para el Sprint Review.
La Definition of Done (DoD)
La Definition of Done es una checklist que todo product backlog item debe satisfacer antes de considerarse completo. Es acordada por todo el equipo y aplica a cada story.
Una DoD Sólida Incluye Criterios de Calidad
Aquí hay un ejemplo de DoD con elementos enfocados en calidad resaltados:
| Criterio | Categoría |
|---|---|
| Código escrito y revisado por pares | Desarrollo |
| Tests unitarios escritos y pasando (≥80% cobertura) | Calidad |
| Todos los criterios de aceptación verificados por QA | Calidad |
| Sin bugs críticos o de alta severidad abiertos | Calidad |
| Testing exploratorio realizado | Calidad |
| Tests de regresión pasando | Calidad |
| Feature desplegado en entorno de staging | Despliegue |
| Documentación actualizada | Documentación |
| Product Owner aceptó el story | Aceptación |
Por Qué la DoD Importa para QA
Sin una DoD clara, “terminado” significa cosas diferentes para diferentes personas. Un desarrollador podría considerar un story terminado cuando el código compila. Un PO podría considerarlo terminado cuando se ve bien en un demo. La DoD elimina esta ambigüedad.
Tu responsabilidad como QA: Aboga por criterios de calidad en la DoD. Si la DoD del equipo no incluye testing, está incompleta.
User Stories y Criterios de Aceptación
En Scrum, los requisitos se expresan como user stories con criterios de aceptación. Estos son la base de tus casos de prueba.
Formato de user story:
Como [rol de usuario],
Quiero [acción],
Para que [beneficio].
Ejemplo de criterios de aceptación:
Dado que estoy en la página de login
Cuando ingreso credenciales válidas
Entonces debo ser redirigido al dashboard
Y debo ver un mensaje de bienvenida con mi nombre
Mejora de QA: Para cada criterio de aceptación, piensa también en los casos negativos:
- ¿Qué sucede con credenciales inválidas?
- ¿Qué sucede con campos vacíos?
- ¿Qué sucede con caracteres especiales en el nombre de usuario?
Estos casos negativos deben convertirse en casos de prueba adicionales.
Artefactos de Scrum y QA
Product Backlog
La lista priorizada de todo lo que podría ser necesario en el producto. QA contribuye:
- Agregando stories relacionados con testing (ej: “Configurar infraestructura de testing de rendimiento”)
- Señalando deuda técnica relacionada con la testeabilidad
- Revisando stories próximos para planificar el enfoque de testing
Sprint Backlog
El conjunto de items seleccionados para el sprint actual más el plan para entregarlos. Las tareas de QA (escribir casos de prueba, ejecutar tests, automatizar escenarios) deben ser visibles en el sprint backlog.
Product Increment
La suma de todos los product backlog items completados al final de un sprint. Este incremento debe cumplir la Definition of Done y ser potencialmente entregable.
Ejercicio: Crear un Plan de Testing para un Sprint
Eres un ingeniero QA en un equipo Scrum. Tu equipo trabaja en sprints de 2 semanas. El Product Owner ha seleccionado los siguientes stories para el próximo sprint:
User Stories:
- US-101: Como usuario, quiero restablecer mi contraseña por email para poder recuperar el acceso a mi cuenta (8 story points)
- US-102: Como administrador, quiero exportar datos de usuarios como CSV para poder analizar patrones de uso (5 story points)
- US-103: Como usuario, quiero recibir notificaciones push para mensajes nuevos para mantenerme informado (13 story points)
- US-104: Como usuario, quiero filtrar resultados de búsqueda por rango de fechas para encontrar contenido relevante más rápido (3 story points)
Tu tarea:
Crea un plan de testing para el sprint que incluya:
- Enfoque de testing para cada story (qué tipos de testing realizarás)
- Dependencias y prerequisitos de prueba
- Cronograma de testing día a día durante los 10 días del sprint
- Evaluación de riesgos: qué stories tienen mayor riesgo y por qué
- Tu contribución a la Definition of Done
Pista
Considera estos factores para tu plan:
- Los story points indican complejidad relativa — US-103 (13 puntos) es el más complejo
- El restablecimiento de contraseña involucra testing de seguridad (no solo funcional)
- La exportación CSV necesita testing de validación de datos
- Las notificaciones push requieren testing en múltiples plataformas
- El filtro de fechas necesita testing de valores límite
Comienza identificando el story más riesgoso y asigna más tiempo de testing a él.
Solución de Ejemplo
Plan de Testing del Sprint
1. Enfoque de Testing por Story:
| Story | Tipos de Testing |
|---|---|
| US-101 (Restablecer Contraseña) | Funcional, seguridad, integración de email, testing negativo, cross-browser |
| US-102 (Exportar CSV) | Funcional, validación de datos, rendimiento (datasets grandes), verificación de formato |
| US-103 (Notificaciones Push) | Funcional, cross-platform (iOS/Android/Web), timing, escenarios offline |
| US-104 (Filtro de Fechas) | Funcional, valores límite, UI/UX, rendimiento con grandes conjuntos de resultados |
2. Dependencias:
- US-101: Configuración de servidor de email de prueba, cuentas de prueba con credenciales conocidas
- US-102: Dataset de muestra con 10K+ registros para testing de rendimiento
- US-103: Dispositivos de prueba (iOS y Android), credenciales del servicio de notificaciones push
- US-104: Base de datos con registros que abarquen varios rangos de fechas
3. Cronograma Día a Día:
| Día | Actividad |
|---|---|
| 1 | Escribir casos de prueba para US-104 (más simple, probablemente terminado primero) y US-101 |
| 2 | Escribir casos de prueba para US-102 y US-103. Preparar datos de prueba. |
| 3-4 | Probar US-104 (se espera dev-complete para día 3). Comenzar testing de US-101. |
| 5-6 | Completar testing de US-101. Comenzar testing de US-102. |
| 7-8 | Probar US-103 (complejo, se espera dev-complete para día 7). Testing cross-platform. |
| 9 | Testing de regresión. Verificación de bugs. Testing exploratorio en features integrados. |
| 10 | Validación final. Actualizar documentación de pruebas. Preparar demo de Sprint Review. |
4. Evaluación de Riesgos:
| Story | Nivel de Riesgo | Razón |
|---|---|---|
| US-103 | ALTO | Más complejo (13 pts), cross-platform, dependencia de servicio externo |
| US-101 | ALTO | Sensible a seguridad, fiabilidad de entrega de email |
| US-102 | MEDIO | Preocupaciones de precisión de datos con datasets grandes |
| US-104 | BAJO | Feature simple, alcance bien definido |
5. Contribución a la Definition of Done:
- Todos los criterios de aceptación verificados con casos de prueba pasando
- Testing negativo/casos límite completado para cada story
- Sin bugs críticos o de alta severidad abiertos
- Testing cross-browser realizado (US-101)
- Testing cross-platform realizado (US-103)
- Suite de regresión pasando
- Casos de prueba documentados y vinculados a stories
Anti-Patrones de Testing en Sprint
Saber qué no hacer es tan importante como saber qué hacer. Estos son los anti-patrones más comunes de testing en sprint:
1. La Mini-Cascada
Problema: Todo el desarrollo ocurre en la primera mitad del sprint, todo el testing en la segunda mitad. Esto crea un cuello de botella de testing y garantiza que los bugs se encuentren tarde.
Solución: Desarrolladores y testers trabajan en paralelo. Prueba stories a medida que se completan, no al final.
2. La Regresión Omitida
Problema: El equipo omite testing de regresión porque “solo cambiamos una cosa.” Ese cambio rompe tres features más.
Solución: Siempre ejecuta tests de regresión, incluso para cambios pequeños. Automatiza tests de regresión para hacer esto sencillo.
3. El Tester Invisible
Problema: QA no participa en Sprint Planning ni Retrospective. El testing se trata como algo secundario.
Solución: QA debe asistir y contribuir activamente en todos los eventos de Scrum. Si te excluyen, plántéalo como impedimento.
4. El “Terminado” que No Está Terminado
Problema: Los stories se marcan como “terminados” cuando el código está escrito, saltando el testing. QA encuentra bugs críticos en stories supuestamente terminados al final del sprint.
Solución: Haz cumplir la Definition of Done. Un story no está terminado hasta que todos los criterios del DoD, incluyendo testing, se cumplan.
5. El Sprint de Bugs
Problema: El equipo dedica un sprint entero a corregir bugs del sprint anterior en lugar de entregar nuevo valor.
Solución: Corrige bugs a medida que se encuentran, dentro del mismo sprint. Incluye tiempo de corrección de bugs en la planificación de capacidad del sprint.
Consejos Pro para QA en Scrum
Haz pair testing con desarrolladores. Cuando un desarrollador termina un feature, siéntense juntos 10 minutos. Te lo demuestran, tú haces preguntas. Esto detecta problemas obvios antes del testing formal.
Automatiza la Definition of Done. Si tu DoD requiere tests unitarios pasando y verificaciones de cobertura de código, automatiza estas verificaciones en el pipeline de CI. La DoD debe ser verificable, no aspiracional.
Rastrea la métrica de “defectos escapados”. Cuenta cuántos bugs se encuentran en producción versus en el sprint. Una tendencia decreciente significa que tu testing de sprint está mejorando.
Refina stories antes del sprint. Participa en sesiones de refinamiento del backlog. Cuanto más clarifiques requisitos antes del Sprint Planning, menos sorpresas durante el testing.
Construye una checklist de testing de sprint. Crea una checklist reutilizable para cada sprint: entorno de pruebas listo, datos de prueba preparados, suite de regresión actualizada. La consistencia previene descuidos.