# Proceso de Corrección de Bugs en Fábrica de Software

## Flujo General

```
QA detecta → PO prioriza → Tech Lead analiza → Dev corrige → QA valida → DevOps despliega → QA cierra
```

---

## 1. QA / Tester

| Actividad | Entregable |
|-----------|------------|
| Detectar y reproducir el bug | Pasos de reproducción |
| Documentar evidencia | Screenshots, logs, ambiente |
| Registrar en sistema de tracking | Ticket con severidad y prioridad |
| Clasificar impacto | Crítico / Alto / Medio / Bajo |

### Plantilla de Ticket

```
ID: BUG-XXX
Título: [Descripción breve del bug]
Severidad: [Crítica | Alta | Media | Baja]
Ambiente: [Desarrollo | QA | Staging | Producción]

Pasos para reproducir:
1. [Paso 1]
2. [Paso 2]
3. [Paso 3]

Resultado esperado:
[Descripción del comportamiento correcto]

Resultado actual:
[Descripción del comportamiento incorrecto]

Evidencia:
[Screenshots, logs, videos]

Componente afectado:
[Módulo / Servicio / Endpoint]
```

---

## 2. Product Owner / Analista

| Actividad | Entregable |
|-----------|------------|
| Validar impacto en negocio | Usuarios afectados |
| Priorizar en backlog | Posición en sprint |
| Definir criterios de aceptación | AC claros y verificables |
| Aprobar solución propuesta | Sign-off |

### Criterios de Priorización

| Severidad | Tiempo de Respuesta | Ejemplos |
|-----------|---------------------|----------|
| **Crítica** | Inmediato (< 4h) | Sistema caído, pérdida de datos, seguridad |
| **Alta** | 24-48 horas | Funcionalidad core bloqueada |
| **Media** | Sprint actual | Funcionalidad degradada con workaround |
| **Baja** | Backlog | Cosméticos, mejoras menores |

---

## 3. Tech Lead / Arquitecto

| Actividad | Entregable |
|-----------|------------|
| Análisis de causa raíz | Identificar origen del bug |
| Evaluar impacto técnico | Componentes afectados |
| Definir estrategia de solución | Enfoque técnico |
| Estimar esfuerzo | Story points / horas |
| Asignar a desarrollador | Responsable |

### Técnicas de Análisis de Causa Raíz

1. **5 Whys**: Preguntar "¿por qué?" hasta llegar a la raíz
2. **Diagrama de Ishikawa**: Categorizar causas potenciales
3. **Revisión de logs**: Trazabilidad del error
4. **Debugging**: Reproducir en ambiente controlado

---

## 4. Desarrollador

| Actividad | Entregable |
|-----------|------------|
| Reproducir en ambiente local | Confirmación del bug |
| Implementar corrección | Código + tests |
| Code review | PR aprobado |
| Documentar cambios | Changelog / comentarios |

### Checklist del Desarrollador

- [ ] Bug reproducido localmente
- [ ] Causa raíz identificada
- [ ] Solución implementada
- [ ] Tests unitarios agregados/actualizados
- [ ] Tests de regresión pasan
- [ ] Code review solicitado
- [ ] PR aprobado
- [ ] Documentación actualizada (si aplica)

### Convención de Commits

```
fix(módulo): descripción breve del fix

Descripción detallada del problema y la solución.

Fixes: #TICKET-ID
```

---

## 5. QA (Post-fix)

| Actividad | Entregable |
|-----------|------------|
| Verificar corrección en QA/Staging | Test passed |
| Ejecutar regresión | Sin efectos colaterales |
| Aprobar para producción | Sign-off QA |

### Checklist de Validación

- [ ] Bug original corregido
- [ ] Casos de borde probados
- [ ] Regresión ejecutada
- [ ] Performance no degradada
- [ ] Sin nuevos defectos introducidos

---

## 6. DevOps / SRE

| Actividad | Entregable |
|-----------|------------|
| Desplegar a producción | Release ejecutado |
| Monitorear post-deploy | Métricas estables |
| Rollback si es necesario | Plan B listo |

### Checklist de Despliegue

- [ ] Build exitoso
- [ ] Tests CI/CD pasan
- [ ] Backup realizado (si aplica)
- [ ] Deployment ejecutado
- [ ] Health checks OK
- [ ] Métricas monitoreadas (15 min)
- [ ] Rollback plan documentado

---

## 7. QA (Validación Producción)

| Actividad | Entregable |
|-----------|------------|
| Smoke test en producción | Bug corregido |
| Cerrar ticket | Evidencia adjunta |
| Actualizar documentación | Si aplica |

### Cierre del Ticket

```
Estado: CERRADO
Resolución: Corregido
Versión: [v1.2.3]
Fecha de cierre: [YYYY-MM-DD]
Validado por: [Nombre QA]
Evidencia: [Link a screenshot/video]
```

---

## Métricas de Seguimiento

| Métrica | Descripción | Meta |
|---------|-------------|------|
| **MTTR** | Mean Time To Repair | < 24h (críticos) |
| **Escape Rate** | Bugs que llegan a producción | < 5% |
| **Reopen Rate** | Bugs reabiertos | < 10% |
| **First Time Fix** | Bugs corregidos al primer intento | > 85% |

---

## Ejemplo Práctico

### Bug: URL de activación apunta a localhost en producción

**Ticket:**
```
ID: BUG-001
Título: URL de activación apunta a localhost en producción
Severidad: Media
Ambiente: Producción

Pasos para reproducir:
1. Login como admin en https://academia.ingeniumcodex.com
2. Crear nuevo estudiante
3. Observar la URL de activación generada

Resultado esperado:
https://academia.ingeniumcodex.com/activate?code=XXX

Resultado actual:
http://localhost:4200/activate?code=XXX
```

**Análisis de Causa Raíz:**
- Código usa fallback `localhost:4200` cuando `App:BaseUrl` no está configurado
- Variable de entorno faltante en deployment de producción

**Solución:**
- Agregar `App__BaseUrl` en `deploy/k3s/api.yaml`
- Agregar `APP_BASE_URL` en `deploy/docker/docker-compose.yml`

**Commit:**
```
fix(deploy): add App__BaseUrl env var for activation URLs
```

**Validación:**
- Nueva URL generada: `https://academia.ingeniumcodex.com/activate?code=XXX`
- Ticket cerrado con evidencia