Un caso de prueba es una instrucción escrita que describe, paso a paso, cómo verificar que una parte específica de un sistema funciona como debería — qué hacer, en qué orden, y qué se espera que pase al final. Suena simple, y en el fondo lo es, pero la mayoría de los equipos que recién empiezan en QA tienen una idea confusa de dónde termina un caso de prueba y dónde empieza otra cosa (un escenario, un plan de pruebas, un simple recordatorio mental).
La definición corta
Un caso de prueba responde a una sola pregunta muy concreta: "¿esta parte del sistema hace lo que debería, en esta situación específica?". Tiene un punto de partida claro (las precondiciones), una secuencia de acciones (los pasos) y un criterio objetivo para decir si pasó o falló (el resultado esperado). Si dos personas distintas ejecutan el mismo caso de prueba, deberían llegar exactamente a la misma conclusión — eso es lo que separa un caso de prueba real de una nota vaga tipo "revisar que el login funcione".
Ejemplo de un caso de prueba bien escrito
Para un formulario de login, un caso de prueba concreto se vería así:
- Título: Login con contraseña incorrecta muestra mensaje de error.
- Precondición: existe una cuenta registrada con el correo
usuario@ejemplo.com. - Pasos: 1) ir a la pantalla de login, 2) escribir el correo
usuario@ejemplo.com, 3) escribir una contraseña incorrecta, 4) hacer clic en "Entrar". - Resultado esperado: aparece el mensaje "Correo o contraseña incorrectos" y el usuario permanece en la pantalla de login, sin quedar autenticado.
Nótese que no dice "probar el login" — eso sería un escenario, no un caso. Tampoco dice "debería mostrar un error" sin más — un resultado esperado vago deja a quien ejecuta el caso adivinando si lo que ve en pantalla realmente cuenta como "pasó".
Caso de prueba vs. escenario de prueba
Es una confusión muy común, así que vale la pena separarla claramente. Un escenario de prueba es una situación amplia a validar — "el usuario puede iniciar sesión" — mientras que un caso de prueba es una de las muchas formas concretas de poner a prueba ese escenario, con datos y pasos específicos. Un solo escenario ("login") suele desglosarse en varios casos de prueba: contraseña correcta, contraseña incorrecta, correo que no existe, campos vacíos, cuenta suspendida. El escenario da el mapa general; los casos de prueba son las rutas específicas que realmente se recorren y se documentan.
Casos positivos y casos negativos
Un buen conjunto de casos de prueba no solo verifica que todo funcione cuando la persona usa el sistema "bien" (caso positivo, o "camino feliz"). También cubre qué pasa cuando algo sale distinto a lo esperado (caso negativo): un campo vacío, un archivo demasiado grande, un doble clic accidental en el botón de pagar. La experiencia muestra que los casos negativos son los que más bugs reales encuentran, precisamente porque son los que el equipo de desarrollo probó menos a fondo antes de entregar.
¿Dónde se guardan los casos de prueba?
Muchos equipos empiezan escribiendo sus casos de prueba en una hoja de cálculo, y funciona bien mientras son pocos. El problema aparece cuando crecen: no queda un historial claro de cuándo se ejecutó cada caso ni con qué resultado, es difícil vincular un caso al bug que encontró, y cada persona termina con su propia copia desactualizada del archivo. Centralizar los casos en un solo lugar — organizados por proyecto, con prioridad y con historial de ejecución — es lo que convierte una lista de casos en un proceso de QA real, y es exactamente lo que organiza QAcove.