Un caso de prueba que dice "verificar que el login funciona" es inútil: un tester no puede ejecutarlo porque "funciona" no está definido, y un desarrollador no puede automatizarlo porque no hay nada concreto que verificar. Un caso de prueba bien escrito es un contrato con tres cosas fijadas: las precondiciones exactas, los pasos exactos y un resultado esperado observable y específico. Esta guía cubre todos los componentes necesarios con ejemplos completos, las técnicas de diseño que hacen la cobertura sistemática, y cuándo escribir casos de prueba formales versus testear de forma exploratoria.

Lo que un caso de prueba no es

Un caso de prueba no es una lista de clics. "Ir a la página de login. Ingresar usuario. Ingresar contraseña. Hacer clic en enviar. Verificar la página." Esto te dice qué hacer pero no qué verificar, cuál es el comportamiento esperado, ni cómo se ve "correcto".

Un caso de prueba es un contrato: dadas estas condiciones y estas acciones, este resultado específico debe ocurrir.

Los componentes de un caso de prueba

Todo caso de prueba necesita estos campos. La herramienta o plantilla exacta no importa (TestRail, Zephyr, Notion, una hoja de cálculo), pero estos elementos deben estar presentes en algún lugar.

ID del caso de prueba: Identificador único. TC-001, AUTH-005, ITEMS-032, lo que use tu equipo. Permite referenciarlo en reportes de bugs y matrices de trazabilidad. Título: Una oración que describe qué se está testeando. Las mismas reglas que para los títulos de bug reports: específico, sin palabras vagas. Precondiciones: Qué debe ser cierto antes de que empiece el test. Estado de la cuenta del usuario, datos que deben existir, estado del sistema, entorno. Pasos: Las acciones exactas a realizar, numeradas, en orden. Cada paso es una acción. Datos de prueba: Los inputs específicos que se usan. No "ingresa un email válido" sino "ingresa admin@becomeqa.com". Resultado esperado: Qué debe ocurrir después del último paso. Específico, observable, verificable. Prioridad: Qué tan crítico es este caso de prueba. Alta (bloquea el release si falla), Media (importante pero tiene workaround), Baja (nice to have). Estado: Pasa, Falla, Bloqueado, No Ejecutado.

Un caso de prueba mínimo

ID: AUTH-001
Título: El usuario puede iniciar sesión con credenciales válidas

Precondiciones:
- Existe la cuenta admin@becomeqa.com con contraseña testpass123
- El usuario no está actualmente logueado

Pasos:
1. Navegar a https://lab.becomeqa.com
2. Hacer clic en el botón "Login" en la navegación
3. Ingresar "admin@becomeqa.com" en el campo Username
4. Ingresar "testpass123" en el campo Password
5. Hacer clic en "Submit"

Resultado esperado:
- El modal se cierra
- Se muestra la página de dashboard
- El encabezado "My Travel Items" es visible
- La navegación muestra el nombre o avatar del usuario logueado

Prioridad: Alta

Esto está completo. Un nuevo ingeniero QA podría ejecutarlo sin hacer preguntas. Un desarrollador podría escribir un test automatizado a partir de él directamente.

Cómo escribir casos de prueba para la funcionalidad de login

El login tiene más casos de prueba que el camino feliz. Una funcionalidad de login completa requiere como mínimo:

Camino feliz

Credenciales válidas → login exitoso.

Caminos negativos

  • Contraseña incorrecta → mensaje de error, sin redirección
  • Nombre de usuario inexistente → mensaje de error (cuidado: no revelar si el email existe)
  • Username vacío → error de validación
  • Password vacío → error de validación
  • Ambos vacíos → error de validación

Casos límite

