Agile y Scrum para QA Engineers: Lo Que Realmente Necesitas Saber

En Waterfall, QA revisaba el trabajo terminado al final de un ciclo de varios meses. En Scrum, QA es parte del equipo que construye el producto, lo que cambia cuándo te involucras y de qué eres responsable. Los criterios de aceptación escritos por el Product Owner se convierten en tus casos de prueba; la planificación del sprint es donde detectas los requisitos poco claros antes de que empiece el desarrollo; y "hecho" significa que los tests están pasando en CI, no solo que el código fue mergeado.

Waterfall vs Agile: por qué importa

La forma antigua de construir software era Waterfall: primero los requisitos, luego el diseño, luego el desarrollo, luego QA, luego el release. Cada fase se completaba antes de que empezara la siguiente. QA ocurría al final, después de que todo estaba construido.

El problema: cuando QA encontraba un bug, llevaba meses ahí. Corregirlo significaba volver a revisar decisiones de arquitectura que nadie recordaba con claridad. Los releases eran riesgosos porque grandes lotes de cambios no testeados salían todos juntos.

Agile es la respuesta a eso. En lugar de un gran release después de meses de trabajo, construyes y lanzas en pequeños incrementos, típicamente ciclos de dos semanas. QA es parte de cada ciclo, no una fase posterior.

Esto cambia cómo se ve el trabajo de un ingeniero QA: pruebas funcionalidades a medida que se construyen, estás en las reuniones de planificación y tu feedback influye en las decisiones de diseño antes de que se escriba el código.

El framework de Scrum

Agile es un conjunto de valores y principios. Scrum es el framework específico que usa la mayoría de los equipos para implementarlo. Cuando alguien dice "trabajamos en Agile", casi siempre se refiere a Scrum.

Roles

Product Owner (PO)

Es dueño del backlog del producto: la lista priorizada de todo lo que el equipo va a construir. El PO decide qué se construye y en qué orden, en función del valor para el negocio. No es un rol técnico, pero necesita entender qué necesitan los usuarios y explicarlo con suficiente claridad para que los desarrolladores puedan construirlo.

Scrum Master

Facilita el proceso. Conduce las ceremonias, elimina bloqueos y protege al equipo de interrupciones externas. No es un gerente; no asigna trabajo. Es más un coach del proceso.

Equipo de desarrollo

Generalmente 5 a 9 personas: desarrolladores, ingenieros QA, a veces UX. Multifuncional: el equipo en conjunto es responsable de entregar software funcional.

En Scrum, QA es parte del equipo de desarrollo, no está separado de él. No eres "el departamento de QA revisando el trabajo de los desarrolladores." Eres un miembro del equipo con un conjunto de habilidades específico que contribuye a un objetivo compartido.

Artefactos

Product Backlog

La lista completa de funcionalidades, correcciones de bugs y trabajo técnico que el equipo podría hacer. El PO es dueño de ella y la prioriza. Los ítems en la parte superior son los más importantes y los más detallados. Los del fondo son vagos. Se refinarán cuando se acerquen a la parte superior.

Sprint Backlog

El subconjunto del product backlog que el equipo se compromete a completar en un sprint. Se crea durante la Planificación del Sprint.

Historia de usuario

El formato estándar para los ítems del backlog:

Como [tipo de usuario],
quiero [algún objetivo],
para que [alguna razón].

Ejemplo:

Como usuario registrado,
quiero filtrar ítems por estado,
para que pueda ver rápidamente solo los ítems en progreso.

Las historias de usuario describen la intención, no la implementación. Cómo construirlo es decisión del equipo.

Criterios de aceptación

Las condiciones específicas que una historia debe cumplir para considerarse hecha. Las escribe el PO, las valida QA.

Ejemplo:

Dado que estoy en la página de ítems
Cuando selecciono "En progreso" en el filtro de estado
Entonces solo se muestran los ítems con estado "En progreso"
Entonces los ítems con otros estados no son visibles
Entonces la selección del filtro persiste si recargo la página

Estos se convierten en tus casos de prueba. Cuando todos los criterios de aceptación pasan, la historia está hecha.

Definición de Hecho (DoD)

Un acuerdo del equipo sobre qué significa "hecho". Típicamente incluye: código escrito, código revisado, tests escritos, tests pasando, desplegado en staging, documentación actualizada.

La contribución de QA a la DoD suele ser: tests automatizados escritos y pasando en CI, testing exploratorio manual completado, sin bugs críticos o altos abiertos.

El ciclo del sprint

Un sprint es un período de tiempo fijo, generalmente dos semanas, en el que el equipo construye un conjunto de funcionalidades. El ciclo se repite.

Planificación del sprint (inicio del sprint)

El equipo selecciona ítems del product backlog para el sprint. Los ítems se descomponen en tareas, se estiman y se asignan.

Rol de QA en la Planificación del Sprint

• Hacer preguntas de clarificación sobre los criterios de aceptación
• Identificar escenarios de prueba que el PO no consideró
• Marcar ítems que no tienen suficiente detalle para testear (devolverlos a refinamiento)
• Estimar el esfuerzo de testing. Si una historia toma 3 días en desarrollarse, ¿cuánto tardará en testearse?

Standup diario (todos los días, ~15 minutos)

Tres preguntas por persona:

1. ¿Qué hice ayer?

2. ¿Qué voy a hacer hoy?

3. ¿Tengo algún bloqueo?

Breve, enfocado, sin resolución de problemas. Si algo necesita una discusión más profunda, ocurre después del standup con las personas relevantes.

