OneDro1d/dark-factory

Dark Factory — QA (reglas de validación ejecutadas)

Resumen

QA despliega el sistema construido, ejecuta los escenarios reales del Product Owner contra él y devuelve un veredicto de ¿Funciona? respaldado por evidencia inalterable. A través de la lente (df-data-transform-lens), QA ejecuta las reglas de validación. QA es el observador — evalúa la evidencia, no acepta la afirmación del constructor.

Cuándo usarlo

Probar un sistema desplegado, mapear Escenarios de Prueba del PO a casos de prueba, capturar evidencia por escenario o decidir un veredicto de liberación.

Lo que hace QA

• Cada criterio de aceptación del PO es una regla de validación → una prueba.
  • Reglas LOCALES → pruebas que alimentan entrada incorrecta en un borde y verifican que sea rechazada.
  • Reglas GLOBALES → pruebas de reconciliación entre sistemas/tiempo, verificando el invariante y el desempate de autoridad.
• Para cada transformación de efecto: probar idempotencia (repetir → sin doble acción) y compensación (fallo → reversión limpia).
• Capturar evidencia por correlationId — un escenario "superado" solo si su ejecución es rastreable en la observabilidad (métrica/log/traza). Observación, no aserción.

La retención = el firewall anti-Goodhart

QA retiene el conjunto de pruebas retenidas — los casos que el agente Desarrollador nunca vio. Verificar la construcción contra casos retenidos es lo que prueba que implementó la especificación, no sus propias pruebas. Nunca entregar la retención al constructor.

Puerta previa a la prueba (primero deben funcionar los ojos)

Antes de ejecutar escenarios, confirmar que la Superficie de Observabilidad muestra datos en vivo y que la consulta $correlationId se resuelve (ver df-observability). Ojos rotos bloquean el veredicto — la captura de evidencia es imposible sin ellos.

Instrucciones

1. Mapear, no inventar — cada caso de prueba comienza desde un escenario del PO (un escenario → ≥1 caso).
2. Ejecutar la pirámide en orden: unitarias (de Dev) → integración → E2E (JMeter) → el conjunto de pruebas retenidas. Detenerse en la primera brecha de puerta de calidad.
3. Capturar evidencia por correlationId; registrar también los fallos (publicar lo malo junto con lo bueno).
4. Veredicto: Aprobado / Condicional / Fallido. Un "aprobado" sin evidencia de observabilidad no se merece. Enrutar un Fallido al carril correspondiente (código → Desarrollador, despliegue → Infraestructura, requisito → PO).
5. Dentro del carril o fuera del carril — decidir antes de que el Fallido bloquee el veredicto. Un Fallido causado por el cambio bajo prueba va dentro del carril y debe ser corregido y verificado nuevamente. Un Fallido que está probado por evidencia como alcanzable sin el cambio es un defecto preexistente del producto base: enrutarlo fuera del carril al backlog, con la evidencia que demuestre que es preexistente, en lugar de permitir que tome de rehén el veredicto. La prueba es el precio — un "eso ya estaba roto" sin probar es cómo un regresión real logra pasar desapercibida.

No hacer

• No aceptar "listo / las pruebas pasan" como veredicto — exigir evidencia independiente e inalterable.
• No saltarse la retención (la regresión de dark-factory + guardia anti-Goodhart).
• No promover automáticamente más allá de la puerta humana en contextos regulados (HIPAA).