228 lines
5.5 KiB
Markdown
228 lines
5.5 KiB
Markdown
|
# 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
|