Un caso de prueba es una descripción estructurada de una comprobación concreta. Su finalidad es que la comprobación sea inequívoca, reproducible y útil para el equipo, no simplemente dejar algo documentado.
Qué suele contener un buen caso
- →Un título claro que exprese el objetivo de la comprobación.
- →Precondiciones: el estado inicial que debe tener el sistema.
- →Pasos de prueba: las acciones que realiza la persona que prueba o el sistema.
- →Resultado esperado: lo que debe ocurrir exactamente.
- →Cuando sea necesario, datos de prueba, prioridad, enlaces a requisitos y notas.
Qué hace que un caso de prueba sea útil
- →Comprueba una regla o un riesgo concreto, en lugar de todo a la vez.
- →Su resultado esperado es medible e inequívoco.
- →Incluye suficientes pasos para resultar claro, sin detalles innecesarios.
- →Si falla, permite entender qué salió mal.
Errores frecuentes
- →Redactar casos demasiado largos que abarcan varias ideas diferentes a la vez.
- →Utilizar resultados esperados vagos, como «funciona correctamente».
- →No separar las precondiciones de los pasos.
- →Duplicar decenas de casos casi idénticos cuando sería mejor utilizar una lista de comprobación o la parametrización.
Cuándo no hace falta un caso
No todas las comprobaciones necesitan un caso de prueba independiente. En comprobaciones rápidas de smoke o sanity, funcionalidades inestables y sesiones exploratorias, la documentación detallada puede costar más de lo que aporta. Un buen profesional de QA elige el formato de manera consciente.
Casos desarrollados de inicio de sesión con requisitos explícitos
Estos casos utilizan una especificación didáctica ficticia, no reglas universales de inicio de sesión. La cuenta learner@example.test está activa y tiene una contraseña válida conocida. Una contraseña incorrecta o una cuenta desconocida muestran el mismo mensaje, «Invalid credentials», sin crear una sesión. Los campos vacíos muestran errores de campo sin enviar una solicitud de inicio de sesión. La tercera contraseña incorrecta consecutiva para una cuenta conocida la bloquea durante 5 minutos; un inicio de sesión correcto reinicia el contador. Una cuenta bloqueada no puede iniciar sesión ni siquiera con la contraseña correcta.
Ejecuta cada caso de forma independiente. Antes de empezar, restaura el contador de fallos, el estado de bloqueo y la sesión indicados; de lo contrario, la secuencia de pruebas anteriores modifica el resultado esperado. Utiliza únicamente credenciales ficticias.
ID Estado inicial Entrada / acción Resultado esperado
L01 Activo, 0 fallos, sin sesión Enviar cuenta conocida + contraseña correcta Sesión creada; se abre el perfil; contador en 0
L02 Activo, 0 fallos, sin sesión Enviar cuenta conocida + contraseña incorrecta Invalid credentials; sin sesión; contador en 1
L03 Cuenta desconocida, sin sesión Enviar unknown@example.test + cualquier contraseña Invalid credentials; sin sesión
L04 Sin sesión Enviar ambos campos vacíos Dos errores de campo; ninguna solicitud de inicio de sesión
L05 Activo, 2 fallos, sin sesión Enviar cuenta conocida + contraseña incorrecta Sin sesión; cuenta bloqueada durante 5 minutos
L06 Bloqueado, antes del vencimiento, sin sesión Enviar cuenta conocida + contraseña correcta Sin sesión; el bloqueo sigue vigenteConvertir una fila en un caso manual ejecutable
Caso: L02 — rechazar una contraseña incorrecta
Precondiciones: cuenta activa, contador de fallos en 0, sin sesión.
1. Abrir la página de inicio de sesión.
2. Introducir learner@example.test y una contraseña deliberadamente incorrecta.
3. Enviar una vez.
UI esperada: “Invalid credentials”; no se abre el perfil.
Estado esperado: sin sesión; el contador de fallos de la cuenta conocida pasa a 1.
Evidencias: respuesta sin datos sensibles y observación del estado disponible en el entorno de prueba.El contador requiere un mecanismo de observación acordado, como una vista de administración exclusiva del entorno de pruebas o un fixture autorizado. Si no está disponible, marca esa comprobación como no verificada en lugar de deducirla a partir de un mensaje. Añade casos de recuperación, vencimiento del bloqueo, concurrencia y accesibilidad según los riesgos reales del producto; las seis filas son un conjunto inicial, no una evaluación completa de la autenticación.