Por Qué la Estimación Importa
Cada sprint planning incluye la pregunta: “¿Cuánto tomará el testing?” Equivocarse tiene consecuencias reales:
- Subestimar: Testing apresurado, bugs escapan a producción, equipo agotado
- Sobreestimar: Presupuesto desperdiciado, credibilidad afectada, features retrasados
Factores que Afectan las Estimaciones
| Factor | Impacto |
|---|---|
| Complejidad del feature | Más complejo = más casos de prueba, más edge cases |
| Experiencia del equipo | Equipo nuevo o dominio nuevo = testing más largo |
| Calidad de requisitos | Requisitos vagos = más testing exploratorio y retrabajo |
| Madurez de automatización | Más automatización = menos ejecución manual |
| Estabilidad del entorno | Entornos inestables = testing bloqueado |
| Dependencias | Servicios externos, otros equipos = tiempo de espera |
| Densidad de defectos | Más bugs = más retesting y regresión |
Técnicas de Estimación
1. Work Breakdown Structure (WBS)
WBS divide el testing en tareas más pequeñas y estimables.
Pasos: 1) Listar todas las actividades 2) Dividir en sub-tareas 3) Estimar cada una en horas 4) Sumar
Ejemplo:
| Actividad | Sub-tareas | Horas |
|---|---|---|
| Revisión de requisitos | Revisar 20 user stories, escribir criterios | 12 |
| Diseño de casos | Funcionales (40), negativos (20), datos | 28 |
| Ejecución de tests | Manual (60 casos) + automatizado | 32 |
| Gestión de bugs | Registrar, verificar, reprobar (~15 bugs) | 12 |
| Regresión | Suite de regresión | 8 |
| Reportes | Estado diario, reporte final | 4 |
| Total | 96h (12 días) |
2. Three-Point Estimation (PERT)
Usa tres valores: O (Optimista), M (Más Probable), P (Pesimista).
Fórmula: Estimación = (O + 4M + P) / 6
| Tarea | O | M | P | PERT |
|---|---|---|---|---|
| Diseño de casos | 12h | 16h | 28h | 17.3h |
| Ejecución | 16h | 24h | 40h | 25.3h |
| Gestión de bugs | 4h | 12h | 24h | 12.7h |
| Regresión | 4h | 8h | 16h | 8.7h |
| Total | 64h (8 días) |
3. Wideband Delphi
Técnica de consenso donde múltiples expertos estiman independientemente.
Pasos:
- Presentar el scope a 3-5 expertos
- Cada uno estima independientemente (sin discusión)
- Recopilar estimaciones anónimamente
- Revelar todas simultáneamente
- Discutir valores extremos
- Re-estimar (independientemente)
- Repetir hasta convergencia (2-3 rondas)
4. Método de Puntos de Caso de Uso
Estima basándose en número y complejidad de casos de uso.
| Complejidad | Cantidad | Peso | Puntos |
|---|---|---|---|
| Simple | 5 | 5 | 25 |
| Medio | 8 | 10 | 80 |
| Complejo | 3 | 15 | 45 |
| Total | 150 |
Ajustado: 150 × factor de complejidad × productividad = horas de testing
5. Datos Históricos (Basado en Analogía)
Usar datos de proyectos similares anteriores.
Ejemplo: “El módulo de login en el Proyecto A tomó 5 días. Este módulo es similar pero agrega autenticación de dos factores. Estimación: 7 días.”
Precisión de Estimación en el Tiempo
±50%] --> E2[Post-Requisitos
±25%] E2 --> E3[Post-Diseño
±15%] E3 --> E4[Durante Testing
±5%] end style E1 fill:#F44336,color:#fff style E2 fill:#FF9800,color:#fff style E3 fill:#FFC107,color:#000 style E4 fill:#4CAF50,color:#fff
Las estimaciones tempranas son inherentemente menos precisas. Proporciona rangos, no números únicos.
Ejercicio: Estimar Esfuerzo Usando Dos Técnicas
Eres QA lead de un proyecto para construir un sistema de reservas de hotel. Features:
- Registro y login (con login social)
- Búsqueda de hoteles (ubicación, fechas, precio, rating)
- Reserva con pago (tarjeta, PayPal)
- Gestión de reservas (ver, modificar, cancelar)
- Sistema de reviews
- Panel de administración
Equipo: 2 QA (1 senior, 1 mid), experiencia en e-commerce pero no en reservas de hotel.
Tu tarea:
- Estimar usando WBS
- Estimar usando Three-Point
- Comparar y explicar cuál presentarías
- Listar 3 riesgos
Pista
Testing de pagos necesita tiempo extra para seguridad. Login social tiene dependencias externas. La búsqueda necesita testing de rendimiento. No olvides regresión y configuración de entorno.
Solución de Ejemplo
WBS: 198h (~25 días)
| Actividad | Horas |
|---|---|
| Revisión de requisitos + criterios | 20 |
| Diseño de casos (105 casos) | 56 |
| Preparación de datos | 8 |
| Ejecución (funcional + seguridad + rendimiento + cross-browser) | 76 |
| Gestión de bugs (~25 bugs) | 16 |
| Regresión (2 ciclos) | 16 |
| Reportes | 6 |
Three-Point: 189h (~24 días)
Rango con 95% confianza: 127-251h (16-31 días)
Presentar como: “24-25 días de trabajo, con rango de 20-31 días según densidad de defectos y estabilidad del entorno.”
Riesgos:
- Problemas de integración con gateway de pagos
- Mayor densidad de defectos de lo esperado
- Cambios en APIs de login social
Errores Comunes
- Olvidar tareas no-testing: Setup de entorno, reuniones, documentación
- Estimar solo happy paths: Testing negativo toma tanto tiempo como el positivo
- Ignorar regresión: Cada fix necesita regresión
- Estimaciones de número único: Siempre da rangos
- No rastrear resultados reales: Sin datos históricos, las estimaciones nunca mejoran
Consejos Pro
Rastrea estimaciones vs. reales. Después de cada proyecto, compara. Esto construye precisión con el tiempo.
Agrega buffer para incertidumbre. Para dominios nuevos: 20-30%. Para terreno conocido: 10-15%.
Presenta rangos, no puntos. “Estimamos 15-20 días” es más honesto que “Estimamos 17.3 días.”
Usa Wideband Delphi para estimaciones importantes. Cuando la estimación determina presupuesto o headcount, involucra múltiples expertos.
Estima testing durante planificación, no después. Si estimas después de que inicia el desarrollo, ya estás atrasado.