La mayoría de los ingenieros QA aparecen a testear el día 9 de un sprint de dos semanas. Para entonces, el costo de cada requisito que se pasó por alto son dos días más de corrección y re-testing. El punto de mayor influencia de QA es el refinamiento del backlog, donde hacer preguntas sobre casos extremos antes de que empiece el desarrollo define qué construye el desarrollador, qué requisitos se escriben, y qué no se convertirá en un bug en producción.
QA no es una fase. Es una presencia.
La señal más clara de que un equipo entiende Agile es cómo responde esta pregunta: "¿Dónde encaja QA en nuestro sprint?" La respuesta incorrecta es "los últimos tres días." La correcta es "en todas partes."
Piensa en un sprint de dos semanas trabajando en un flujo de checkout para una app de e-commerce. El equipo está agregando un campo de código de descuento. En un equipo que lo hace mal, QA se entera el día 9 cuando el desarrollador marca el ticket como "listo para testing." Tres días para testear y corregir antes de que termine el sprint.
En un equipo que lo hace bien, QA se involucra cuando se crea el ticket. Antes de que se escriba una línea de código, el ingeniero QA revisó los criterios de aceptación y preguntó: ¿Qué pasa si el código expiró? ¿Qué pasa si el usuario aplica dos códigos? ¿Qué pasa si el descuento hace que el total sea negativo? Esas preguntas se responden antes de que empiece el desarrollo, lo que significa que el desarrollador sabe qué construir desde el principio. Cuando el ticket llega a testing el día 7, QA ya tiene los casos de prueba escritos. El testing toma horas, no días. Hay margen para corregir bugs.
Esto no es una mejora de proceso. Es el diseño original de Agile. El modelo de equipo multifuncional existe precisamente para que la experiencia de QA se aplique antes de que se escriba el código, no después.
Ceremonias del sprint: dónde ocurre realmente el trabajo de QA
Cada ceremonia de Scrum es una oportunidad. La mayoría de los ingenieros QA aprovecha solo algunas.
El refinamiento del backlog es donde QA tiene mayor influencia. Es la reunión donde los tickets próximos se detallan antes de que empiece el sprint: se escriben los criterios de aceptación, se discuten los casos extremos, se revisan los diseños. El trabajo de QA aquí es ser la persona que hace las preguntas que se convertirán en bugs si nadie las hace ahora.Imagina una sesión de refinamiento para una nueva página de perfil de usuario. Los criterios de aceptación dicen: "El usuario puede actualizar su nombre, email y foto de perfil." Un desarrollador lee esto y sabe qué construir. Un ingeniero QA lee esto y pregunta: ¿Cuáles son las reglas de validación para el campo de nombre? ¿Hay un límite de caracteres? ¿Qué formatos de archivo se aceptan para las fotos? ¿Cuál es el tamaño máximo de archivo? ¿Qué pasa si el usuario actualiza su email a uno que ya existe en el sistema? ¿Y si intenta subir un virus?
Ninguno de estos son casos extremos que el ingeniero QA inventó. Son requisitos que todavía no estaban escritos. Sácalos en el refinamiento y se convierten en criterios de aceptación. Sáltate el refinamiento y se convierten en bugs en producción.
La planificación del sprint es donde QA estima. No solo las estimaciones de desarrollo, sino las de testing. Una historia que tarda dos días en construirse puede tardar un día en testearse a fondo, o puede tardar cuatro. El trabajo de automatización es diferente del trabajo de testing manual. Si QA no habla en la planificación, el sprint se carga con trabajo de desarrollo que físicamente no puede testearse en el tiempo restante. Los standups diarios son donde QA comunica los bloqueos temprano. El peor patrón: un ingeniero QA bloqueado en silencio durante dos días porque el entorno de staging está roto, y lo menciona recién el día nueve. El standup existe para que esto salga a la luz el día uno. "Estoy bloqueado. Staging está devolviendo errores 500 en el servicio de pago, necesito que eso se corrija para continuar." El Scrum Master entonces se encarga de eliminar ese bloqueo. Si no comunicas los bloqueos en el standup, no estás usando la ceremonia correctamente. Las retrospectivas del sprint son donde QA mejora el proceso. No se queja de él: lo mejora. Hay una diferencia. "Las historias siempre llegan a testing sin suficiente detalle" es una queja. "Las historias siempre llegan a testing sin suficiente detalle; me gustaría proponer que requiramos una sección de notas de testing en cada ticket antes de que entre al sprint" es una contribución a la retrospectiva. Los ingenieros QA que usan bien las retros van dando forma gradualmente a cómo opera todo el equipo.Qué significa "hecho" desde la perspectiva de QA
La Definición de Hecho es un acuerdo del equipo sobre qué condiciones debe cumplir un ticket antes de cerrarse. La mayoría de los equipos tiene una. Muchos equipos dejan que QA defina su parte de forma deficiente.
Una Definición de Hecho de QA común dice: "Testing completado." Eso no es una definición. Es un gesto vago.
Una mejor Definición de Hecho de QA para un ticket de funcionalidad: tests de criterios de aceptación escritos y pasando en la suite de tests, testing exploratorio completado con notas de sesión registradas, sin bugs críticos o de severidad alta abiertos, escenarios de regresión verificados para funcionalidades adyacentes afectadas, y el ticket testeado en los entornos especificados en el acuerdo del sprint (staging, como mínimo).
La disciplina que esto genera es significativa. Cuando un desarrollador marca algo como "listo para QA," tienes una lista de verificación. Cuando cierras un ticket, puedes señalar exactamente qué se hizo. Cuando algo falla en producción, puedes rastrear qué parte de la DoD no se cumplió. Así el trabajo de QA se vuelve auditable en lugar de simplemente confiado.
Para los tickets de testing específicamente (los tickets donde QA escribe automatización, no testea una funcionalidad), la Definición de Hecho debería incluir: tests ejecutando en el pipeline de CI sin inestabilidad durante tres ejecuciones consecutivas, tests que cubren los escenarios documentados en el ticket, y PR revisado por otro QA o un desarrollador familiarizado con el framework de testing.
Un escenario de la práctica: un equipo tenía discusiones recurrentes sobre si un test automatizado cuenta como "hecho" si estaba escrito pero ejecutándose en un pipeline opcional que no bloqueaba los merges. Definir la DoD explícitamente resolvió esto. El test no estaba hecho hasta que estaba en el pipeline bloqueante. El equipo acordó. Las discusiones cesaron.
El antipatrón de "testear al final" y el shift-left
El testing shift-left significa mover las actividades de testing más temprano en el proceso de desarrollo. La frase se ha usado tanto que se ha vuelto insignificante en algunos equipos: un eslogan sin práctica. Esto es lo que realmente significa en el contexto de un sprint.
Un equipo que sigue el testing shift-left hace tres cosas de forma diferente. Primero, QA escribe escenarios de prueba a partir de los criterios de aceptación antes de que empiece el desarrollo. No para ejecutarlos de inmediato, sino para que el desarrollador pueda ver exactamente qué se va a validar. El desarrollador programa para que esos escenarios pasen. Esto elimina toda una clase de bugs: los que ocurren cuando el desarrollador malinterpretó cómo se ve "hecho."
Segundo, el testing ocurre en paralelo con el desarrollo. Cuando un desarrollador termina una sub-tarea de una historia, esa parte va a QA mientras el desarrollo continúa en la siguiente sub-tarea. Una funcionalidad de login puede tener: renderizado del formulario, lógica de validación, llamada a la API, redirección de éxito, estados de error. Testea el renderizado del formulario mientras se construye la lógica de validación. Para cuando el desarrollo esté completo, ya testeaste el 60% de la funcionalidad.
Tercero, QA participa en la revisión de código para las decisiones de cobertura de tests. No en la revisión línea por línea (ese es el dominio del desarrollador), sino en una revisión de: ¿este PR incluye tests? ¿Los tests cubren los criterios de aceptación? ¿Hay rutas que no están testeadas?
La preocupación que los ingenieros QA suelen plantear: "Si hago shift-left y testeo antes, termino testeando funcionalidades incompletas y re-testeando todo." Esto es legítimo si haces shift-left sin coordinarte con los desarrolladores. La solución son acuerdos explícitos de entrega. "Avísame cuando el flujo feliz esté funcionando. Voy a testear eso. Luego avísame cuando el manejo de errores esté listo. Voy a testear eso por separado." Las entregas pequeñas superan a una gran entrega al final.
Kanban vs Scrum: qué significa la diferencia para QA
La diferencia práctica entre Scrum y Kanban desde la perspectiva de QA se reduce a la cadencia y los límites de trabajo en progreso (WIP).
En Scrum, el trabajo llega en lotes definidos por la planificación del sprint. Tienes dos semanas y un conjunto definido de tickets. Hay ceremonias y momentos definidos donde el rol de QA es explícito.
En Kanban, el trabajo fluye de forma continua. No hay límite de sprint. Un desarrollador termina algo y lo mueve a la columna "Listo para QA." QA lo toma, lo testea y lo mueve a Hecho. Llega otro. Repetir.
Para los equipos de productos con muchas funcionalidades, Scrum le da a QA mejor anticipación. Puedes ver qué viene en el sprint y planificar la cobertura de tests antes de que lleguen los tickets. Para los equipos de soporte y mantenimiento (los que hacen correcciones de bugs, trabajo de infraestructura y pequeñas mejoras), Kanban suele funcionar mejor porque los sprints crean urgencia artificial que no se corresponde con el tipo de trabajo.
El riesgo de Kanban para QA es la carga invisible. En Scrum, si el sprint está sobrecargado, es visible en la planificación. En Kanban, QA puede convertirse silenciosamente en el cuello de botella: una pila de tickets acumulándose en "Listo para QA" que nadie nota hasta que el desarrollador empieza a preguntar por qué su funcionalidad no se lanzó todavía. Los límites de WIP existen para evitar esto. Si tu tablero Kanban no tiene límite en cuántos tickets pueden estar en Testing simultáneamente, eventualmente te convertirás en el cuello de botella.
Una regla práctica: establece tu límite de WIP de QA en dos tickets de testing activos. Tres si estás ejecutando automatización y testing manual simultáneamente. A partir de ahí, estás cambiando de contexto constantemente y frenando en lugar de acelerar.
QA en CI/CD: cuando no hay límites de sprint
Algunos equipos, especialmente los que tienen pipelines de CI/CD maduros, han disuelto efectivamente el sprint como límite de testing. El código se mergea diariamente. Los pipelines despliegan a staging automáticamente. Los releases van a producción según un calendario o de forma continua.
En estos entornos, el trabajo de QA ocurre en varios puntos simultáneamente.
A nivel del pull request, los tests automatizados se ejecutan antes de que el código se mergee. Los ingenieros QA son dueños de estas suites: definen qué se testea en el pipeline, gestionan los fallos de tests que bloquean los merges, y evalúan si un test que falla es una regresión real o un test roto. A escala, esto es trabajo a tiempo completo.
A nivel del despliegue en staging, una suite de regresión más amplia se ejecuta después de cada deploy. QA monitorea estas ejecuciones e investiga los fallos. La disciplina requerida aquí es la velocidad de triage: un pipeline de staging que falla necesita una decisión humana en minutos, no en horas, o la cola de despliegues se acumula.
A nivel de la funcionalidad, las nuevas funcionalidades siguen requiriendo testing exploratorio y validación de aceptación. En un equipo CI/CD, QA coordina directamente con los desarrolladores sobre el timing de los despliegues. "Despliega la funcionalidad X en staging antes del martes y la voy a tener validada antes de la ventana de release del miércoles."
El cambio en este modelo: QA ya no es principalmente un tester manual que escribe algo de automatización. QA es principalmente un ingeniero de automatización que hace validación manual para nuevas funcionalidades. Si apuntas a roles en empresas de productos modernas, esta es la dirección hacia la que se ha movido la industria desde 2022 y es el modelo operativo estándar en 2026.
Métricas que realmente dicen algo
La mayoría de las métricas de QA se reportan porque son fáciles de recolectar, no porque sean significativas. La tasa de tests pasando en aislamiento no dice nada. Si escribiste 50 tests que solo prueban el flujo feliz, una tasa de aprobación del 100% te dice que el flujo feliz funciona. No te dice si la funcionalidad es realmente confiable.
Métricas que vale la pena rastrear en un contexto de QA Agile:
La tasa de escape de defectos es el porcentaje de bugs encontrados en producción versus bugs encontrados antes de producción. Esta es la señal central de QA. Si aumenta sprint tras sprint, algo en tu proceso de testing se está degradando. Si disminuye, algo está mejorando. Calcula por sprint y evalúa la tendencia por trimestres. El tiempo de ciclo de testing es cuánto tiempo desde "listo para QA" hasta ticket cerrado. Esto te dice si el testing es el cuello de botella del sprint. Si el tiempo de ciclo promedio es tres días y tu sprint es de diez días, tienes un problema estructural. Si el tiempo de ciclo promedio es seis horas, tu proceso de testing es eficiente. El timing de descubrimiento de bugs es cuándo durante el sprint se están encontrando los bugs. Si la mayoría aparece en los días 9-10, el testing está siendo comprimido al final. Si los bugs están distribuidos a lo largo del sprint, el testing en paralelo está funcionando. Esta métrica requiere que registres la fecha de creación del bug, lo que la mayoría de los equipos hace automáticamente a través de su rastreador de issues. La tasa de tests inestables es el porcentaje de tus ejecuciones de CI con al menos un test que falla de forma intermitente sin que un cambio de código cause el fallo. Cualquier porcentaje por encima del 5% es una señal de que tu suite automatizada está dejando de ser confiable. Las suites no confiables se evitan. Las suites que se evitan no sirven para nada.Lo que no hay que sobreponderar: el conteo bruto de casos de prueba, el porcentaje de cobertura de tests sin contexto, y el conteo de bugs por sprint. Un ingeniero QA que escribe 200 casos de prueba superficiales parece más activo que uno que escribe 50 profundos. El porcentaje de cobertura depende enteramente de qué se está contando. El conteo de bugs por sprint varía con la complejidad de las funcionalidades, no con la efectividad de QA.
Cómo aplicar esto el lunes a la mañana
La brecha entre leer sobre QA Agile y practicarlo tiende a ser hábitos específicos. Estos cinco tienen el mayor impacto inmediato.
Antes de que empiece tu próximo sprint, lee cada ticket del backlog del siguiente sprint y escribe tres preguntas sobre cada uno. Lleva esas preguntas al refinamiento o agrégalas directamente en el ticket. Vas a encontrar criterios de aceptación faltantes todas las veces.
En tu próximo standup, si estás bloqueado o parcialmente bloqueado, dilo explícitamente. No "estoy trabajando en los tests de login." Di "estoy trabajando en los tests de login. Estoy esperando que el entorno de dev se redespliegue con la nueva configuración, esperado para esta tarde." La especificidad le permite actuar al Scrum Master.
En tu próxima retro del sprint, lleva un cambio de proceso propuesto. Formúlalo así: "Noté que X ocurrió tres veces en este sprint. Me gustaría probar Y por un sprint y ver si mejora." Las propuestas pequeñas y acotadas en el tiempo se adoptan. Las quejas vagas no.
Agrega un campo de notas de testing a tu próximo ticket antes de que un desarrollador empiece. Escribe dos oraciones: "Punto de entrada del test" y "Casos extremos conocidos a verificar." Esto toma tres minutos y elimina la mayor parte de la comunicación de ida y vuelta cuando el ticket llega a testing.
Si tu equipo tiene un pipeline de CI, mira las últimas 10 ejecuciones de tests e identifica cualquier test que haya fallado de forma intermitente. Regístralo como un ticket de test inestable. Los tests inestables son deuda técnica que erosiona la confianza del equipo en la automatización más rápido que casi cualquier otra cosa.
→ See also: Roadmap de Automatización QA 2026: Habilidades Esenciales para Conseguir Trabajo | CI/CD para QA: GitHub Actions, Jenkins y GitLab Comparados | Agile y Scrum para QA Engineers: Lo Que Realmente Necesitas Saber
