Hubo una época en que el éxito de un equipo de QA se medía por la cantidad de test cases escritos. Si tu Excel tenía 300 filas, ibas bien. Si tenía 800, eras el rey del waterfall. Y sí, en el enfoque tradicional, predictivo, basado en proyectos tipo Waterfall, esa era la lógica: más documentación = más control = más seguridad.
Pero hoy el mundo del software se mueve a otra velocidad. Y con él, la forma de entender la calidad.
El modelo Waterfall y su obsesión con lo predecible
Waterfall funcionaba como una fábrica: había que definir todo antes de construir, luego ejecutar paso a paso. En ese mundo, la prueba era la etapa final del proceso. Y lo más importante era “cubrir todos los requerimientos con casos de prueba bien documentados”.
El problema es que ese modelo suponía que todo se puede predecir. Que el cliente sabe lo que quiere desde el inicio, que no habrá cambios, que no habrá errores de entendimiento, ni ideas nuevas a mitad del camino.
Spoiler: eso nunca ocurre.
Y en ese contexto, tener cientos de casos de prueba daba la ilusión de control. Pero lo que no detectaban era el valor real para el usuario, los errores conceptuales, las experiencias rotas o los riesgos ocultos.
Bienvenido a la agilidad con a sus zonas grises
Cuando trabajamos en entornos ágiles, el éxito no se mide por la cantidad de test cases, sino por la capacidad de adaptarse, de aprender rápido, de detectar riesgos antes de que duelan.
Los principios ágiles nos invitan a:
- Colaborar más que documentar exhaustivamente.
- Responder al cambio más que seguir un plan cerrado.
- Construir software funcional más que enfocarse en la burocracia del proceso.
Por eso, el QA moderno no es un escritor de casos de prueba. Es un estratega de calidad.
🧭 Escenarios, conversaciones, ejemplos: herramientas igual de valiosas que los test case
En agilidad, el conocimiento se construye en equipo. A veces un escenario hablado en una Daily tiene más valor que un test documentado que nadie lee. Una conversación con el PO puede prevenir bugs antes de que existan. Un ejemplo compartido en un refinamiento puede alinear mejor que cualquier documento.
Y es aquí donde entra algo que defiendo firmemente en Shift Left Testing en pocas páginas:
El trabajo de calidad es holístico, no secuencial.
Basado en el enfoque de Janet Gregory y Lisa Crispin, esto significa que el trabajo de QA debe integrarse en todo el proceso: desde las ideas iniciales, pasando por el diseño, el desarrollo, las pruebas y el feedback del usuario real.
No se trata de marcar pasos. Se trata de participar activamente en todas las conversaciones que definen el producto.
Entonces… ¿qué hacemos si no documentamos todo?
Primero: no se trata de eliminar los test cases. Se trata de entender su rol en un contexto más amplio.
- Los test cases ayudan a tener una base, una estructura.
- Pero no cubren exploración, pruebas heurísticas, conversaciones, hipótesis, riesgos no previstos.
Por eso, en agilidad, lo más importante no es todo lo que se prueba, sino cómo el equipo se prepara para lo que aún no se sabe que puede fallar.
🎯 El objetivo real: mitigar riesgos, no solo documentar pruebas
En entornos cambiantes, los riesgos evolucionan. Lo que ayer era prioritario, hoy no lo es. Por eso, tu estrategia de calidad no puede estar anclada a un archivo estático.
Lo que sí funciona es:
✅ Involucrarse desde el inicio para entender qué puede salir mal.
✅ Co-crear criterios de aceptación claros y validados por todos.
✅ Diseñar pruebas pensando en valor, no en cantidad.
✅ Tener feedback rápido del equipo y del usuario.
✅ Y lo más importante: tener un plan para mitigar riesgos en cada iteración.
El rol de QA (y de todos) en un equipo ágil
En agilidad, las responsabilidades se difuminan. El PO también piensa en calidad. El Dev también propone ideas para testear mejor. QA no es el “dueño” de la calidad, es un facilitador, un conector, un estratega.
Y esto es poderoso, porque te permite dejar de ser quien revisa errores… y convertirte en quien previene problemas, propone soluciones y eleva el nivel del equipo.
¿Qué puedes hacer ahora?
Te regalo esta guía rápida para usar en tu equipo:
[GUÍA DESCARGABLE] ¿Estamos listos para mitigar riesgos?
Rellena estas preguntas en tu próxima retrospectiva o planning:
- ¿Qué parte del producto tiene mayor incertidumbre?
- ¿Qué es lo peor que puede salir mal si esto falla?
- ¿Quiénes entienden bien esta funcionalidad? ¿Qué sabemos y qué asumimos?
- ¿Tenemos ejemplos concretos de uso real?
- ¿Cómo podemos descubrir fallos antes de que duelan?
- ¿Qué tan claros están los criterios de aceptación para este caso?
- ¿Qué haremos si esto rompe algo en producción?
Puedes adaptar esta guía como plantilla en Notion, Google Docs o Miro para tus sesiones de planificación de calidad.
Conclusión
No todo se prueba con casos de prueba.
Y eso está bien.
El éxito no está en tener 1000 pruebas documentadas, sino en tener la capacidad de adaptarse, de colaborar, de observar, de prevenir. De construir calidad como equipo. De entender que el QA no trabaja en soledad, sino que es parte esencial de una red de decisiones, riesgos, conversaciones y mejoras continuas.
Porque en la agilidad, el mejor test case… es el que nunca tuvo que ejecutarse gracias a que el equipo lo previó a tiempo.
