Cada proyecto de software llega a un momento crítico: decidir si el producto está listo para salir a producción. Esa decisión no puede basarse en intuición ni en frases como "la app se siente más estable". Necesita evidencia concreta y rastreable. El reporte de cierre de pruebas —o Test Summary Report— es exactamente eso: el documento que confronta lo planificado contra lo ejecutado y transforma números en una recomendación fundamentada. Si el plan de pruebas era el plano de la casa, el reporte de cierre es la inspección final antes de entregar las llaves [0:18].
¿Qué bloques componen un reporte de cierre de pruebas?
El Test Summary Report se estructura en cuatro bloques esenciales [0:33] que, en conjunto, ofrecen una radiografía completa del ciclo de pruebas.
¿Cómo se interpreta el resumen de ejecución?
El primer bloque es el resumen de ejecución: cuántos casos se planificaron, cuántos se corrieron, cuántos pasaron, cuántos fallaron y cuántos quedaron en error. Funciona como una boleta escolar: no basta saber que el alumno asistió, importa cómo le fue en cada materia.
¿Por qué el estado de defectos va más allá de contar bugs?
El segundo bloque agrupa los defectos por severidad y prioridad, pero además muestra su estado dentro del ciclo de vida: cerrados, reabiertos, diferidos o abiertos [0:55]. Un defecto diferido es una decisión consciente: el equipo sabe que existe y elige no corregirlo en este momento. Un defecto abierto, en cambio, representa riesgo activo que debe evaluarse antes de liberar.
¿Qué revela la cobertura y qué oculta?
El tercer bloque mide qué porcentaje del sistema ejercitaron las pruebas. Aquí hay una trampa común: ejecutar el cien por ciento de los casos planificados no garantiza que se cubrió todo [1:12]. El plan mismo podría tener huecos. Es como pintar una pared: la cobertura indica qué secciones recibieron pintura y cuáles quedaron sin ella.
El cuarto bloque registra desviaciones: un ambiente caído, un requisito que cambió tarde o un bloqueo técnico. Cada desviación se documenta con qué pasó, cuándo ocurrió y qué impacto tuvo.
¿Cómo se conectan los criterios de salida con la evidencia real?
Tener los cuatro bloques completos no responde la pregunta más importante: ¿alcanza para liberar? Aquí el reporte se enlaza directamente con el plan de pruebas, específicamente con los criterios de salida —condiciones medibles para declarar las pruebas completas— [1:42].
El reporte toma cada criterio y lo enfrenta con la evidencia. Si el plan exigía "noventa y cinco por ciento de aprobación y cero críticos abiertos", el reporte responde con datos: tasa de aprobación al noventa y seis por ciento, críticos abiertos en cero. Ambos cumplidos. La decisión de release tiene respaldo documental, no opinión.
Cuando un criterio no se cumple, se declara de forma explícita: ¿se aceptó el riesgo?, ¿se extendió el ciclo?, ¿se redujo el alcance? Lo que separa un reporte útil de uno mediocre es el riesgo residual por área [2:10]. Decir "quedan doce defectos abiertos" aporta poco. Decir "ocho de esos doce están en el módulo de pagos" cambia por completo la conversación. Se aplica la fórmula de probabilidad por impacto, pero ahora después de probar, para calcular cuánto redujo la probabilidad lo que se ejecutó.
¿Qué hacer con las pruebas que nunca se ejecutaron?
Este es el punto que más incomodidad genera y que muchos reportes omiten [2:42]. Si de ochenta casos planificados seis nunca se corrieron, esos seis representan territorio desconocido: un punto ciego que impacta directamente la decisión de release.
- Si los casos sin ejecutar cubren funcionalidad crítica como pagos, un smoke test no basta para justificar la liberación.
- Si cubren áreas de baja prioridad y todo lo de alto riesgo pasó, la decisión se defiende con mayor facilidad.
- Cualquier liberación con pruebas sin ejecutar debe ser decisión consciente y documentada.
Un ejemplo práctico lo ilustra bien [3:05]: plataforma de comercio electrónico con ochenta casos, setenta y cuatro ejecutados y sesenta y ocho aprobados. La tasa de aprobación queda en noventa y uno punto nueve por ciento, pero el criterio pedía noventa y cinco. No se cumple. Dos defectos altos diferidos en búsqueda y seis casos sin ejecutar en reportes por ambiente no disponible. La acción correcta es:
- Declarar el incumplimiento.
- Mapear el riesgo residual por área: pagos bajo, búsqueda medio, reportes desconocido.
- Recomendar un ciclo de verificación antes de habilitar reportes a todos los usuarios.
Antes de entregar cualquier reporte, verifica tres cosas [3:50]:
- Un lector puede ver exactamente qué áreas fueron cubiertas y cuáles no.
- Cada defecto abierto muestra severidad, prioridad y estado.
- Cada dato se puede rastrear a un caso de prueba concreto.
Sin rastreabilidad, el reporte pierde su valor como evidencia y se convierte en simple narrativa. Y este documento no es el paso final: es el insumo para las notas de release, que deben construirse con hechos documentados [4:15]. Decir "el bug X que bloqueaba checkout en móviles fue corregido en el build 3.4" es evidencia. Decir "la app se siente más estable" es opinión.
¿Podrías construir hoy una tabla de riesgo residual por área en tu proyecto? Comparte tu experiencia y las dificultades que encuentras al documentar lo que no se probó.
