Rol de QA en Gestión de Releases
La gestión de releases es el proceso de planificar, programar y controlar liberaciones de software. QA es central — no como un bloqueador, sino como asesor de calidad que proporciona recomendaciones basadas en datos.
Checklist de Release
Pre-Release
- Todos los tests automatizados pasan
- Cobertura de código cumple el umbral mínimo
- Sin bugs críticos o de alta severidad abiertos
- Tests de performance sin regresión
- Escaneo de seguridad sin vulnerabilidades críticas
- Migraciones de BD testeadas y reversibles
- Plan de rollback documentado y testeado
- Ingeniero de guardia identificado
Durante Release
- Health checks pasando en todas las instancias
- Smoke tests ejecutados contra producción
- Métricas clave dentro de rangos normales
Post-Release
- Suite completa de smoke tests pasada
- Métricas de negocio dentro de rangos esperados
- Monitoreo sintético todo verde
- Release marcado como exitoso o rollback iniciado
Criterios Go/No-Go
| Métrica | Umbral Go | Umbral No-Go |
|---|---|---|
| Tasa de éxito de tests | ≥ 99% | < 95% |
| Bugs críticos | 0 | > 0 |
| Cobertura de código | ≥ 80% | < 70% |
| Regresión de performance | < 5% | > 15% |
| Vulnerabilidades críticas | 0 | > 0 |
Planes de Rollback
Cada release debe tener un plan que responda: cuándo, cómo, quién decide, comunicación y verificación.
Ejercicio: Crea un Checklist de Release
Tu equipo libera una actualización mayor con: nueva integración de proveedor de pagos, checkout rediseñado y migración de schema de BD.
Solución
T-7 Días
- Feature freeze
- Regresión completa en staging
- Testing de sandbox de pagos completado
- Migración de BD testeada con dataset de tamaño producción
- Load test: 2x tráfico normal de checkout
T-1 Día
- Reunión go/no-go
- Resultados de tests revisados: 100% pass rate
- Equipo de soporte informado
Día del Release
- Despliegue durante ventana de mantenimiento
- Canary 1% → 10% → 50% → 100%
- Monitorear en cada fase
Post-Release (48 Horas)
- Tasa de éxito de pagos ≥ 99.5%
- Conversión de checkout dentro de 5% del baseline
- Marcar release como exitoso
Conclusiones Clave
- Los checklists previenen error humano
- Criterios go/no-go deben ser predefinidos y medibles
- Cada release necesita un plan de rollback — testeado antes, no improvisado
- La validación post-release es obligatoria
- QA es asesor de calidad, no bloqueador