Email con longitud máxima, contraseña con longitud máxima y contraseña con caracteres especiales (!@#$%^&*).

Casos de seguridad

Inyección SQL en el campo de username (no debe romper la aplicación) e inyección de script () que debe escaparse, no ejecutarse.

Casos de UX

El campo de contraseña debe enmascarar los caracteres, presionar Enter en el campo de contraseña debe enviar el formulario, y el enlace "Olvidé mi contraseña" debe estar presente y funcionar.

Son 12 o más casos de prueba para una sola funcionalidad. Decidir cuántos escribir es un juicio basado en el riesgo. El login de un proveedor de pagos necesita todos. Una herramienta de administración interna usada por 5 personas necesita menos.

Técnicas de diseño de casos de prueba

Partición de equivalencia

En lugar de testear cada edad posible de 0 a 120, divide el espacio de entrada en grupos que deberían comportarse de forma idéntica. Testea un valor de cada grupo.

Para un campo de edad que acepta 18–65:

  • Partición válida: cualquier valor entre 18 y 65 (testear uno: 35)
  • Inválido por debajo: cualquier valor menor de 18 (testear uno: 15)
  • Inválido por encima: cualquier valor mayor de 65 (testear uno: 70)
  • Tipo inválido: entrada no numérica (testear uno: "veinte")

Cuatro casos de prueba en lugar de 120.

Análisis de valores límite

Los bugs se concentran en los límites. Testear los bordes de cada partición.

Para el mismo campo de edad 18–65:

  • 17: justo por debajo del límite inferior (inválido)
  • 18: límite inferior (válido)
  • 65: límite superior (válido)
  • 66: justo por encima del límite superior (inválido)

Combinado con la partición de equivalencia: 4 valores bien elegidos cubren todo el rango.

Testing con tabla de decisión

Cuando múltiples condiciones se combinan para producir resultados diferentes, una tabla de decisión mapea todas las combinaciones:

| Logueado | Tiene suscripción activa | Muestra contenido premium |

|----------|--------------------------|---------------------------|

| No | cualquiera | No |

| Sí | No | No |

| Sí | Sí | Sí |

Escribe un caso de prueba por fila. Las tablas de decisión son excelentes para reglas de negocio con múltiples condiciones.

Escribir casos de prueba a partir de una historia de usuario

Historia de usuario: "Como usuario, puedo agregar un ítem de viaje con nombre de destino y estado."

Este es un punto de partida, no una especificación completa. Antes de escribir casos de prueba, pregunta: ¿Cuáles son los estados válidos? ¿El destino es obligatorio? ¿Cuál es la longitud máxima? ¿Qué pasa si envías el formulario vacío?

Primero obtienes las respuestas, luego escribes los casos. Los casos de prueba escritos a partir de requisitos ambiguos suelen estar equivocados, no porque el tester sea incompetente, sino porque el requisito no especificó el comportamiento.

ID: ITEMS-001
Título: El usuario puede crear un nuevo ítem de viaje con datos válidos

Precondiciones:
- El usuario está logueado como admin@becomeqa.com
- Se muestra el dashboard con la tabla de ítems

Pasos:
1. Hacer clic en el botón "Add Item"
2. Ingresar "Tokio" en el campo Destination
3. Seleccionar "Planned" del dropdown Status
4. Hacer clic en "Save"

Resultado esperado:
- El modal se cierra
- La nueva fila "Tokio" con estado "Planned" aparece en la tabla de ítems
- Se muestra confirmación de éxito (toast o mensaje)

Prioridad: Alta

ID: ITEMS-002
Título: El formulario de agregar ítem muestra error de validación cuando el destino está vacío

Precondiciones:
- El usuario está logueado como admin@becomeqa.com
- El modal de agregar ítem está abierto

Pasos:
1. Dejar el campo Destination vacío
2. Seleccionar "Planned" del dropdown Status
3. Hacer clic en "Save"

Resultado esperado:
- El formulario no se envía
- Aparece el error de validación "Destination is required" debajo del campo Destination
- El modal permanece abierto

Prioridad: Alta

Qué hace a un caso de prueba bueno vs. malo

Bueno

  • Suficientemente específico para reproducirlo sin hacer preguntas
  • El resultado esperado es observable y verificable (no "la página funciona correctamente")
  • Las precondiciones están completas
  • Un resultado esperado por caso de prueba
  • Los pasos son secuenciales e inequívocos

Malo

  • "Verificar que el login funciona" (¿qué significa "funciona"?)
  • Precondiciones faltantes (el test fallará porque los datos no existen)
  • Pasos combinados en uno ("completar el formulario y enviarlo"), demasiado vago
  • Múltiples resultados esperados en un solo caso de prueba (si uno falla, no sabés cuál condición falló)
Un caso de prueba debe poder ser ejecutado por alguien que nunca vio la funcionalidad. Si al releer tus pasos agregas contexto mental, el caso de prueba no es suficientemente específico.

Cuándo escribir casos de prueba vs. cuándo testear de forma exploratoria

Escribe casos de prueba para: escenarios de regresión que se van a re-ejecutar repetidamente, funcionalidades de alto riesgo o complejas, cualquier cosa que necesite aprobación de un product owner o stakeholder, y flujos que eventualmente serán automatizados.

Testea de forma exploratoria para: funcionalidades nuevas antes de que se escriban los casos (primero aprende la funcionalidad), casos límite que descubres mientras testeas (sigue el hilo), y cualquier cosa con tiempo acotado donde escribir scripts llevaría más tiempo que ejecutarlos.

Los dos enfoques tienen su lugar. Los mejores ingenieros QA saben cuándo usar cada uno.

FAQ

¿Cuántos casos de prueba son suficientes para una funcionalidad?

Los necesarios para tener confianza de que la funcionalidad funciona correctamente a través de sus caminos principales, casos límite y condiciones de error. No hay un número fijo. Un formulario simple con dos campos necesita menos que un flujo de checkout multi-paso complejo.

¿Debo escribir los casos de prueba antes o después del desarrollo?

Antes, o durante. Escribir casos de prueba a partir de los requisitos antes de que empiece el desarrollo tiene dos propósitos: fuerza la aclaración de requisitos ambiguos, y produce un checklist de testing listo cuando termina el desarrollo. Este es el enfoque shift-left.

Mis casos de prueba siguen fallando porque los requisitos cambiaron. ¿Qué hago?

Actualiza los casos de prueba cuando cambien los requisitos. Los casos que reflejan requisitos desactualizados son peores que inútiles: dan falsa confianza. Trata los casos de prueba como documentación viva, no como artefactos inmutables.

¿Necesito escribir casos de prueba para los tests automatizados?

Los tests automatizados son una forma de casos de prueba ejecutables. Si tu test automatizado está bien escrito y es legible, él mismo es el caso de prueba. No necesitas un documento manual separado que duplique lo que el código ya dice.

→ See also: La Anatomía de un Bug Report que los Desarrolladores Realmente Arreglan | Testing Basado en Riesgos: Priorizar Qué Testear Cuando No Puedes Testar Todo | Caso de Prueba vs Escenario de Prueba: Diferencia y Cuándo Usar Cada Uno | Técnicas de Diseño de Casos de Prueba: EP, BVA, Tablas de Decisión, Transición de Estados | Cómo Escribir un Plan de Pruebas: Plantilla y Ejemplos Reales