37. Derivación de casos de prueba desde casos de uso
37.1 Introducción
Un caso de uso bien escrito no solo sirve para analizar y diseñar. También es una base muy útil para definir casos de prueba. Cada flujo, regla, excepción y resultado esperado puede transformarse en una verificación concreta.
La derivación de pruebas desde casos de uso ayuda a comprobar que el sistema cumple el comportamiento acordado. También permite detectar huecos en la especificación: si no se puede probar un paso o una postcondición, probablemente falta precisión.
En este tema veremos cómo pasar desde una especificación funcional a pruebas claras, trazables y orientadas al usuario.
37.2 Qué es un caso de prueba
Un caso de prueba describe una situación que se ejecuta para verificar un comportamiento esperado del sistema. Suele incluir precondiciones, datos de entrada, pasos, resultado esperado y estado final.
Por ejemplo, para el caso de uso Solicitar turno, un caso de prueba puede verificar que un paciente registrado logra reservar un horario disponible y recibe una confirmación.
37.3 Por qué derivar pruebas desde casos de uso
Los casos de uso describen comportamiento desde la perspectiva del actor. Por eso son una fuente natural para pruebas funcionales y pruebas de aceptación.
Derivar pruebas desde ellos permite:
- Verificar el flujo principal.
- Probar variantes y decisiones del usuario.
- Comprobar excepciones y recuperación.
- Validar reglas de negocio.
- Confirmar postcondiciones y resultados observables.
- Mantener trazabilidad entre análisis y pruebas.
37.4 Del caso de uso al conjunto de pruebas
Un caso de uso puede generar varias pruebas. El flujo principal produce una prueba de camino exitoso. Cada flujo alternativo importante produce una prueba adicional. Cada excepción relevante produce una prueba de error o recuperación. Las reglas de negocio y postcondiciones generan verificaciones específicas.
37.5 Prueba del flujo principal
La primera prueba suele corresponder al flujo principal. Verifica que, bajo condiciones normales, el actor puede lograr el objetivo y el sistema alcanza la postcondición de éxito.
Ejemplo para Solicitar turno:
Precondición: el paciente está registrado y existe un horario disponible.
Pasos: el paciente busca disponibilidad, selecciona un horario y confirma la reserva.
Resultado esperado: el turno queda reservado y el sistema muestra confirmación.
37.6 Pruebas de flujos alternativos
Cada flujo alternativo relevante debe transformarse en una prueba. Si el caso de uso permite buscar por profesional en lugar de especialidad, esa variante debe verificarse.
Ejemplo:
Precondición: existe un profesional con horarios disponibles.
Pasos: el paciente elige buscar por profesional, selecciona un profesional y confirma un horario.
Resultado esperado: el sistema reserva el turno con el profesional seleccionado.
37.7 Pruebas de excepciones
Las excepciones documentadas deben generar pruebas. Estas pruebas verifican que el sistema responda correctamente ante errores, condiciones no permitidas o fallas externas.
Ejemplo:
Precondición: el horario aparece disponible inicialmente.
Situación: otro usuario reserva el mismo horario antes de la confirmación.
Resultado esperado: el sistema informa que el horario ya no está disponible y ofrece elegir otro.
37.8 Pruebas de reglas de negocio
Las reglas de negocio deben probarse explícitamente. Si una regla impide una operación, debe existir una prueba que intente violarla y verifique que el sistema la bloquea.
Ejemplo:
Prueba: intentar reservar un segundo turno con el mismo profesional y fecha.
Resultado esperado: el sistema rechaza la reserva e informa la regla aplicada.
37.9 Pruebas de postcondiciones
Las postcondiciones indican qué debe quedar verdadero al finalizar. Cada postcondición importante debe tener una verificación.
Ejemplos:
- Verificar que el turno quedó asociado al paciente correcto.
- Verificar que el horario ya no aparece como disponible.
- Verificar que se generó una confirmación.
- Verificar que no quedó una reserva incompleta si la operación falló.
37.10 Pruebas de datos de entrada
Los datos de entrada permiten definir pruebas con valores válidos, inválidos, faltantes y límites.
Ejemplos:
- Fecha válida posterior al día actual.
- Fecha anterior al día actual.
- Especialidad inexistente.
- Correo electrónico con formato inválido.
- Horario disponible y horario ocupado.
37.11 Pruebas de mensajes
Los mensajes del sistema también deben verificarse cuando son importantes para guiar al usuario o confirmar resultados.
Por ejemplo, ante un horario no disponible, no basta con que el sistema rechace la operación. También debe informar el problema de forma comprensible y ofrecer una acción de recuperación si corresponde.
37.12 Pruebas de requisitos no funcionales
Algunos requisitos no funcionales relacionados con el caso de uso requieren pruebas específicas. Por ejemplo, rendimiento, seguridad, accesibilidad o auditoría.
Ejemplos:
- La búsqueda de horarios responde en menos de 3 segundos.
- Un paciente no puede consultar turnos de otro paciente.
- La cancelación de turno queda registrada en auditoría.
- El flujo puede completarse usando teclado.
37.13 Tabla de derivación
Una tabla permite conectar partes del caso de uso con pruebas:
| Elemento del caso de uso | Prueba derivada | Resultado esperado |
|---|---|---|
| Flujo principal | Reserva exitosa. | Turno confirmado. |
| Flujo alternativo | Búsqueda por profesional. | Horarios del profesional seleccionado. |
| Excepción | Horario ocupado al confirmar. | Mensaje de conflicto y opción de elegir otro horario. |
| Regla de negocio | Intento de doble reserva. | Reserva rechazada. |
| Postcondición | Verificar disponibilidad posterior. | Horario reservado no aparece disponible. |
37.14 Formato de un caso de prueba
Un caso de prueba puede documentarse con estos campos:
- Identificador.
- Nombre.
- Caso de uso relacionado.
- Objetivo de la prueba.
- Precondiciones.
- Datos de prueba.
- Pasos de ejecución.
- Resultado esperado.
- Estado final esperado.
37.15 Trazabilidad con pruebas
Cada prueba importante debería relacionarse con el caso de uso, flujo, regla o requisito que verifica. Esto permite saber qué cobertura existe y qué pruebas deben actualizarse si cambia la especificación.
Por ejemplo, si cambia la regla de cancelación de turnos, se pueden localizar rápidamente las pruebas asociadas.
37.16 No probar solo el camino feliz
Un error frecuente es probar solo el flujo principal exitoso. Aunque esa prueba es necesaria, no alcanza. Muchos errores aparecen en alternativas, excepciones, datos inválidos, permisos o fallas de integración.
Un buen conjunto de pruebas cubre el camino normal y también los escenarios que pueden afectar la experiencia, la consistencia o la seguridad.
37.17 Errores frecuentes
Al derivar pruebas desde casos de uso, suelen aparecer estos errores:
- Crear una sola prueba por caso de uso aunque existan muchas variantes.
- Olvidar flujos alternativos y excepciones.
- No verificar postcondiciones.
- No probar reglas de negocio críticas.
- No incluir datos inválidos o límites.
- No relacionar pruebas con identificadores de casos de uso.
- Escribir resultados esperados vagos o imposibles de comprobar.
37.18 Lista de revisión
Antes de cerrar las pruebas derivadas, conviene revisar:
- ¿Existe prueba para el flujo principal?
- ¿Las alternativas importantes tienen pruebas?
- ¿Las excepciones relevantes tienen pruebas?
- ¿Las reglas de negocio críticas están cubiertas?
- ¿Se verifican postcondiciones?
- ¿Hay datos válidos, inválidos y de borde?
- ¿Cada prueba tiene resultado esperado claro?
- ¿Las pruebas están trazadas al caso de uso?
37.19 Qué debes recordar de este tema
- Un caso de uso puede generar varios casos de prueba.
- El flujo principal produce pruebas de camino exitoso.
- Los flujos alternativos y excepciones también deben probarse.
- Las reglas de negocio deben verificarse explícitamente.
- Las postcondiciones indican qué resultados comprobar.
- Los datos de entrada ayudan a definir valores válidos e inválidos.
- La trazabilidad permite conectar pruebas con casos de uso y requisitos.
37.20 Conclusión
Derivar casos de prueba desde casos de uso permite verificar que el sistema cumple el comportamiento esperado desde la perspectiva del usuario y del negocio.
Una especificación bien escrita facilita construir pruebas claras, completas y trazables. En el próximo tema estudiaremos la revisión, validación y aprobación de casos de uso con usuarios.