Actualizaciones típicas de QA en el standup

"Ayer terminé de testear la funcionalidad de filtros, encontré un bug y lo registré. Hoy estoy testeando el formulario modal. Sin bloqueos." O bien: "Ayer estaba bloqueado porque el entorno de staging estaba caído. Hoy está de vuelta, continúo con los tests de carga. Sin bloqueos ahora."

Revisión del sprint (fin del sprint)

El equipo muestra el trabajo completado a los stakeholders: el PO, gerentes, a veces clientes. Solo se muestra el trabajo que cumple la Definición de Hecho.

Rol de QA en la Revisión del Sprint

Confirmar qué está hecho y qué no (lo parcialmente hecho no cuenta), mostrar los escenarios de testing junto a las funcionalidades cuando aplique, y señalar cualquier cosa que se completó con limitaciones conocidas.

Retrospectiva del sprint (fin del sprint)

El equipo reflexiona sobre el proceso, no sobre el producto. ¿Qué salió bien? ¿Qué no? ¿Qué cambiamos en el próximo sprint?

Tres categorías: Mantener (cosas que están funcionando bien), Detener (cosas que no están funcionando) y Empezar (cosas que deberíamos probar).

Aquí es donde QA suele plantear problemas de proceso: los tests corren muy lento en CI, los desarrolladores rompen el entorno de prueba sin avisar, las historias llegan al sprint sin criterios de aceptación.

Entre Planificación y Revisión: el sprint en sí

Un flujo típico de QA durante un sprint:

Días 1-2

Escribir casos de prueba basados en los criterios de aceptación de las historias que entran a desarrollo. Revisar con el desarrollador para que ambos estén de acuerdo en cómo se ve "hecho".

Días 3-8

Testear historias a medida que los desarrolladores las completan. Testing continuo, no en lote al final. Cuando una historia está lista, se testea. Los bugs se corrigen. Se vuelve a testear.

Día 9

Verificación de regresión. Asegurarse de que nada nuevo rompió funcionalidades existentes.

Día 10

Buffer para correcciones, testing exploratorio, preparación de la revisión del sprint.

Testear en paralelo con el desarrollo, no después, es la diferencia clave con Waterfall.

Ciclo de vida de un bug en Scrum

Cuando encuentras un bug:

1. Registrarlo con pasos claros para reproducir, comportamiento esperado vs. real, severidad

2. Vincularlo a la historia en la que se encontró

3. Discutir con el desarrollador. ¿Es un bug o una mala interpretación de los requisitos?

4. Priorizar con el PO. Los bugs críticos bloquean el sprint; los menores pueden ir al backlog

Niveles de severidad de bugs

• Crítico: bloquea funcionalidad principal, pérdida de datos, problema de seguridad. Corregir ahora.
• Alto: funcionalidad principal rota, sin solución alternativa. Corregir en este sprint.
• Medio: funcionalidad parcialmente rota o existe una solución alternativa. Corregir en el próximo sprint.
• Bajo: problema cosmético, inconveniente menor. Va al backlog.

Términos clave que escucharás en un equipo Scrum

| Término | Significado |

|---------|-------------|

| Refinamiento del backlog | Reunión periódica para revisar y detallar los ítems próximos del backlog |

| Velocidad | Cuántos puntos de historia completa un equipo por sprint en promedio |

| Puntos de historia | Medida relativa de esfuerzo (no horas). 1, 2, 3, 5, 8, 13. |

| Épica | Una funcionalidad grande dividida en múltiples historias |

| Spike | Tarea de investigación con tiempo limitado (investigación, prueba de concepto) |

| Deuda técnica | Trabajo diferido para mantener la velocidad, que eventualmente hay que afrontar |

| Bloqueo | Algo que impide el progreso, necesita atención inmediata |

| Límite de WIP | Número máximo de cosas en progreso al mismo tiempo (evita el cambio de contexto) |

Kanban: cuándo lo verás en lugar de Scrum

Algunos equipos usan Kanban en lugar de Scrum. La diferencia: sin sprints. El trabajo fluye de forma continua. Un tablero con columnas (Por hacer > En progreso > Testing > Hecho) rastrea el estado.

Rol de QA en Kanban: tomar historias de "En progreso" cuando los desarrolladores las marcan como listas, moverlas a "Testing" y moverlas a "Hecho" cuando pasan. Sin ceremonias, sin ciclos fijos. Es más adecuado para trabajo de mantenimiento y corrección de bugs que para desarrollo de nuevas funcionalidades.

Lo que los entrevistadores preguntan en realidad

Habla sobre en qué ceremonias participaste, cuál fue tu rol en cada una, y da un ejemplo concreto. "Era parte de un equipo con sprints de 2 semanas. Asistía a los standups diarios, testeaba las historias a medida que salían del desarrollo y participaba en las retrospectivas. En un sprint planteé el problema de que las historias llegaban sin criterios de aceptación y agregamos un paso de refinamiento que lo resolvió."

"Empiezo a escribir casos de prueba durante la Planificación del Sprint, antes de que empiece el desarrollo. Así, cuando una historia se marca como lista para testear, no estoy empezando de cero. También testeo las historias de forma individual a medida que se completan, no en lote al final."

"Un bug es un comportamiento que se aparta de los criterios de aceptación documentados. Un requisito faltante es un comportamiento que no está cubierto por ningún criterio de aceptación. La app funciona como se especificó, pero la especificación estaba incompleta. Los requisitos faltantes vuelven al PO; los bugs vuelven al desarrollador."