Versión: 1.0
Fecha: 2026-05-11
Autor: Carlos Alberto Torres Camargo (arquitecto)
Documentos relacionados: ADR-003 Política Entrega QA, DEFINITION_OF_DONE, GITFLOW_DETALLADO
Definir el procedimiento estándar cuando QA rechaza casos durante la Fase 5 (Validación) del flujo de entrega: cómo se atacan los defectos, qué SLAs aplican, cuántos ciclos de retrabajo se aceptan antes de escalar, y cuándo se retira una HT del release.
Esta política complementa el procedimiento técnico ya documentado en GITFLOW_DETALLADO §3.2 (modelo de ramas bugfix/*-fix-qa y sincronización qa → develop).
Aplica cuando, durante la ejecución de pruebas en nodo-02 (Fase 5 del flujo de entrega), QA Lead reporta uno o más defectos en QA_EXECUTION_REPORT.md que requieren fix antes de que el lote pueda aprobarse.
NO aplica para:
feature/ con merge normal a develop).POLITICA_ROLLBACK.md).| Severidad | Definición | Ejemplo |
|---|---|---|
| Bloqueante | Impide ejecutar otros casos del lote (los datos no se pueden generar, el servicio no levanta, etc.) | Endpoint principal retorna 500 con cualquier payload |
| Crítico | Rompe flujo principal de la HT | Cálculo de causación contable arroja resultado incorrecto |
| Mayor | Afecta flujo secundario o caso edge importante | Validación rechaza payload válido en caso límite |
| Menor | Cosmético, edge poco frecuente, o documentable como deuda | Mensaje de error en idioma incorrecto |
QA Lead clasifica al detectar. Si hay duda, escala a Arquitecto para decisión.
Tiempo máximo desde apertura del issue en GitLab hasta merge del fix a qa.
| Severidad | SLA de fix | Quién lo asume |
|---|---|---|
| Bloqueante | 48 horas hábiles | Backend Sr (asignación inmediata) |
| Crítico | 72 horas hábiles | Backend Sr |
| Mayor | 5 días hábiles o se retira HT del release | Backend Mid/Sr |
| Menor | No requiere fix en sprint actual; se acepta como deuda en QA_CLOSURE.md |
N/A en sprint actual |
SLA del primer reporte por QA:
| Actividad | SLA |
|---|---|
Acuse de recibo del QA_HANDOFF.md por QA Lead |
Mismo día hábil |
| Inicio de ejecución de casos | ≤ 24h tras GATE-D |
| Reporte de primeros defectos bloqueantes | ≤ 48h tras GATE-D |
| Cierre completo del lote (GATE-F) | ≤ 5 días hábiles para lote ≤ 10 HTs; +1 día hábil por cada 5 HTs adicionales |
Para cada defecto bloqueante, crítico o mayor:
QA Lead abre issue en GitLab del repo afectado:
[HT-CON-XXX] <descripción corta>.bug, qa, sprint-N, severity-{bloqueante|critico|mayor|menor}.docker logs <container>), screenshot si aplica.Backend Sr/Mid crea branch desde qa (NO desde develop):
git checkout qa
git pull origin qa
git checkout -b bugfix/HT-CON-XXX-fix-qa-NN
Donde NN es el número de ciclo (01, 02, 03).
Razón de partir desde qa: durante hardening, develop puede tener HTs del sprint siguiente; mergear develop → qa arrastraría esas HT al ambiente QA.
mvn clean verify localmente verde.qabugfix/HT-CON-XXX-fix-qa-NN → qa.Closes #N.qa dispara webhook → Jenkins build → input manual QA Lead → deploy a nodo-02.QA_EXECUTION_REPORT.md columna del ciclo correspondiente.qa → developEn máximo 4 horas hábiles tras el merge a qa:
git checkout develop
git pull origin develop
git merge --no-ff qa -m "sync(qa): incorpora bugfix HT-CON-XXX-fix-qa-NN"
git push origin develop
Esto evita que develop siga avanzando con un bug que ya fue arreglado en qa.
Un "ciclo" se cuenta cada vez que QA reporta defectos sobre el mismo lote y los devs producen un nuevo conjunto de fixes.
| Ciclo | Acción |
|---|---|
| 1 | Ejecución inicial. Si hay defectos, abrir fix branch. |
| 2 | QA re-valida tras fix #1. Si quedan defectos del scope original, continúa ciclo. |
| 3 | QA re-valida tras fix #2. Si quedan defectos, se escala a Arquitecto. |
| 4 (excepcional) | Solo con autorización de Arquitecto + PM. Evaluar si retirar HT del release. |
Regla: tras 3 ciclos consecutivos sin lograr aprobación de una HT, el Arquitecto decide:
QA_CLOSURE.md).QA_CLOSURE.md).| Disparador | Escalación a | Comunicación |
|---|---|---|
| SLA de fix excedido en bloqueante o crítico | Arquitecto + PM | Email + mensaje inmediato |
| 3 ciclos sin aprobación de una HT | Arquitecto + PM + PO | Reunión ad-hoc |
QA Lead detecta defecto crítico no documentado en QA_HANDOFF ni en HTU |
Arquitecto + Backend Lead | Email mismo día |
| Defecto requiere cambio en contrato REST ya validado por frontend | Arquitecto + Sr. Frontend | Reunión coordinación |
| Bug fiscal/contable detectado en QA | Arquitecto + PO + (eventualmente) consultoría contable | Email formal con detalle |
Si QA detecta un bug que no fue introducido por las HTs del sprint actual sino que existe en código previo:
QA_EXECUTION_REPORT §3 separadamente como "defecto heredado".legacy-bug y se prioriza en backlog.nebula-models, nebula-shared, nebula-commons)Si el fix requiere modificar una library compartida:
bugfix/HT-CON-XXX-fix-lib-NN en el repo de la library, partiendo de develop de la lib.develop de la lib → SNAPSHOT publicado a Nexus automáticamente.<nebula-X.version> en el pom del microservicio en branch bugfix/HT-CON-XXX-fix-qa-NN (del microservicio).qa del microservicio.Si durante la Fase 5 del sprint N se requiere un hotfix urgente en PROD (sprint N-1):
hotfix/X.Y.Z → main (ver GITFLOW_DETALLADO §4).main → develop y main → qa para incorporar el fix.Cada QA_EXECUTION_REPORT.md captura las siguientes métricas que alimentan retrospectiva del sprint:
Estas métricas se consolidan trimestralmente para evaluar tendencias y ajustar la política (esta misma) si es necesario.
Los SLAs definidos en §4 son propuestos en la versión 1.0 de esta política. Se revisan:
Cualquier ajuste se versiona en el historial de cambios al final de este documento.
| Versión | Fecha | Autor | Cambio |
|---|---|---|---|
| 1.0 | 2026-05-11 | Carlos Torres | Versión inicial. SLAs propuestos sujetos a ajuste tras piloto sprint-3. |