Un caso de prueba mal escrito cuesta más tiempo del que ahorra: alguien lo ejecuta, no entiende qué se supone que debía pasar, y termina adivinando si el resultado está bien o mal. Un buen caso de prueba, en cambio, lo puede ejecutar cualquier persona del equipo — no solo quien lo escribió — y llegar siempre a la misma conclusión.
Las cuatro partes de un caso de prueba útil
No hace falta una plantilla complicada. Con estas cuatro partes, cualquier caso de prueba queda claro:
- Título descriptivo: debe decir qué se está probando sin tener que abrir el caso. "Login con contraseña incorrecta muestra mensaje de error" es mejor que "Probar login 2".
- Precondiciones: qué tiene que existir o estar configurado antes de empezar (una cuenta creada, un producto en el carrito, un rol de administrador).
- Pasos numerados: acciones concretas y en orden, una por línea. "Ir al login, escribir el correo, escribir una contraseña incorrecta, hacer clic en Entrar" — no "probar el login".
- Resultado esperado: exactamente qué debería ver quien ejecuta el caso. No "debería funcionar bien", sino "aparece el mensaje 'Correo o contraseña incorrectos' y el usuario permanece en la pantalla de login".
Un caso, un objetivo
El error más común es meter varias validaciones distintas en un solo caso de prueba ("probar el formulario de registro", con quince verificaciones adentro). Cuando algo falla a mitad de camino, no queda claro si el caso "pasó" o "falló" en general, y el historial de ejecuciones deja de servir para ver tendencias. Es mejor tener más casos, cada uno enfocado en una sola cosa: uno para el registro con datos válidos, otro para el correo ya usado, otro para la contraseña débil, y así.
Prioriza según impacto, no según lo fácil que sea probar
Es tentador escribir primero los casos más fáciles de probar. Pero la prioridad debería reflejar qué tan grave sería que ese flujo se rompiera en producción: procesos de pago, login, y cualquier cosa que toque datos de otros usuarios van primero, aunque tomen más tiempo en documentarse y ejecutarse.
Casos positivos y negativos
Un conjunto de pruebas que solo verifica "el camino feliz" (todo lo que el usuario hace bien) deja pasar la mitad de los bugs reales. Por cada flujo importante, vale la pena preguntarse: ¿qué pasa si el campo queda vacío? ¿Si el archivo es demasiado grande? ¿Si se hace doble clic muy rápido en el botón de enviar? Los casos negativos suelen encontrar los bugs que más le duelen al usuario final.
Mantén los casos vivos, no los escribas una sola vez
Un caso de prueba que quedó desactualizado (porque el flujo cambió y nadie lo actualizó) es peor que no tener caso: alguien lo ejecuta, ve que "falla", y hace perder tiempo revisando algo que en realidad ya no aplica. Revisar los casos cuando cambia la funcionalidad que cubren — no solo cuando alguien se acuerda — es lo que mantiene útil todo el trabajo de documentación.
Si hoy escribes tus casos de prueba en una hoja de cálculo o los repartes en mensajes de chat, vale la pena centralizarlos en un solo lugar donde queden organizados por proyecto, con prioridad, y con un historial de qué se ejecutó y cuándo — que es exactamente lo que resuelve QAcove.