Gestión de Actividades de Prueba — Apuntes CTFL v4.0 (capítulo 5)

Planificación de Pruebas

El Plan de Pruebas es dinámico y debe actualizarse. Documenta alcance, recursos, presupuesto, riesgos, estrategia.
Estrategias de prueba: Analítica (basada en riesgo), Metódica (listas estándar), Reactiva (exploratoria), Consultiva (preguntar a expertos), Basada en modelos.
Criterios de Entrada (Entry Criteria): ¿Cuándo podemos empezar? (Ej. entorno disponible, código compilado).
Criterios de Salida (Exit Criteria): ¿Cuándo terminamos? (Ej. 100% riesgos cubiertos, presupuesto agotado, sin bugs severos abiertos).

Estimación y Priorización

Estimación basada en métricas: Datos históricos de proyectos anteriores o métricas como Puntos de Función.
Estimación basada en expertos: Planning Poker en equipos ágiles o Delphi de banda ancha.
Priorización de pruebas: ¿Qué ejecutar primero? Según riesgo, valor de negocio o dependencias lógicas. En Ágil, priorizan las historias de usuario de mayor valor.

Pirámide de Pruebas

Modelo que promueve tener muchísimas pruebas unitarias en la base (rápidas, baratas, aisladas).
Menos pruebas en la capa media de integración/API.
Muy pocas pruebas de UI (Interfaz de Usuario) en la punta, por ser frágiles, lentas y caras de mantener.

Gestión de Riesgos

Nivel de Riesgo = Probabilidad × Impacto.
Riesgo de Producto (Calidad): Funciones que fallan, vulnerabilidades de seguridad, la app crashea, mal rendimiento.
Riesgo de Proyecto (Proceso): Falta de presupuesto, testers enfermos, retrasos del entorno, problemas de herramientas.
El Testing es una forma primordial de mitigar los riesgos de PRODUCTO.

Reportes e Información de Defectos

Tipos de reporte: Progreso (durante la iteración) y Resumen (al final).
Métricas comunes: Cobertura de requisitos, progreso de ejecución, tiempo promedio de reparación.
Un reporte de defecto debe incluir: ID, título, severidad/prioridad, pasos detallados para reproducir, resultado esperado vs actual, y logs/capturas.
Severidad (impacto técnico) ≠ Prioridad (importancia de negocio). Un defecto cosmético en el logo puede ser Severidad Baja pero Prioridad Alta.

Gestión de la Configuración

Garantiza la trazabilidad e integridad de todos los artefactos.
Asegura que probemos la versión 1.2 del software con la base de datos 1.2 y el test plan v2.
Sin gestión de configuración, los testers podrían probar versiones antiguas del código por error.

Siguiente paso

Ahora toca comprobar si se ha quedado: entra en el simulador, filtra por el capítulo 5 y haz una tanda de diez preguntas. Cada respuesta incluye la justificación completa.

El syllabus oficial completo del CTFL v4.0 se descarga gratis desde istqb.org, y los términos están definidos en el glosario oficial.