Integración de QA con GitScrum
Construye calidad en tu proceso de desarrollo. Integra QA perfectamente con los flujos de trabajo de desarrollo para releases más rápidos y confiables.
9 min de lectura
La calidad no es una fase - está integrada en cada paso. GitScrum ayuda a los equipos a integrar QA a lo largo del ciclo de vida del desarrollo con flujos de testing, seguimiento de bugs y métricas de calidad que detectan problemas temprano.
QA en Ágil
Testing Shift-Left
ENFOQUE DE TESTING SHIFT-LEFT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRADICIONAL (Pesado a la derecha): │
│ │
│ [Requisitos]→[Diseño]→[Desarrollo]→[Testing]→[Release] │
│ ▲ │
│ │ │
│ Todo testing │
│ ocurre aquí │
│ (bugs costosos) │
│ │
│ SHIFT-LEFT (Continuo): │
│ │
│ [Requisitos]→[Diseño]→[Desarrollo]→[Testing]→[Release] │
│ ▲ ▲ ▲ ▲ │
│ │ │ │ │ │
│ Revisar Revisar Testing Validación │
│ y test diseños durante final │
│ criterios temprano dev │
│ │
│ BENEFICIOS: │
│ • Bugs encontrados antes = más baratos de arreglar │
│ • Calidad construida, no testeada después │
│ • Ciclos de release más rápidos │
│ • Menos retrabajo │
│ │
│ COSTO DE BUG POR FASE: │
│ Requisitos: $1 │
│ Diseño: $5 │
│ Desarrollo: $10 │
│ Testing: $20 │
│ Producción: $100+ │
└─────────────────────────────────────────────────────────────┘
Rol de QA en el Sprint
QA A LO LARGO DEL SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANIFICACIÓN DE SPRINT: │
│ • QA revisa historias próximas │
│ • Clarificar criterios de aceptación │
│ • Identificar complejidad de testing │
│ • Estimar esfuerzo de testing │
│ • Señalar riesgos potenciales │
│ │
│ INICIO DEL SPRINT: │
│ • Escribir casos de prueba para items del sprint │
│ • Revisar diseños para testabilidad │
│ • Configurar datos/entornos de prueba │
│ • Planificación de automatización │
│ │
│ MITAD DEL SPRINT: │
│ • Probar features conforme se completan │
│ • Reportar bugs inmediatamente │
│ • Verificar correcciones de bugs │
│ • Testing exploratorio │
│ • Actualizar casos de prueba según se necesite │
│ │
│ FINAL DEL SPRINT: │
│ • Testing de regresión │
│ • Testing de integración │
│ • Verificaciones puntuales de rendimiento │
│ • Aprobación de items completados │
│ │
│ FIN DE SPRINT: │
│ • Validación de release │
│ • Participación en demo │
│ • Input de retro sobre calidad │
│ │
│ CLAVE: Sin "fase de testing" - testing es continuo │
└─────────────────────────────────────────────────────────────┘
Integración de Flujo de Trabajo
Ciclo de Vida de Historia
QA EN FLUJO DE TRABAJO DE HISTORIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BACKLOG → DEV → CODE REVIEW → QA → DONE │
│ │
│ BACKLOG: │
│ ☐ Criterios de aceptación definidos │
│ ☐ QA revisó y acordó │
│ ☐ Enfoque de testing identificado │
│ │
│ EN DESARROLLO: │
│ ☐ Desarrollador ejecuta unit tests │
│ ☐ Happy path básico verificado │
│ ☐ PR incluye cobertura de tests │
│ │
│ CODE REVIEW: │
│ ☐ Tests revisados con código │
│ ☐ Requisitos de cobertura cumplidos │
│ ☐ Todas las verificaciones pasando │
│ │
│ TESTING QA: │
│ ☐ Criterios de aceptación verificados │
│ ☐ Casos edge testeados │
│ ☐ Regresión verificada │
│ ☐ Cross-browser si aplica │
│ ☐ Aprobación de QA dada │
│ │
│ DONE: │
│ ☐ Todos los criterios cumplidos │
│ ☐ Sin bugs abiertos │
│ ☐ Documentación actualizada │
│ ☐ Listo para release │
│ │
│ RUTA BLOQUEADA: │
│ Si QA encuentra problemas → Volver a Desarrollo │
│ Debe arreglarse antes de Done │
└─────────────────────────────────────────────────────────────┘
Flujo de Trabajo de Bugs
FLUJO DE TRACKING DE BUGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BUG ENCONTRADO → TRIAGE → DEV → VERIFICAR → CERRADO │
│ │
│ FORMATO DE REPORTE DE BUG: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TÍTULO: [Área] Descripción clara del problema ││
│ │ ││
│ │ SEVERIDAD: Crítico/Alto/Medio/Bajo ││
│ │ ENTORNO: Producción/Staging/Dev ││
│ │ NAVEGADOR/DISPOSITIVO: Chrome 120, macOS ││
│ │ ││
│ │ PASOS PARA REPRODUCIR: ││
│ │ 1. Ir a página de checkout ││
│ │ 2. Agregar item al carrito ││
│ │ 3. Clic en "Aplicar cupón" ││
│ │ ││
│ │ ESPERADO: Descuento aplicado al total ││
│ │ ACTUAL: Mensaje de error "Cupón inválido" ││
│ │ ││
│ │ SCREENSHOT: [adjunto] ││
│ │ ERRORES DE CONSOLA: [adjunto] ││
│ │ HISTORIA RELACIONADA: #123 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINICIONES DE SEVERIDAD: │
│ Crítico: Sistema caído, pérdida de datos, seguridad │
│ Alto: Feature principal rota, sin workaround │
│ Medio: Feature afectada, workaround existe │
│ Bajo: Problema menor, cosmético, caso edge │
│ │
│ SLA POR SEVERIDAD: │
│ Crítico: Arreglar inmediatamente, mismo día │
│ Alto: Arreglar dentro del sprint │
│ Medio: Arreglar dentro de 2 sprints │
│ Bajo: Backlog, arreglar cuando sea conveniente │
└─────────────────────────────────────────────────────────────┘
Prácticas de Testing
Tipos de Tests
PIRÁMIDE DE TESTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ /\ │
│ / \ │
│ / E2E \ Lentos, costosos, pocos │
│ /──────\ │
│ / \ │
│ / Integración\ Velocidad media, más │
│ /──────────────\ │
│ / \ │
│ / Unit Tests \ Rápidos, baratos, muchos│
│ /────────────────────\ │
│ │
│ UNIT TESTS (70-80%): │
│ • Rápidos de ejecutar │
│ • Testean componentes individuales │
│ • Escritos por desarrolladores │
│ • Ejecutan en cada commit │
│ │
│ TESTS DE INTEGRACIÓN (15-20%): │
│ • Testean interacciones de componentes │
│ • Testing de API │
│ • Integración con base de datos │
│ • Ejecutan en PR/merge │
│ │
│ TESTS E2E (5-10%): │
│ • Testean flujos completos de usuario │
│ • Testing de navegador/UI │
│ • Lentos, ejecutar menos frecuentemente │
│ • Solo rutas críticas │
│ │
│ ADEMÁS: │
│ • Testing exploratorio (manual, liderado por QA) │
│ • Testing de rendimiento (periódico) │
│ • Testing de seguridad (periódico) │
└─────────────────────────────────────────────────────────────┘
Testing de Aceptación
TESTING DE CRITERIOS DE ACEPTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HISTORIA: Usuario puede aplicar cupón de descuento │
│ │
│ CRITERIOS DE ACEPTACIÓN: │
│ │
│ AC1: Cupón válido reduce total │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DADO QUE tengo items en carrito totalizando $100 ││
│ │ CUANDO ingreso cupón válido "SAVE20" ││
│ │ ENTONCES el total muestra $80 ││
│ │ Y mensaje "Descuento 20% aplicado" se muestra ││
│ │ ││
│ │ RESULTADO DEL TEST: ✅ PASA ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AC2: Cupón inválido muestra error │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DADO QUE estoy en checkout ││
│ │ CUANDO ingreso cupón inválido "EXPIRED" ││
│ │ ENTONCES error "Cupón no válido" se muestra ││
│ │ Y el total permanece sin cambios ││
│ │ ││
│ │ RESULTADO DEL TEST: ✅ PASA ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AC3: Un cupón por orden │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DADO QUE cupón ya está aplicado ││
│ │ CUANDO intento agregar otro cupón ││
│ │ ENTONCES "Solo un cupón por orden" se muestra ││
│ │ ││
│ │ RESULTADO DEL TEST: ❌ FALLA ││
│ │ BUG: Segundo cupón reemplaza primero sin mensaje ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESTADO DE HISTORIA: Bloqueada - Bug encontrado en AC3 │
└─────────────────────────────────────────────────────────────┘
Métricas de Calidad
Rastreando Calidad
DASHBOARD DE MÉTRICAS DE CALIDAD:
┌─────────────────────────────────────────────────────────────┐
│ Reporte de Calidad Sprint 24 │
├─────────────────────────────────────────────────────────────┤
│ │
│ MÉTRICAS DE BUGS: │
│ ├── Bugs encontrados en sprint: 12 │
│ ├── Bugs arreglados en sprint: 15 │
│ ├── Tasa de escape de bugs: 2 (llegaron a producción) │
│ └── Bugs críticos: 0 ✅ │
│ │
│ TENDENCIA DE BUGS: │
│ Bugs│ │
│ 20│ ▄ │
│ 15│ █ ▄ │
│ 10│ █ █ ▄ ▄ │
│ 5│ █ █ █ ▄ █ ▄ │
│ 0└───────────────── │
│ S19 S20 S21 S22 S23 S24 │
│ │
│ COBERTURA DE TESTS: │
│ ├── Cobertura unit tests: 78% (+3%) │
│ ├── Tests de integración: 45 pasando │
│ ├── Tests E2E: 12 pasando, 1 flaky │
│ └── Cobertura código nuevo: 85% │
│ │
│ TIEMPO DE CICLO: │
│ ├── Tiempo promedio de Ready a QA: 2.5 días │
│ ├── Tiempo promedio en QA: 0.8 días │
│ └── Tiempo promedio corrección bug: 4 horas │
│ │
│ RECOMENDACIONES: │
│ • Investigar test E2E flaky │
│ • Cobertura de unit por debajo del objetivo 80% │
│ • Tasa de escape de bugs mejoró del sprint anterior │
└─────────────────────────────────────────────────────────────┘