QA sin contexto: cuando probar se convierte en adivinar

Hay una frase que cualquier tester con experiencia ha escuchado alguna vez:

“Ya está listo para probar.”

Cinco palabras. Sin descripción, sin criterios de aceptación, sin indicación de qué usuario debe usar, qué rol tiene, qué URL debe visitar ni qué acciones debe realizar. Solo eso: está listo para probar.

Antes de hablar de lo que falla, vale la pena hablar de cómo debería funcionar.

Cómo trabaja QA cuando tiene lo que necesita

Cuando un tester recibe una tarea bien contextualizada, puede hacer su trabajo de verdad: ejecutar el happy path, explorar los sad paths, identificar edge cases, verificar restricciones por rol, y dejar constancia de qué se probó y bajo qué condiciones. Las pruebas se pueden repetir, trazar y comparar entre sprints.

Para llegar ahí no hace falta documentación exhaustiva ni casos de uso de treinta páginas. Hace falta lo mínimo con sentido:

1. Set de pruebas: URL del entorno, credenciales o indicación del rol del usuario con el que se debe probar.
2. Descripción funcional: qué debe hacer la funcionalidad y qué se espera como resultado.
3. Flujo principal: las acciones que el tester debe ejecutar y en qué orden, aunque sea de forma resumida.
4. Criterios de aceptación: al menos los más críticos. La formulación más útil es la más simple: “Si el usuario hace X, el sistema debe responder con Y.”
5. Condiciones: qué roles deben poder realizar la acción y cuáles no, en qué estado deben estar los usuarios y bajo qué condiciones se ejecuta la acción para que el resultado sea el esperado.
6. Cobertura: qué está fuera de alcance en esta iteración. Por ejemplo: no está traducido a todos los idiomas, no está implementado en determinados países, etc.

Con estos seis puntos, QA trabaja. Sin ellos, empieza la degradación.

La ambigüedad en la definición

La ambigüedad es el estado más común. Criterios de aceptación vagos, descripciones incompletas, flujos sin documentar. Es incómodo, pero gestionable: un tester con contexto de la aplicación puede inferir, puede preguntar de forma puntual, puede avanzar con suposiciones razonables. Los desarrolladores hacen lo mismo constantemente.

El problema es que trabajar así tiene un coste. Cada suposición es una fuente potencial de error:

• Falso negativo: El tester puede asumir un flujo incorrecto y no detectar un defecto real.
• Falso positivo: El tester puede reportar como bug algo que es comportamiento esperado.
• Cobertura limitada: Sin conocer los roles implicados o los casos límite, la cobertura se reduce al happy path más obvio.
• Pruebas no repetibles: Si el flujo se improvisa, otro tester —o el mismo en un sprint futuro— difícilmente puede replicar las pruebas.

La ambigüedad no impide trabajar, pero degrada la calidad de las pruebas de forma proporcional, y esa degradación raramente es visible hasta que algo falla en producción.

La ausencia de información

Imagina esta situación: una tarea llega a QA con el comentario “ya se puede probar”. El tester detecta que los criterios de aceptación son vagos o inexistentes, y dedica una o dos horas a rastrear comentarios, un hilo de correos y a ver la grabación de una reunión a la que nunca fue invitado, intentando consolidar algo parecido a una especificación que alguien creyó que carecía de importancia. Al final del proceso tiene más contexto, pero sigue faltando lo más básico: el flujo que debe seguir el usuario para llegar al punto exacto que hay que probar. Nadie lo ha escrito porque todo el mundo asume que el tester ya lo sabe. Y es exactamente ahí donde empiezan los problemas.

La ausencia de información es diferente a la ambigüedad. Cuando un tester no sabe cuál es la URL del entorno, qué rol tiene el usuario de prueba, qué acciones debe ejecutar ni en qué orden, o qué se espera que ocurra ni cuál es el trigger, no hay inferencia posible. No es ambigüedad: es un bloqueo.

Aquí es donde la situación deja de ser un problema de calidad para convertirse en un problema de responsabilidad. Si algo falla en producción y las pruebas no estaban respaldadas por criterios de aceptación claros, ¿quién valida que QA probó lo correcto? La ausencia de especificación convierte al tester en un adivino, y eso no es justo para nadie del equipo.

El coste de ahorrar tiempo en la especificación

Lo entiendo: los proyectos tienen fechas, los sprints son un compromiso, y cuando el calendario aprieta, dar contexto a QA parece lo primero que se puede eliminar, especialmente cuando el desarrollador afirma tener claro qué se pide implementar. Es tiempo que no se ve, que no aparece en ningún burndown, y que no duele de inmediato.

El problema es que la tarea de especificación no desaparece sin más: se convierte en deuda. Y cuando esa deuda se acumula, resurge en forma de incidencias en producción, regresiones inesperadas, búsqueda de culpables cuando lo que falla es el proceso, y —lo que más cuesta de recuperar— pérdida de confianza por parte de los usuarios.

Esta situación no es nueva en ingeniería de software. El coste de corregir un defecto crece exponencialmente cuanto más tarde se detecta. Lo que en desarrollo cuesta minutos, en producción puede costar horas o días, con el riesgo añadido de datos comprometidos o corruptos. Contextualizar a QA antes de empezar a probar no es burocracia: es prevención.

Una cuestión de cultura, no solo de proceso

Sería tentador reducir este problema a una cuestión de herramientas: una checklist antes de pasar una tarea a QA, una plantilla de criterios de aceptación, un campo obligatorio en el gestor de tareas… Todo eso ayuda. Pero el problema de fondo es cultural.

En los equipos donde QA funciona como un engranaje más del proceso, existe una comprensión compartida de que la calidad no es responsabilidad exclusiva del tester: forma parte del proceso. Cuando alguien entrega una tarea sin los mínimos necesarios, no está ahorrando tiempo: está trasladando el coste a otro actor del proceso, con intereses. Literalmente, está poniendo en riesgo la calidad del producto.

Los equipos que lo entienden tratan a QA como un colaborador desde el inicio, no como un filtro al final. La diferencia en la estabilidad de sus productos suele ser notable.

Probar software sin contexto no es hacer QA. Es hacer suposiciones. Y las suposiciones, en producción, tienen consecuencias reales: defectos, regresiones, usuarios insatisfechos, equipos desgastados y conflictos internos.

La solución no requiere grandes inversiones ni reorganizaciones profundas. Requiere algo más sencillo y más difícil a la vez: que todos los involucrados entiendan que la calidad no empieza cuando QA abre la tarea. Empieza cuando alguien decide que vale la pena especificar bien lo que se va a construir. Todo lo demás llega solo.