1. Lunes: la Historia que Parecía Perfecta
Era mi segunda semana en un equipo nuevo. El primer día de Sprint abrí la primera historia de usuario y sentí algo que no me pasa seguido: alivio. Criterios de aceptación claros, uno por uno. Reglas de negocio explícitas, sin nada que interpretar. Un link a Figma con cada estado del flujo ya validado por diseño.
En un artículo anterior conté lo que pasa cuando la historia llega ambigua a QA — sprints de 65 historias, backlog sin refinar, criterios que nadie terminó de escribir. Esta historia no tenía nada de eso. Y sin embargo, unos días después, iba a descubrir que "documentación perfecta" y "calidad" son dos cosas completamente distintas.
Escribí 20 casos de prueba esa misma tarde, cada uno mapeado uno a uno contra un criterio, una regla de negocio, una pantalla de Figma. El viernes la historia pasó a "Listo para probar." El lunes siguiente me senté a ejecutarlos, convencido de que iba a ser una tarde tranquila.
No lo fue. Y lo que encontré esa tarde terminó siendo la razón de este artículo: el equipo, sin darse cuenta, estaba usando a QA como mecanismo de descubrimiento de errores de implementación — y, peor, como validación tardía de si la historia correspondía o no al alcance real.
2. Caso 7: el Bug que no Debería Haber Existido
Los primeros casos ya venían dejando señales sueltas — un criterio que no calzaba del todo con el flujo, un detalle que no coincidía con Figma. Nada tan contundente como el caso 7, que probaba algo simple, casi aburrido de tan directo: una regla de negocio que decía, sin ninguna vuelta, que un usuario con una reserva activa no podía crear una segunda. Seguí el guion — usuario con reserva activa, clic en "Nueva reserva" — esperando que el sistema me bloqueara.
No me bloqueó. La segunda reserva se creó sin ningún problema. Volví a leer la regla de negocio para asegurarme de no haberla malinterpretado. No había vuelta que darle: estaba escrita con total claridad, y simplemente no se había implementado.
Regla de negocio (documentada, clara, sin ambigüedad):
"Si el usuario tiene una reserva activa, no puede crear una nueva."
Caso de prueba:
1. Usuario con reserva activa
2. Intenta crear una nueva reserva
3. Resultado esperado: el sistema lo bloquea
Resultado real:
El sistema permite crear la segunda reserva.
→ Bug. La regla estaba escrita. No se implementó.Seguí con el caso 8, el 9, el 10. Para cuando llegué al final de la tarde, esto era lo que tenía anotado en mi lista:
5
5
8
18 de 20 casos. No eran detalles cosméticos — eran reglas de negocio explícitas que el desarrollo simplemente no había respetado. Cerré la laptop esa noche pensando lo mismo que probablemente estás pensando ahora: ¿cómo una historia tan bien escrita terminó así?
3. Lo que Vimos en el Pizarrón esa Tarde
Le mostré la lista al lead de desarrollo al día siguiente. Nos sentamos frente al pizarrón y empezamos a clasificar caso por caso, uno por uno. Y ahí apareció algo que no había visto tan claro hasta ese momento: bajo el mismo síntoma — "demasiados bugs" — convivían en realidad dos problemas distintos.
| Qué se ve | Qué es en realidad | Qué corresponde hacer |
|---|---|---|
| La HU dice A, el sistema hace B | Defecto real de implementación | Bug — corregir el código para que cumpla A |
| Tras 3-4 ciclos, "esta regla ya no aplicaba" | HU mal asignada o no validada como implementable antes de programar | Detener, revisar con PO/BA — no seguir iterando a ciegas |
La mayoría de mis 18 hallazgos eran del primer tipo, y ahí QA estaba funcionando exactamente como debería: validando contra el contrato que había recibido. Pero dos o tres casos generaron una discusión distinta — más incómoda. El lead dudó frente a uno de ellos y dijo algo como "esto capaz que ya no aplica así". Fue la primera grieta de algo que íbamos a terminar de entender recién semanas después.
No se debería modificar una HU para cerrar bugs que en realidad corresponden a una implementación incompleta. Se lo dije en ese momento, medio en broma: la pregunta que hay que hacerse antes de tocar la HU es siempre la misma — ¿cambió realmente el negocio, o estamos ajustando el requisito para que coincida con lo que ya se desarrolló?
4. Cuatro Ciclos, el Mismo Fantasma
Ciclo 1, ese mismo lunes: reporto los 18 hallazgos, cada uno con evidencia, cada uno enlazado al criterio o regla que no se cumplía. El desarrollador los acepta todos sin discutir. Buena señal, pienso.
Ciclo 2, la semana siguiente: vuelvo a correr los 20 casos. Nueve siguen fallando. Los que se cerraron, se cerraron bien — pero todavía queda casi la mitad.
Ciclo 3: abro el tablero esperando ver cero. Veo cuatro. Uno de ellos es el caso 7 — la reserva duplicada, el mismo que empezó todo esto — y vuelve así:
Bug: No se cumple RN-05 (reserva duplicada)
Estado: Por probar
[sin comentario]
[sin evidencia]
[sin explicación de qué se modificó]
[sin indicar si se resolvió completo o parcial]
→ Tuve que volver a reconstruir todo el contexto desde cero,
con el mismo esfuerzo que reportarlo la primera vez.Ciclo 4, casi tres semanas después de aquel lunes con alivio: en la daily, alguien de desarrollo dice, casi al pasar, "creo que esta regla ya no aplicaba tal como la escribimos". Y ahí entendí que llevábamos un mes probando algo que nadie había terminado de validar que se pudiera construir tal cual estaba escrito. La solicitud llegó enseguida: pedirle al PO que ajustara la regla de negocio para que la historia por fin pudiera cerrarse.
Esa noche dibujé lo que habíamos vivido, para entenderlo yo mismo:
5. La Pregunta que Nadie se Había Hecho
Esa noche me quedé pensando en algo que se me había pasado por alto en medio de los cuatro ciclos: nadie, en ningún momento, había validado que el desarrollador pudiera implementar todo lo que la historia pedía antes de que llegara a mí. La HU pasó a "Listo para probar" simplemente porque alguien terminó de escribir código — no porque alguien confirmara que ese código cumplía lo que la propia historia describía.
Si yo, como QA, abrí la historia y encontré de entrada 5 reglas de negocio incumplidas, 5 criterios sin implementar y 8 diferencias visuales, esa historia, en los hechos, nunca estuvo lista para mí. Estaba lista para que alguien la revisara — y ese "alguien" tendría que haber sido el propio desarrollador, antes de mover el estado.
6. Lo que Cambiamos el Sprint Siguiente
Lo planteé en la retro de ese Sprint, sin esperar que nadie fuera del equipo nos diera permiso. La solución de fondo — validar que una historia es implementable antes de que empiece a programarse — iba a tomar tiempo y necesitaba acuerdo de más gente. Pero había dos hábitos que podíamos probar ya, en el próximo Sprint.
Primero: el desarrollador se auto-valida contra la HU antes de mover el estado a "Listo para probar".
✓ Repasé cada criterio de aceptación contra mi implementación,
uno por uno — no de memoria
✓ Repasé cada regla de negocio explícita de la HU
✓ Comparé el resultado visual contra Figma
✓ Ejecuté el flujo principal y al menos un caso alternativo
✓ Si algo de la HU no apliqué o no pude cumplir,
lo dejé comentado ANTES de pasar a QA — no lo dejé silencioso
Si no puedo marcar las cinco → todavía no está "Listo para probar"Segundo: ningún bug cambia de estado sin un comentario mínimo de qué se hizo — la regla que hubiera evitado la escena del ciclo 3.
Acordamos algo simple: un bug no puede pasar de "En progreso" a "Por probar" sin al menos una línea indicando qué se corrigió y si la corrección es completa o parcial. Sin eso, no lo vuelvo a probar — lo devuelvo pidiendo el comentario. Cuesta diez segundos escribirlo y ahorra un ciclo entero de descubrir el contexto de nuevo.
Con la siguiente historia del mismo módulo, los 20 casos bajaron a 3 hallazgos reales en el primer ciclo. Ninguno tardó más de una vuelta en cerrarse.
7. Lo que Todavía nos Falta
El auto-checklist funcionó, pero sé que no resuelve el caso más grave — el del caso 7, el de la regla que "ya no aplicaba". Ese sigue necesitando un paso que todavía no tenemos como equipo, antes de que el desarrollo empiece:
| Etapa | Qué valida |
|---|---|
| Refinamiento / Grooming | Que la HU tenga AC, reglas de negocio y diseño — la parte documental |
| Validación técnica previa | Que el Dev asignado confirme que puede implementar todo lo escrito, con ese alcance, en ese sistema |
| Desarrollo + auto-validación | Que la implementación cumpla el checklist de la sección 6 antes de cambiar el estado |
| QA | Que la implementación validada cumpla el contrato — no que lo descubra por primera vez |
El paso que nos falta es el segundo: todavía nadie confirma, antes de escribir código, que el desarrollador entiende y puede implementar cada criterio, cada regla y cada detalle de diseño asociado a la HU. Hoy esa validación sigue ocurriendo, en los hechos, cuando yo empiezo a probar — y ese sigue siendo nuestro cuello de botella.
8. Para el Debate
No cuento esto para señalar a nadie de mi equipo — al contrario, son de los mejores con los que trabajé, y por eso me sorprendió tanto encontrarme con este patrón ahí. Un equipo con HU perfectamente documentadas y aun así 3-4 ciclos de pruebas por historia no tiene un problema de documentación ni de QA — tiene un problema de handoff: nadie valida que la implementación cumple el contrato antes de que ese contrato llegue a QA.
¿Cuántos de los bugs que reporta tu equipo son errores reales de implementación, y cuántos terminan resolviéndose modificando la HU en vez de corrigiendo el código?
¿Qué pasa en tu equipo cuando el mismo bug vuelve al tercer ciclo sin un solo comentario de qué se cambió?
Tener una HU perfectamente documentada no garantiza calidad si nadie valida que la implementación realmente la cumple antes de enviarla a QA. Yo debería validar la calidad de la implementación — no descubrir, después de tres o cuatro ciclos, cuál era realmente el alcance de la historia. Si te tocó un caso 7 propio, o tu equipo ya resolvió el handoff de otra forma, te leo en los comentarios de este artículo o en LinkedIn.