El testing ágil es la práctica de probar software de forma continua dentro de ciclos cortos de desarrollo, integrada al trabajo del equipo desde el primer día.
Cuando el tester llega al final, ya es tarde
Imagina que el equipo de Liverpool lanza una nueva función de pagos en su app. Los desarrolladores trabajan tres semanas, entregan el código y entonces le pasan todo al tester. El tester encuentra 40 bugs. Hay que reabrir tareas, reescribir código y retrasar el lanzamiento dos semanas más.
Eso es testing en cascada: lineal, tardío y costoso. En un equipo ágil, ese escenario no debería existir. El tester trabaja junto a los desarrolladores desde el inicio del sprint, no al final.
La diferencia no es solo de tiempo. Es de mentalidad y de proceso.
El Sistema SPRINT-QA: cómo encaja el tester en Scrum
Scrum divide el trabajo en sprints: ciclos de una a cuatro semanas donde el equipo construye, prueba y entrega una porción de software funcionando. El rol del tester dentro de este ciclo sigue un patrón claro que puedes aplicar en cualquier empresa.
Llámalo el Sistema SPRINT-QA. Tiene cuatro momentos clave:
- Refinamiento — antes del sprint
- Inicio del sprint — primeras horas
- Durante el sprint — días de trabajo activo
- Cierre del sprint — revisión y retrospectiva
Cada momento tiene una responsabilidad específica para el tester. Vamos uno por uno.
Momento 1: Refinamiento — el tester como detective
Antes de que el sprint comience, el equipo revisa las historias de usuario con el Product Owner. Una historia de usuario describe una funcionalidad desde la perspectiva del usuario final.
Ejemplo real: el equipo de FEMSA trabaja en su app de tiendas OXXO Pay. El Product Owner escribe esta historia:
"Como usuario, quiero pagar mi recibo de luz desde la app para no ir a la tienda."
En esta reunión, el tester hace preguntas incómodas pero necesarias:
- ¿Qué pasa si el pago falla a la mitad?
- ¿Cuál es el monto máximo permitido?
- ¿Qué sucede si el código de barras del recibo no es legible?
Estas preguntas generan los criterios de aceptación: las condiciones que la historia debe cumplir para considerarse terminada. Sin criterios claros, cada quien interpreta "listo" a su manera. Eso produce bugs.
Tu acción concreta: En cada refinamiento, escribe al menos tres preguntas de borde para cada historia. Usa el formato: "¿Qué pasa si...?"
Momento 2: Inicio del sprint — planear antes de codificar
El primer día del sprint, el equipo selecciona las historias que va a trabajar. Aquí el tester define su plan de pruebas ligero: una lista simple de escenarios que va a verificar.
No es un documento de 40 páginas. Es una tabla en Notion, Jira o incluso en papel con tres columnas:
| Escenario | Resultado esperado | Prioridad |
|---|---|---|
| Pago exitoso con tarjeta Visa | Confirmación en pantalla y SMS | Alta |
| Pago con saldo insuficiente | Mensaje de error claro | Alta |
| Timeout de red durante el pago | El cobro no se duplica | Alta |
| Pago con monto de $0 | Sistema rechaza la operación | Media |
Este plan es vivo. Se actualiza conforme el desarrollador avanza y aparecen nuevos casos.
Tu acción concreta: Al inicio de cada sprint, crea tu tabla de escenarios antes de que el primer ticket pase a "En progreso".
Momento 3: Durante el sprint — probar en paralelo, no al final
Aquí está la diferencia más grande entre testing ágil y testing tradicional. En Scrum, el tester no espera a que todo esté listo. Prueba cada historia en cuanto el desarrollador la termina.
En la práctica, esto significa:
- El desarrollador termina la función de "pago exitoso" el martes.
- El tester la prueba el miércoles.
- Si hay un bug, el desarrollador lo corrige el jueves, cuando el contexto todavía está fresco en su memoria.
Eso es muy diferente a encontrar el bug tres semanas después, cuando el desarrollador ya está trabajando en otra cosa.
Además, el tester colabora directamente con el desarrollador. Si una historia no tiene criterios claros, hablan. No abren tickets formales para preguntas simples. La comunicación directa reduce el tiempo de ciclo.
Ejemplo en Bimbo: El equipo digital de Bimbo desarrolla un portal de pedidos para distribuidores. Durante el sprint, el tester detecta que la función de "descuento por volumen" aplica mal cuando el pedido mezcla productos de diferentes categorías. El tester no abre un bug y espera. Va directo al desarrollador, explican juntos el criterio de aceptación y lo resuelven en el mismo día.
Tu acción concreta: Acuerda con tu equipo una regla simple: cualquier historia terminada debe ser probada en menos de 24 horas. Si no cabe en el sprint, no entra al sprint.
Los artefactos ágiles que el tester debe conocer
Scrum tiene tres artefactos principales. Todos afectan directamente el trabajo de QA.
El Product Backlog
Es la lista priorizada de todo lo que el producto necesita. La mantiene el Product Owner. Para el tester, el backlog es una fuente de contexto. Al revisarlo, entiendes qué funciones vienen después y puedes anticipar pruebas de integración.
El Sprint Backlog
Es el subconjunto de historias que el equipo se compromete a terminar en el sprint actual. El tester necesita este backlog actualizado todos los días. Si una historia cambia de alcance a mitad del sprint, los casos de prueba también cambian.
El Incremento
Es el resultado funcional del sprint: el software que realmente funciona y que el equipo puede mostrar. Para QA, el incremento solo es válido si todas las historias pasaron sus criterios de aceptación. Si una historia no tiene pruebas, no cuenta como terminada.
Momento 4: Cierre del sprint — retrospectiva como herramienta de mejora
Al final del sprint hay dos eventos importantes para el tester.
La Sprint Review es donde el equipo muestra el incremento al Product Owner y a los interesados. El tester puede participar aclarando qué se probó y qué quedó fuera del alcance.
La Retrospectiva es donde el equipo habla de cómo trabajó, no de qué construyó. Aquí el tester debe responder honestamente:
- ¿Encontramos bugs tarde porque los criterios eran ambiguos?
- ¿Alguna historia se cerró sin pruebas completas?
- ¿El tiempo de prueba fue suficiente o fue el primero en recortarse?
En equipos de Mercado Libre, las retrospectivas de QA suelen revelar un patrón común: las historias que más bugs generan son las que no tuvieron al tester en el refinamiento. Esa métrica sola justifica involucrar a QA desde el inicio.
Errores comunes del tester en equipos Scrum
Muchos testers llegan de ambientes de cascada y repiten los mismos errores dentro de Scrum.
Error 1: Esperar a que todo esté listo. Si esperas al último día del sprint para probar, siempre habrá bugs que no caben en el tiempo que queda. La solución es probar historia por historia, en cuanto están disponibles.
Error 2: No participar en el refinamiento. Las historias mal escritas generan bugs inevitables. Tu presencia en el refinamiento no es opcional: es donde más valor aportas con menor esfuerzo.
Error 3: Tratar los criterios de aceptación como sugerencias. Si el criterio dice que el sistema debe rechazar pagos mayores a $50,000 y no lo pruebas, firmaste un cheque que alguien más va a pagar después.
Error 4: No actualizar los casos de prueba cuando cambia el alcance. En Scrum el alcance cambia. Si tus casos no cambian con él, estás probando una versión antigua del producto.
El tester ágil no es un inspector de última hora
El tester ágil es el guardián de la calidad durante todo el sprint, no al final de él.
Eso cambia todo: cómo te relacionas con los desarrolladores, cómo lees las historias de usuario, cómo mides tu propio trabajo. En equipos como los de FEMSA o Mercado Libre, la calidad no es responsabilidad de una persona al final del proceso. Es una conversación continua que empieza en el refinamiento y termina en la retrospectiva.