ESTADO: Propuesto
FECHA: 2026-05-11
AUTOR: Carlos Alberto Torres Camargo (arquitecto)
REVISORES PENDIENTES: Gatekeepers del proyecto (Sr. Backend, Sr. Frontend), Product Owner, PM/Scrum Master, QA Lead
Nebula ERP tiene operativo el flujo técnico de entrega DEV→QA: Modelo A GitFlow con ramas permanentes develop/qa/main, pipeline CI/CD Jenkins shared library centrica-pipeline-shared@v1.0.4 con builds automáticos por webhook GitLab, y 22 de 22 repos backend con primer build QA SUCCESS (verificado 2026-05-11). El plan de ruta documental (FLUJO_HT_A_PROD.md, CICD_HOJA_RUTA_QA_PROD.md, GITFLOW_DETALLADO.md) está actualizado a Modelo A.
Auditoría documental al 2026-05-11 detecta gaps en la capa de proceso (no técnica) del flujo de entrega a QA:
QA_HANDOFF.md: existe plantilla canónica (architecture/nebula-erp/QA_HANDOFF_TEMPLATE.md v1.0.0) pero su uso aún no es obligatorio post-merge a qa. Plantilla cubre alcance, datos seed y casos críticos; queda fuera el reporte de ejecución y el acta de cierre.ROLES_RESPONSABILIDADES_FABRICA.md v2.0 no incluye explícitamente al QA Lead; el rol se asume tácitamente en GITFLOW_DETALLADO.md (firma del input manual en Jenkins) sin definición de responsabilidades, accountability, ni RACI.GITFLOW_DETALLADO.md §3.2 define el procedimiento técnico (bugfix/*-fix-qa + sync qa→develop), pero no la política de gestión (cuántos retrabajos, cuándo se escala, cuándo se retira HT del release).Adoptar una política formal de entrega a QA y validación de aceptación, compuesta por los siguientes elementos:
[F1 Definición] PO + Arquitecto firman HU + HTU GATE-A
↓
[F2 Sprint Plan] HTs del lote priorizadas, QA_HANDOFF draft GATE-B
↓
[F3 Desarrollo] feature/HT-XXX → develop (PR + Gatekeeper) GATE-C (DoD verde)
↓
[F4 Promoción] develop → qa (MR + QA_HANDOFF v1 firmado) GATE-D (pre-corte QA)
↓
[F5 Validación] QA ejecuta + reporta + decide GATE-E (criterio aprobación)
↓
[F6 Cierre QA] Acta de cierre QA firmada GATE-F (QA Closure)
↓
[F7 Release] qa → main + tag SemVer GATE-G (release authorized)
↓
[F8 Post-Release] Retro QA, métricas, deuda registrada
Cada gate tiene checklist asociado, responsable de firma, y output material (commit, push, archivo firmado).
| # | Artefacto | Ubicación | Owner | Cuándo |
|---|---|---|---|---|
| 1 | DEFINITION_OF_DONE.md (corporativo) |
wiki/zona-interna/04-sdlc/ |
Arquitecto | Referenciado en GATE-C y GATE-D |
| 2 | QA_HANDOFF.md (instancia por sprint) |
architecture/sprint-N/ |
Backend Lead | Producido pre GATE-D |
| 3 | QA_EXECUTION_REPORT.md (instancia por sprint) |
architecture/sprint-N/ |
QA Lead | Producido durante F5, cerrado en GATE-E |
| 4 | QA_CLOSURE.md (instancia por sprint) |
architecture/sprint-N/ |
QA Lead + Arquitecto | Firmado en GATE-F |
| 5 | POLITICA_REGRESION_QA.md |
wiki/zona-interna/04-sdlc/ |
Arquitecto | Referencia continua |
| 6 | POLITICA_ROLLBACK.md |
wiki/zona-interna/04-sdlc/ |
Arquitecto | Referencia continua |
Plantillas canónicas de los artefactos 2-4 viven en architecture/nebula-erp/ (QA_HANDOFF_TEMPLATE.md ya existe v1.0.0; QA_EXECUTION_REPORT_TEMPLATE.md y QA_CLOSURE_TEMPLATE.md se crean con esta ADR).
Se incorpora QA Lead a ROLES_RESPONSABILIDADES_FABRICA.md con responsabilidades explícitas:
QA_HANDOFF.md (SLA: mismo día hábil).08_Contracts.md + 07_TestCases.md de cada HT.QA_EXECUTION_REPORT.md con matriz de casos vs resultado, defectos, métricas.QA_CLOSURE.md junto con Arquitecto en GATE-F.qa en Jenkins UI.| Actividad | SLA |
|---|---|
Acuse de recibo QA_HANDOFF.md |
Mismo día hábil |
| Inicio ejecución casos | ≤ 24h tras GATE-D |
| Reporte primeros bloqueantes | ≤ 48h tras GATE-D |
| Cierre completo del lote | ≤ 5 días hábiles para lote ≤ 10 HTs; +1 día por cada 5 HTs adicionales |
| Defecto | SLA de fix |
|---|---|
| Bloqueante | 48h |
| Crítico | 72h |
| Mayor | 5 días o retiro de HT |
| Menor | Documentar como deuda aceptada |
Tras 3 ciclos de retrabajo sin aceptación, escala a Arquitecto.
Un lote es aprobado en GATE-E cuando:
QA_CLOSURE.md).Un defecto se clasifica crítico cuando se cumple al menos uno:
Autoriza rollback: Arquitecto (en PROD), QA Lead (en QA). DevOps ejecuta.
Se agrega stage opcional Verify QA_HANDOFF al microservicePipeline.groovy (bump a v1.1.0) que verifica:
architecture/sprint-N/QA_HANDOFF.md cuando se hace merge a qa.Bypass permitido con justificación en commit message (etiqueta [QA-HANDOFF-BYPASS]) que dispara alerta al Arquitecto.
Esta integración técnica se hace después de validar el flujo en piloto sprint-3.
| Alternativa | Pros | Contras | Veredicto |
|---|---|---|---|
| A. Status quo (sin política formal) | Cero esfuerzo. Flexibilidad total al equipo. | Improvisación por sprint. Sin accountability. Defectos sin SLA. | Descartada. |
| B. Solo SLAs y criterio aprobación, sin templates adicionales | Esfuerzo bajo. | No resuelve la falta de Reporte de Ejecución y Acta de Cierre. Métricas pobres. | Descartada. |
C. Pipeline gate técnico que bloquea promoción sin QA_HANDOFF |
Enforcement automatizado. | Sin política previa, gate técnico genera fricción innecesaria. La política debe preceder al enforcement. | Aceptada como Fase 8 del plan (post-piloto). |
| D. Política formal con templates + SLAs + rol QA Lead (esta decisión) | Resuelve todos los gaps. Documental, no técnica. Permite piloto sin bloquear flujo actual. | Esfuerzo de documentación (~5 días persona). Adopción cultural requiere disciplina. | Adoptada. |
| E. Externalizar QA a proveedor con contrato SLA | SLAs contractuales. Equipo Centrica se enfoca en desarrollo. | Costo. Pierde conocimiento interno. No aplica a equipos in-house. | Descartada para fase actual. |
QA_EXECUTION_REPORT.md (casos pasados/fallados, MTTF, ciclos de retrabajo).A los 90 días de adoptado el ADR:
QA_HANDOFF.md, QA_EXECUTION_REPORT.md y QA_CLOSURE.md firmados.| Fase | Acción | Owner | Estado |
|---|---|---|---|
| 1 | Emitir ADR-003 estado Propuesto | Arquitecto | Completado 2026-05-11 |
| 2 | Crear DEFINITION_OF_DONE.md |
Arquitecto | Completado 2026-05-11 |
| 3 | Crear QA_EXECUTION_REPORT_TEMPLATE.md |
Arquitecto | Completado 2026-05-11 |
| 4 | Crear QA_CLOSURE_TEMPLATE.md |
Arquitecto | Completado 2026-05-11 |
| 5 | Crear POLITICA_REGRESION_QA.md + POLITICA_ROLLBACK.md |
Arquitecto | Completado 2026-05-11 |
| 6 | Actualizar ROLES_RESPONSABILIDADES_FABRICA.md con QA Lead |
Arquitecto | Completado 2026-05-11 |
| 7 | Actualizar FLUJO_HT_A_PROD.md, GITFLOW_DETALLADO.md, INDICE_SDLC.md |
Arquitecto | Completado 2026-05-11 |
| 8 | Presentar ADR-003 a gatekeepers y QA Lead, recibir feedback | Arquitecto | Pendiente |
| 9 | Cambiar estado de ADR-003 a Aprobado | Arquitecto + gatekeepers | Pendiente fase 8 |
| 10 | Piloto sprint-3 cierre: usar QA_HANDOFF.md + QA_EXECUTION_REPORT.md + QA_CLOSURE.md |
Backend Lead + QA Lead + Arquitecto | Pendiente fase 9 |
| 11 | Retro del piloto: ajustar SLAs y criterios con datos reales | Arquitecto + equipo | Pendiente fase 10 |
| 12 | Integrar stage Verify QA_HANDOFF en pipeline (v1.1.0) |
Arquitecto | Pendiente fase 11 |
| Actividad | PO | Arquitecto | PM | Backend Lead | Gatekeeper Backend | Backend Sr/Mid/Jr | QA Lead | DevOps |
|---|---|---|---|---|---|---|---|---|
| Captura HU | R/A | C | C | I | - | - | I | - |
| Diseño HTU | C | R/A | I | C | - | - | C | - |
| Sprint Plan | C | A | R | R | C | I | C | C |
Producir QA_HANDOFF.md |
C | A | C | R | C | - | C | - |
| Implementar HT | - | C | I | C | A | R | - | - |
| Code review pre-merge | - | C | - | C | R/A | I | - | - |
Promover develop→qa (GATE-D) |
I | A | I | R | C | - | I | C |
| Ejecutar pruebas QA | I | C | I | I | - | - | R/A | - |
Producir QA_EXECUTION_REPORT.md |
- | C | I | - | - | - | R/A | - |
| Decisión aprobar/rechazar (GATE-E) | I | C | I | I | - | - | R/A | - |
Firmar QA_CLOSURE.md (GATE-F) |
I | C | I | I | - | - | R | - |
Release qa→main (GATE-G) |
I | R/A | C | C | C | - | C | C |
| Rollback PROD | I | R/A | I | C | C | - | I | R |