25. Documentación de pruebas: estrategia, casos, datos, evidencias y resultados
25.1 Introducción
La documentación de pruebas describe cómo se verificará que el sistema cumple sus requisitos y funciona con el nivel de calidad esperado. Permite planificar, ejecutar, registrar y comunicar actividades de validación.
No toda prueba necesita un documento extenso, pero toda estrategia de pruebas necesita claridad. El equipo debe saber qué se prueba, qué no se prueba, con qué datos, en qué ambiente, con qué criterios y cómo se registran resultados.
En este tema veremos documentación de estrategia, alcance, tipos de pruebas, casos, datos, evidencias, resultados, defectos, trazabilidad y automatización.
25.2 Qué es documentación de pruebas
La documentación de pruebas es el conjunto de artefactos que explican y registran la verificación del software. Puede incluir plan de pruebas, estrategia, casos de prueba, datos, scripts, evidencias, reportes, defectos y resultados.
Su propósito es dar visibilidad sobre la calidad del producto. Ayuda a demostrar qué comportamientos fueron verificados, qué riesgos quedan pendientes y qué información respalda una decisión de entrega.
25.3 Elementos de la documentación de pruebas
La imagen muestra los elementos principales de la documentación de pruebas: estrategia, alcance, casos de prueba, datos, ambiente, ejecución, evidencias, defectos, resultados y trazabilidad con requisitos.
25.4 Estrategia de pruebas
La estrategia de pruebas define el enfoque general. Indica qué tipos de pruebas se harán, qué riesgos se priorizarán, qué herramientas se usarán, qué ambientes se necesitan y qué criterios permitirán considerar suficiente la validación.
Por ejemplo, un sistema de turnos puede requerir pruebas funcionales de reserva y cancelación, pruebas de concurrencia para evitar doble reserva, pruebas de seguridad sobre permisos, pruebas de API e integración con notificaciones.
25.5 Alcance y exclusiones
El alcance indica qué funcionalidades, módulos o riesgos serán cubiertos por las pruebas. Las exclusiones indican qué no se probará y por qué. Esta información evita expectativas incorrectas.
Por ejemplo, una entrega puede incluir pruebas completas de reserva de turnos, pero dejar fuera reportes administrativos porque no cambiaron. Si esa decisión no se documenta, puede parecer una omisión accidental.
25.6 Tipos de pruebas
La documentación puede distinguir pruebas unitarias, integración, sistema, aceptación, regresión, rendimiento, seguridad, usabilidad y pruebas exploratorias. Cada tipo responde preguntas distintas.
No todos los proyectos necesitan todos los tipos con la misma profundidad. La selección depende de riesgos, criticidad, arquitectura, equipo y frecuencia de cambios.
25.7 Casos de prueba
Un caso de prueba describe una condición a verificar. Puede incluir identificador, objetivo, requisito asociado, precondiciones, datos, pasos, resultado esperado, resultado obtenido, estado y evidencia.
Los casos de prueba deben ser claros y verificables. Un caso como "probar reserva" es demasiado general. Es mejor indicar "reservar un turno disponible para un paciente autenticado y verificar que queda en estado reservado".
25.8 Datos de prueba
Los datos de prueba son necesarios para ejecutar casos. Pueden incluir usuarios, roles, turnos, profesionales, horarios, configuraciones, archivos, respuestas simuladas o datos sintéticos.
La documentación debe indicar qué datos se necesitan, cómo obtenerlos, si pueden reutilizarse, cómo limpiarlos y si contienen información sensible. No deben usarse datos reales sensibles sin controles adecuados.
25.9 Ambiente de prueba
El ambiente influye en los resultados. La documentación debe indicar dónde se ejecutaron las pruebas: versión del sistema, base de datos, configuración, servicios externos, navegador, dispositivo, sistema operativo o dependencias relevantes.
Sin esta información, puede ser difícil reproducir un error o comparar resultados entre ejecuciones.
25.10 Resultado esperado y resultado obtenido
El resultado esperado describe qué debe ocurrir si el sistema funciona correctamente. El resultado obtenido registra lo que ocurrió realmente. La diferencia entre ambos puede indicar un defecto, una ambigüedad en la especificación o un dato de prueba incorrecto.
Los resultados esperados deben ser concretos. "Funciona bien" no es suficiente. Debe indicarse estado, mensaje, dato creado, respuesta de API, evento generado o cambio visible.
25.11 Evidencias
Las evidencias respaldan la ejecución de pruebas. Pueden ser capturas de pantalla, registros, reportes automáticos, respuestas de API, videos, archivos generados o resultados de herramientas.
No todas las pruebas requieren evidencia pesada. Pero en proyectos críticos, auditorías o validaciones formales, las evidencias pueden ser necesarias para demostrar cumplimiento.
25.12 Defectos
Cuando una prueba falla, se registra un defecto. La documentación del defecto debe incluir descripción, pasos para reproducir, resultado esperado, resultado obtenido, ambiente, severidad, evidencia y relación con requisitos o casos de prueba.
Un defecto bien documentado acelera la corrección. Un defecto vago obliga a repetir preguntas y puede perderse si no se puede reproducir.
25.13 Trazabilidad con requisitos
Las pruebas deben relacionarse con requisitos, reglas o escenarios. Esta trazabilidad permite saber qué necesidades fueron verificadas y cuáles aún no tienen cobertura.
Por ejemplo, el requisito de cancelar un turno hasta 24 horas antes puede tener casos de prueba para cancelación válida, cancelación fuera de plazo, turno ya atendido y usuario sin permisos.
25.14 Tabla de caso de prueba
| Identificador | CP-006 |
|---|---|
| Objetivo | Verificar cancelación válida de turno. |
| Precondiciones | Paciente autenticado con turno reservado para dentro de más de 24 horas. |
| Pasos | Ingresar al detalle del turno, seleccionar cancelar y confirmar. |
| Resultado esperado | El turno queda en estado cancelado y se muestra confirmación. |
25.15 Automatización de pruebas
Las pruebas automatizadas también son documentación. Sus nombres, estructura y datos muestran comportamientos esperados. Sin embargo, deben ser legibles y mantenerse actualizadas.
La documentación puede indicar cómo ejecutar pruebas, qué cubren, qué datos usan, qué reportes generan y qué hacer ante fallas. Esto es útil para desarrollo, integración continua y revisión de calidad.
25.16 Errores frecuentes
Al documentar pruebas suelen aparecer estos errores:
- No definir alcance ni exclusiones.
- Escribir casos de prueba demasiado generales.
- No indicar datos o ambiente de ejecución.
- Omitir resultado esperado verificable.
- Guardar evidencias sin contexto.
- No relacionar pruebas con requisitos.
- No actualizar pruebas cuando cambian reglas funcionales.
25.17 Qué debes recordar de este tema
- La documentación de pruebas da visibilidad sobre la calidad del software.
- Debe incluir estrategia, alcance, casos, datos, ambiente, resultados y evidencias.
- Los casos de prueba deben ser claros y verificables.
- Los datos de prueba deben gestionarse con cuidado, especialmente si son sensibles.
- Las evidencias respaldan la ejecución y el resultado.
- Los defectos deben documentarse para poder reproducirse.
- La trazabilidad conecta pruebas con requisitos y reglas del sistema.
25.18 Conclusión
La documentación de pruebas permite planificar y demostrar cómo se verificó el sistema. Al registrar estrategia, casos, datos, evidencias y resultados, el equipo puede tomar decisiones de entrega con mayor información.
En el próximo tema estudiaremos manuales de usuario y guías paso a paso.