Un dev del equipo te manda un PR. Los tests pasan — todos verdes. Playwright corriendo en CI, cobertura por encima del 80%, todos los criterios de aceptación marcados. Hace seis meses lo aprobabas en cuatro minutos.
Hoy no.
Porque hace dos semanas el equipo adoptó Spec-Driven Development. Y el código que estás revisando no lo escribió el dev — lo generó la IA a partir de una spec que escribió él solo, sin ti en la mesa. Los tests que pasan tampoco los escribió el dev — los generó la IA a partir de esa misma spec.
Ahí está el problema. Tests verdes que validan código generado desde la misma spec ambigua que ya nadie auditó. Validación circular pura. El PR pasa porque la IA está siendo consistente consigo misma, no porque el sistema haga lo que el usuario necesita.
Si lo apruebas, el bug llega a producción. Si lo rechazas sin argumentos técnicos, quedas como el QA que “frena el flow”.
Hay una tercera opción. Y es donde empieza tu nuevo trabajo.
Antes de seguir — el contexto que necesitas
Hace un mes publiqué Spec-Driven Development: si la IA escribe los tests, ¿para qué nos pagan a los QA?. Hace tres semanas, la guía paso a paso con GitHub Spec Kit. Si no las leíste, este artículo va a tener más sentido después.
Lo que dejé abierto en el primer artículo: el QA no desaparece con SDD. Cambia de posición. La pregunta que te quedaba era operativa — ¿qué hago yo, mañana, el lunes a las 9 de la mañana, cuando llego al sprint y mi equipo ya está usando SDD?
Esto es la respuesta. Llega en tres entregas:
- Hoy: tu nuevo trabajo frente al dev y al product owner
- Mañana: tu nuevo trabajo frente al arquitecto y al Scrum Master
- El viernes: el playbook completo para arrancar el primer ciclo SDD multi-rol con tu equipo
Antes de meternos en cada rol, una frase. Repítela en voz alta. Tenla presente en cada ciclo de ahora en adelante:
El QA dejó de ser el último filtro. Ahora es el primero.
En cascada validabas al final. En agile validabas un poco antes, pero seguías cerca del final. En SDD validas antes del código — en el lugar donde antes vivía el dev escribiendo el primer renglón.
No es teoría. Es la única manera de que SDD no se vuelva un generador masivo de bugs caros.
Frente al dev: la trampa circular
Antes, cuando un dev escribía código y un dev (o tú, según el equipo) escribía los tests, había dos cerebros mirando el problema desde dos ángulos. El dev pensaba “cómo hago que esto funcione”. Tú pensabas “cómo hago que esto falle”. Dos intenciones distintas atacando el mismo código.
Con SDD eso se rompe.
El dev escribe la spec. La IA genera el código desde la spec. La misma IA — o un agente que entiende la misma spec — genera los tests. Ambos artefactos vienen de la misma fuente, interpretada de la misma manera, por el mismo sistema.
Si el código y los tests vienen de la misma spec ambigua, los tests van a pasar — siempre. Pero estarán pasando porque el sistema es consistente consigo mismo, no porque resuelva el problema del usuario.
Te lo cuento con un ejemplo que vas a reconocer.
Imagina una spec de login que dice: “Después de 5 intentos fallidos, bloquear el usuario”.
Suena clara. Pero léela de nuevo:
- ¿Qué cuenta como “intento fallido”? ¿Password incorrecto? ¿Usuario inexistente? ¿2FA fallado?
- ¿Los 5 intentos son consecutivos, o acumulados en un período? ¿Y si pasan 24 horas entre el intento 4 y el 5?
- ¿Se cuenta por usuario, por IP, por dispositivo, o por combinación?
- ¿El usuario queda bloqueado para siempre, hasta que un admin lo desbloquee, o hasta que pasen N minutos?
- ¿El sistema le avisa al usuario que está bloqueado, o le sigue mostrando “credenciales incorrectas” para no dar pistas a un atacante?
La IA va a interpretar todas estas decisiones. Va a tomar una opción por cada una, generar el código, y después generar los tests con la misma interpretación. Los tests van a pasar.
Y tres semanas después vas a tener un ticket abierto que dice “usuarios reportan que después de bloquearse vuelven a entrar a los 2 minutos sin saber por qué”. Cuando vayas a revisar el código y los tests, todo va a parecer correcto. Porque el código hace lo que los tests verifican. Y los tests verifican lo que el código hace. Y los dos hacen lo que la IA decidió que la spec significaba.
Eso es la trampa circular.
Tu nuevo trabajo: auditar la spec antes que el código
Antes leías código. Ahora lees specs. Y ya no después del desarrollo — antes. Mucho antes.
Tu cerebro de QA tiene un talento que ningún dev tiene en la misma intensidad: ver lo que falta. Ver el hueco. Ver el caso de borde que nadie mencionó. Cuando un dev escribe una spec, su sesgo natural es escribir lo que sabe cómo implementar. Tu sesgo natural es ver lo que va a romper.
Eso es exactamente lo que SDD necesita.
No estás validando que el código cumpla la spec — eso ahora lo hace la IA y lo hace bien. Estás validando que la spec cubra el problema real del usuario. Si la spec está completa, el resto del ciclo funciona. Si la spec tiene huecos, todo lo que venga después está contaminado.
Esto requiere una habilidad distinta. No es mejor ni peor — es distinta. Y casualmente, es la habilidad que los QA seniors venimos desarrollando durante años cuando hacíamos pre-validación de requerimientos en refinement, cuando reescribíamos historias confusas, cuando le decíamos al PO “esto no se puede testear así”. Esa habilidad pasó del 10% del trabajo al 70% del trabajo.
Si la tienes, te promovieron. Si no la trabajaste, ahora la tienes que desarrollar urgente.
Checklist: 7 huecos que un dev no ve en su propia spec
Cuando recibas una spec para auditar, léela buscando estos 7 patrones. Vas a encontrar al menos uno en cada spec, garantizado.
1. Ambigüedad numérica. Cualquier cantidad sin unidad, rango, o comportamiento de borde. “5 intentos” sin definir ventana de tiempo. “Hasta 1000 caracteres” sin definir si incluye espacios o no. “Más de 18 años” sin definir si exactamente 18 cuenta o no.
2. Negaciones sin especificar. “El usuario no puede X.” ¿Qué pasa si lo intenta igual? ¿Mensaje de error? ¿Botón deshabilitado? ¿Redirect? ¿Excepción 403? ¿Audit log? El “no puede” sin consecuencia definida es un bug en producción esperando a salir.
3. Sincronía implícita. Operaciones que la spec describe en lenguaje natural pero que en producción son asíncronas. “Cuando el usuario pague, se le envía el email de confirmación.” ¿Inmediatamente, o cuando el procesador de pagos confirme? ¿Y si falla el email pero el pago ya se procesó?
4. Estados intermedios faltantes. La spec describe el estado inicial y el final, pero no los intermedios. “El pedido pasa de creado a enviado.” ¿Pasa por confirmado? ¿En preparación? ¿Pagado? ¿Y si el usuario cancela durante la preparación, qué estado queda?
5. Roles implícitos. La spec usa “el usuario” como si todos fueran iguales. ¿Hay roles distintos? ¿Admin, cliente, soporte, invitado? ¿Cada uno tiene las mismas restricciones? ¿Qué pasa en las intersecciones — un admin que también es cliente?
6. Condiciones desactivadas. La spec describe el happy path completo y los errores obvios, pero no los caminos donde una validación falla por una razón que nadie escribió. “El usuario sube un archivo.” ¿Tamaño máximo? ¿Tipos permitidos? ¿Qué pasa si el archivo está corrupto? ¿Qué pasa si pierde la conexión a mitad del upload?
7. Dependencias externas asumidas. La spec menciona “cuando recibimos la confirmación del banco” pero no describe qué pasa cuando el banco está caído, responde lento, devuelve un error inesperado, o cambia su API sin avisar.
Estos 7 patrones no son una lista exhaustiva. Son lo mínimo. Si la spec sobrevive a estos 7 filtros, recién puedes decirle al equipo “lista para entrar al pipeline”.
Frente al PO/PM: la US se ejecuta literal
Acá viene la parte que más le va a doler a tu equipo: la forma en que el product owner viene escribiendo historias dejó de ser suficiente.
Durante años aprendimos a escribir user stories en el formato “Como [rol], quiero [funcionalidad], para [beneficio]”. Es un formato que ayudó a alinear equipos, a poner al usuario en el centro, a evitar que los devs construyeran cosas que nadie necesitaba.
Pero ese formato fue diseñado para humanos.
Cuando una persona lee “Como usuario, quiero recuperar mi contraseña, para volver a entrar a mi cuenta”, lo interpreta con sentido común. Sabe que probablemente involucra un email, un token con vencimiento, una nueva contraseña que cumpla ciertas reglas, no permitir reusar la anterior, invalidar sesiones activas, mandar un email de confirmación al final. Todo eso no está escrito en la US — está implícito en lo que cualquier humano con experiencia mínima en software esperaría.
La IA no tiene sentido común. La IA toma esa US y ejecuta literal lo que dice.
Una user story en SDD ya no es un input para que el equipo discuta. Es un input que va a alimentar a un sistema de agentes que va a generar código y tests. Lo que no está escrito explícitamente, no existe. Y lo que está escrito ambiguo, se va a interpretar de la peor manera posible — no por mala fe, sino porque la IA toma la primera interpretación coherente que encuentra.
Un caso típico que vas a ver dentro de poco.
Una US del estilo: “Como administrador, quiero exportar el reporte de ventas mensual a Excel, para compartirlo con el equipo de finanzas.”
Suena clara. El PO la escribió en treinta segundos. La IA genera código que crea un endpoint que retorna un archivo .xlsx. Genera tests que verifican que el endpoint responde 200 y que el archivo tiene la extensión correcta. Tests verdes. Sprint cerrado.
Tres semanas después, finanzas se queja:
- El reporte tarda 45 segundos en generarse para meses con muchos datos — la UI quedaba colgada sin feedback.
- No incluye las ventas canceladas pero sí las pendientes, y nadie sabía cuál era el criterio.
- Los números no cuadran con el reporte interno porque la IA decidió usar la fecha de creación del pedido y finanzas esperaba la fecha de cobro.
- El admin que descargó el archivo no quedó registrado en ningún audit log.
- Cuando un admin sin permisos a “ventas” intenta exportar, el sistema le devuelve el archivo igual.
Cinco bugs caros. Todos producto de huecos en la US. Ninguno de los tests generados los iba a detectar — porque los tests salieron de la misma US incompleta.
Tu nuevo trabajo: traductor de ambigüedad
Esto no es nuevo en el oficio del QA — siempre fuimos los que pedíamos detalle en refinement, los que decíamos “pero qué pasa si…”, los que llenábamos de notas las historias en Jira. Lo que cambió es la importancia relativa de esa tarea.
Antes, si una US estaba incompleta, el dev preguntaba durante el desarrollo. Tú preguntabas en QA. El PO ajustaba sobre la marcha. Era un sistema imperfecto pero amortiguado por la conversación humana en cada paso.
En SDD no hay esa conversación. La IA no pregunta. La IA ejecuta.
Tu trabajo es asegurar que la US que entra al pipeline ya tenga todo lo que la IA necesita interpretar sin sesgo. Y tu posición para hacerlo es única, porque combinas tres cosas que ningún otro rol tiene juntas:
Esos tres ángulos son exactamente lo que una user story necesita para sobrevivir a SDD.
Plantilla: cómo reescribir una US para SDD
Cuando recibas una US del PO que va a entrar al pipeline de SDD, no la apruebes hasta que sobreviva a esta reescritura:
1. Convertir el 'quiero' en comportamiento observable
La US dice “quiero recuperar mi contraseña”. Reescríbelo como: “Cuando un usuario solicita recuperar su contraseña [trigger], el sistema [comportamiento medible] dentro de [tiempo o condición], y el resultado verificable es [output específico]”. Si no puedes llenar esos cuatro campos, la US no está lista.
2. Listar todos los actores, no solo el principal
La US dice “como administrador”. Pregunta: ¿qué otros roles tocan este flujo? ¿Soporte puede ver lo mismo? ¿Auditoría queda involucrada? ¿Hay roles que NO deberían poder hacer esto? Cada rol que toque el flujo necesita una línea explícita en la spec.
3. Convertir cada beneficio en métrica
La US dice “para compartirlo con finanzas”. Eso es marketing — no es testeable. Reescríbelo: “para que finanzas pueda procesar el reporte el primer día hábil del mes, sin intervención manual, sin reformateo”. Ahí sí puedes validar si el feature cumplió su propósito.
4. Hacer explícito lo que NO está incluido
Esta es la parte que los POs olvidan. Después de la lista de lo que SÍ hace, agregar una sección “fuera de alcance” con todo lo que parece obvio pero no entra: “no incluye notificación por email”, “no incluye versión en otros idiomas”, “no incluye permisos personalizados”. La IA va a respetar esto. Tu equipo también.
5. Definir el comportamiento del peor escenario
“¿Qué pasa cuando algo falla?” es la pregunta que te ahorra el 80% de los bugs caros. Para cada acción del usuario, definir explícitamente: qué pasa si el servicio externo no responde, qué pasa si la operación es muy lenta, qué pasa si el usuario cierra la app a mitad del proceso, qué pasa si la operación se duplica accidentalmente.
Esta plantilla no se inventó de cero — es la suma de lo que un buen QA hace en refinement durante años, ordenado para que sea repetible. La diferencia con antes es que ahora es un entregable obligatorio, no una recomendación optimista. La US no entra al pipeline si no pasa los 5 puntos.
Lo que viene mañana
Hoy cubrimos las dos relaciones más visibles del QA en cualquier equipo: el dev que escribe código y el PO que escribe historias. Pero hay otros dos roles donde tu posición también cambió, y son menos obvios — por eso es donde el mayor riesgo va a quedar oculto durante meses.
Mañana, SDD no reemplazó al QA: lo promovió — Parte 2: frente al arquitecto y al Scrum Master:
- Por qué el pipeline de agentes (orchestrator, code gen, test gen, validator) ES una decisión arquitectónica nueva — y tu rol en definirla
- Por qué la calidad de la spec dejó de ser un nice-to-have y pasó a ser una métrica de arquitectura
- Cómo cambia el refinement, la daily y la retro cuando el equipo trabaja con SDD
- Las 3 ceremonias que se transforman — y la única que sigue igual
Y el viernes, el playbook completo: cómo arrancas el primer ciclo SDD multi-rol con tu equipo, paso a paso, anti-patrones incluidos.
SDD no te reemplazó. Te promovió. Pero la promoción solo se hace efectiva si te plantas en la nueva posición — antes del código, no después. Si sigues validando como hace seis meses, llegaste tarde a tu propio ascenso.
Si esto te resuena, hay algo importante: la promoción no es individual. Es del oficio entero. Y por una vez en la historia, los QA somos los que mejor preparados estamos para liderar el cambio.
Nos vemos mañana.