El costo de no invitar a QA al refinamiento
Tabla de contenidos
Alguna vez te ha pasado: estás en un refinamiento, el Product Owner explica la historia de usuario, los desarrolladores discuten tecnologías, y tú — QA — te preguntas en silencio: «¿Qué hago aquí?»
Si te ha dado sueño en un refinamiento, no es porque seas mal profesional. Es porque nadie te ha mostrado el valor brutal que tiene tu presencia en esa sala. Y peor aún: es probable que nadie en tu equipo lo sepa tampoco.
Este artículo existe para cambiar eso.
Todos leen la misma historia. No todos ven lo mismo.
Imagina una historia de usuario cualquiera. Algo como:
«Como usuario, quiero poder transferir dinero a otro usuario y recibir una notificación del resultado.»
Un desarrollador lee eso y piensa: ¿cómo lo construyo? ¿Qué tecnología uso? ¿Cuánto tiempo me lleva? Preguntas válidas. Necesarias.
Un QA lee exactamente la misma historia y piensa: ¿qué pasa si esto falla? ¿Qué significa exactamente «notificación»? ¿Puede el usuario romper esto sin querer?
Cada rol filtra la historia desde su responsabilidad. Eso no es un problema — es una ventaja. Pero solo funciona como ventaja si todas esas perspectivas están presentes en la misma conversación.
El problema ocurre cuando QA recibe el ticket después de que el código ya está escrito. En ese momento, cambiar algo tiene un costo enorme — para el desarrollador, para el equipo, para el producto.
Por eso estamos hablando del refinamiento y no de la fase de testing.
La autopsia: 6 problemas que nadie vio
Voy a demostrarte exactamente cómo lee un QA una historia de usuario. No voy a buscar si funciona. Voy a buscar lo que no está escrito.
Usemos la historia de la transferencia de dinero como ejemplo.
1. Límites
La historia dice que el usuario puede transferir dinero. Perfecto. ¿Cuánto? ¿Hay un mínimo? ¿Un máximo por transacción? ¿Un límite diario?
Si esto no está definido aquí, el desarrollador va a implementar lo que le parezca lógico. Y lo que le parece lógico a él puede no ser lo que requiere el negocio, ni lo que exige la regulación financiera.
2. Identidad
¿Cómo se identifica al destinatario? ¿Por email? ¿Por nombre de usuario? ¿Por número de cuenta? ¿Qué pasa si existen dos usuarios con el mismo nombre?
Esta ambigüedad tarda 30 segundos en resolverse en un refinamiento. En producción, puede costar semanas — y dinero real de usuarios reales.
3. Error
Escenario: la red falla justo cuando se está procesando la transferencia. El saldo ya salió de la cuenta origen. Pero no llegó al destinatario. ¿Qué hace el sistema? ¿Qué le muestra al usuario en ese momento?
Nadie lo definió. Y ese vacío lo va a llenar el desarrollador, solo, en el momento en que escribe el código.
4. Seguridad
¿Hay validación de sesión activa antes de procesar la transferencia? En una aplicación fintech esto no es un detalle de experiencia de usuario. Es un requisito regulatorio.
Si no está especificado en la historia, no está garantizado en el código.
5. Ambigüedad
El criterio de aceptación dice: «el usuario recibe notificación del resultado». ¿Qué es una notificación? ¿Email? ¿Push notification? ¿Un mensaje dentro de la app? ¿Los tres?
¿Y si el email no llega? ¿La transferencia se considera exitosa igual?
«Notificación del resultado» parece un criterio claro. No lo es — esconde tres decisiones de negocio que nadie tomó.
6. Dato
La conexión se corta mientras el sistema está procesando. ¿La transacción quedó en estado «pendiente» o en estado «error»? Para el sistema puede parecer un detalle técnico menor. Para el usuario es la diferencia entre «mi dinero está en camino» y «perdí mi dinero». Son dos experiencias completamente distintas. Y ninguna de las dos está definida en esta historia.
Seis problemas. En una sola historia de usuario. Esto no es una crítica al equipo. Es lo que pasa cuando QA no tiene voz en el refinamiento.
El ojo que busca lo que puede fallar tiene que estar presente antes de que empiece la construcción.
Los números no mienten
Lo que acabas de leer no es teoría. La industria del software lleva décadas midiendo exactamente esto: cuánto cuesta encontrar un problema tarde versus encontrarlo temprano.
30x — Treinta veces más caro. Ese es el costo de corregir un bug en producción comparado con detectarlo en los requisitos. No en testing. En producción. Ese número viene de un estudio del IBM System Sciences Institute que analizó el costo de corrección de defectos a lo largo de todo el ciclo de vida del software. El 30x es el promedio conservador. En sistemas críticos como fintech o healthcare, el ratio sube considerablemente.
64% — El 64% de los defectos en software tienen origen en requisitos mal definidos. No en código mal escrito. En requisitos.
40% — El 40% del tiempo de retrabajo en proyectos se debe a ambigüedad en los requerimientos.
Cada pregunta que QA hace en el refinamiento es una inversión. Probablemente la más barata de todo el proyecto.
El framework: 3 preguntas que cambian todo
Podría darte una lista de cincuenta preguntas para hacer en un refinamiento. No voy a hacer eso. Porque memorizando preguntas llegas hasta cierto punto. Entendiendo por qué se hacen, llegas a cualquier historia.
Los seis problemas de la autopsia salen de tres preguntas base. Si aprendes a hacerte estas tres preguntas, vas a poder generar tus propias listas en cualquier contexto.
1. ¿Qué pasa si falla?
No el camino feliz. El camino feo. ¿Qué pasa si la red falla? ¿Si el servicio externo no responde? ¿Si el usuario hace algo que no se esperaba?
Esta pregunta sola genera la mitad de los escenarios de prueba más críticos de cualquier historia.
2. ¿Qué no está definido?
Todo lo que está escrito en una historia tiene un significado. Pero todo lo que no está escrito igual toma un valor — lo decide el desarrollador en el momento en que está programando.
Los límites del sistema, los estados intermedios, los términos que parecen obvios pero no lo son. Si algo te parece claro, pregúntalo igual. Lo que parece obvio para quien escribe la historia no siempre lo es para quien tiene que programarla.
3. ¿Quién sufre si esto sale mal?
Esta es la pregunta que define la prioridad. No todas las ambigüedades tienen el mismo peso. Una que afecta la experiencia visual es muy diferente a una que puede causar pérdida de dinero o una multa regulatoria.
En fintech, una ambigüedad en la identificación del destinatario puede derivar en una multa. En e-commerce, en una devolución masiva. En healthcare, puede comprometer datos médicos. No es lo mismo una ambigüedad que afecta un botón visual que una que puede causar pérdida de dinero.
Esto no es exclusivo de QA (pero QA lo hace diferente)
Estas tres preguntas no son exclusivas de QA. Un desarrollador puede hacerlas. Un Product Owner puede hacerlas. Un Scrum Master puede hacerlas.
La diferencia es que QA las hace de manera sistemática, en cada historia, antes de que empiece el trabajo. Eso es lo que la industria llama shift-left testing: mover la calidad hacia el inicio del proceso, no dejarlo para el final.
Un QA en el refinamiento no está ahí para frenar al equipo. Está ahí para que el equipo no tenga que frenar después.
Entonces, ¿qué haces la próxima vez?
Si eres QA y te invitan al refinamiento: la próxima historia de usuario que lean — antes de aceptarla — háganle las tres preguntas. Una sola vez. Y fíjense qué encuentran.
Si eres PO, Scrum Master o líder técnico y no estás invitando a QA al refinamiento: ya viste lo que se pierde. Seis problemas en una sola historia. Multiplícalo por cada historia de cada sprint.
Si eres desarrollador y piensas que el refinamiento «no es para QA»: recuerda que cada ambigüedad que no se resuelve en esa sala, la vas a resolver tú solo frente a tu editor de código. A veces acertarás. A veces no. Y cuando no aciertes, el costo lo paga todo el equipo.
Reflexión final
En 15 años trabajando en software, la diferencia entre los proyectos que funcionaron y los que no casi nunca estuvo en la tecnología. Estuvo en las conversaciones que el equipo tuvo — o no tuvo — antes de empezar a construir.
El refinamiento es esa conversación.
No dejes a QA afuera.