QA no Tiene un Problema de Calidad:
Tiene un Problema de Historias que Nunca Estuvieron Listas

1. El Patrón que se Repite en Distintos Equipos

En los últimos meses estuve conversando muy de cerca con distintos equipos y proyectos, y me encontré con el mismo patrón una y otra vez: historias ambiguas o poco claras, requisitos que cambian mientras se está probando, sprints con 65 historias o más, sin priorización visible, sin un backlog realmente refinado, con dependencias en historias que todavía están "Por hacer".

Cuando eso pasa de forma constante, QA termina absorbiendo parte de la incertidumbre que el proceso dejó sin resolver. En vez de concentrarse en validar calidad, el equipo empieza a interpretar qué se quiso construir, a descubrir reglas de negocio en pleno testing, y a perseguir definiciones que debieron estar claras antes de que la historia entrara al Sprint.

Dicho esto, QA tampoco es un espectador pasivo de este problema. Somos, muchas veces, los primeros en detectar que algo en el proceso no está funcionando — y eso nos pone en posición de ser agentes de cambio: proponer un Definition of Ready, empujar el refinamiento continuo, nombrar la ambigüedad antes de que llegue a testing. Pero esa iniciativa tiene un límite claro: depende de que los líderes del equipo — PO, Scrum Master, liderazgo de ingeniería — escuchen esas señales y respalden el cambio con decisiones reales, no solo con buena voluntad. Un QA puede insistir con las mismas tres preguntas Sprint tras Sprint, pero si nadie con autoridad sobre el backlog o la prioridad del equipo decide sostener ese hábito, el patrón vuelve.

2. Un Ejemplo Típico: la Historia que Parecía "Ready"

La historia dice: "Como usuario quiero exportar mi reporte." Tiene story points, tiene un responsable de desarrollo asignado, y en el tablero figura como "Ready" para entrar al Sprint. Nadie mintió al moverla ahí — simplemente nadie se hizo las preguntas incómodas antes.

Nada de esto aparece como bloqueante en el Planning. Aparece en testing, cuando QA ya tiene la build en la mano y el Sprint está a mitad de camino. En ese momento, QA deja de hacer QA y empieza a hacer arqueología de producto: pregunta al PO, pregunta a desarrollo, revisa tickets viejos buscando una decisión que nunca se tomó por escrito.

3. No es un Problema de QA: 5 Causas Detrás del Síntoma

Cuando este patrón se repite Sprint tras Sprint, casi siempre hay una combinación de estos cinco factores. Ninguno es exclusivo de un rol — por eso la conversación no debería apuntar a culpar a PO, a Dev o a QA, sino a mirar el proceso completo.

4. El Costo de Descubrir la Ambigüedad Tarde

Es un principio ampliamente aceptado en desarrollo de software: mientras más tarde se descubre una ambigüedad o un defecto en el ciclo de entrega, más caro resulta resolverlo. Una pregunta sin responder en refinamiento cuesta una conversación de cinco minutos. La misma pregunta sin responder, descubierta en testing con la build ya construida, cuesta una vuelta completa: QA reporta, desarrollo reinterpreta, se vuelve a construir, se vuelve a probar — y en el medio, el Sprint pierde días que no vuelven.

El punto no es "QA debería trabajar más rápido". Es que la misma pregunta, hecha una etapa antes, es gratis en comparación con lo que cuesta hoy. Correr la detección de la ambigüedad hacia la izquierda del ciclo — hacia el refinamiento, no hacia testing — es la palanca más barata que tiene un equipo para recuperar días de Sprint.

5. Solución de Corto Plazo: 3 Preguntas Antes de Aceptar una Historia

La solución de fondo — backlog ordenado, Definition of Ready respetado, refinamiento constante — toma tiempo y necesita acuerdo del equipo completo. Pero hay algo que QA puede empezar a aplicar en el próximo refinamiento, sin esperar que cambie el proceso completo y sin pedirle permiso a nadie:

1. ¿Qué pasa si el usuario hace algo inesperado?
   (input vacío, doble click, conexión caída, permiso incorrecto)

2. ¿Esta historia depende de otra que todavía está "Por hacer"?
   (endpoint, feature flag, dato, servicio de otro equipo)

3. ¿Cómo vamos a saber que esto está "hecho"?
   (criterio de aceptación verificable, no una frase genérica)

Si nadie en la mesa puede responder las tres → la historia
no está lista, sin importar qué diga el tablero.

No hace falta un proceso nuevo, ni una herramienta nueva, ni convencer a nadie de adoptar un framework distinto. Hace falta el hábito de hacer estas tres preguntas en voz alta durante el refinamiento, y el acuerdo simple de que una historia sin respuesta no entra al Sprint tal como está. Si el equipo decide que igual tiene que entrar, al menos entra con la ambigüedad nombrada y asignada a alguien — no descubierta a ciegas en testing.

6. La Solución de Fondo: un Backlog que Sostenga el Sprint

Las 3 preguntas son un parche — necesario, aplicable ya, pero un parche. El síntoma de fondo (65+ historias, cero priorización, dependencias sueltas) necesita un cambio de proceso que ninguna checklist individual reemplaza:

Ninguno de estos cuatro cambios depende exclusivamente de QA — y eso es exactamente el punto. Si QA es el único que empuja por historias más claras, el síntoma vuelve la próxima Sprint. El cambio se sostiene cuando PO, Dev y QA acuerdan juntos que una historia sin las tres respuestas del checklist no está lista para comprometerse, sin importar la presión de fecha.

7. Para el Debate

No comparto esto para culpar a nadie en particular — PO, Dev o QA. Lo comparto porque es un patrón que vi repetirse en equipos y proyectos distintos, y sospecho que no soy el único. Quiero abrir la conversación con dos preguntas, y de verdad me interesa leer tu experiencia:

La calidad no empieza cuando QA ejecuta las pruebas. Empieza mucho antes, cuando se define qué se quiere construir. Si te tocó vivir este patrón — o si tu equipo ya encontró una forma de resolverlo que no fue la checklist de arriba — te leo en los comentarios de este artículo o en LinkedIn.