El diff miente
Review mira el cambio. QA mira el comportamiento. Un PR “correcto” puede dejar el checkout en rojo y el criterio de aceptación en verde.
El quinto paso del ciclo —y el talón de Aquiles del código que escriben los agentes—. Probar contra la spec, no contra la intuición. Aún no lo vendemos. No hay fecha.
En construcción · Sin fecha de cobro ni de lanzamiento · El ciclo ya se cierra hoy con Review
Preferimos no poner fecha a lo que todavía no usamos nosotros todos los días.
Review mira el cambio. QA mira el comportamiento. Un PR “correcto” puede dejar el checkout en rojo y el criterio de aceptación en verde.
Los criterios de aceptación no sirven si nadie los ejecuta. QA convierte la spec en casos, no en texto al pie del PR.
El cliente no compra un merge. Compra que el producto hace lo que pidió. Sin evidencia de prueba, la factory entrega opinión.
Probar contra la spec, no contra la intuición.
Los criterios de Spec se convierten en casos que alguien —o algo— ejecuta contra el cambio.
El agente cumple AURA-118 y rompe el flujo de cupones. QA mira el producto, no solo el diff.
Qué se probó, contra qué criterio, con qué resultado. El mismo lenguaje que Review. Para el CTO y para el cliente de la factory.
QA no va a “venir incluido” en un plan para rellenar la tabla. Cuando exista, tendrá precio propio. Hasta entonces no hay fila que vender ni fecha que incumplir. Review ya verifica intención, coherencia, calidad y seguridad en cada Pull Request.
Algunas software factories no necesitan Spec ni Orchestra: necesitan evidencia de que lo que entregaron se comporta. Cuéntanos cómo pruebas hoy. No hay lista de espera con fecha. Hay una conversación para construir esto con quien de verdad lo va a usar.