- Un caso de prueba es un conjunto de precondiciones, datos de entrada, pasos y resultados esperados diseñado para comprobar una condición de prueba concreta.
- Un buen caso de prueba tiene: ID único, título claro, trazabilidad al requisito, prioridad, precondiciones, datos de prueba exactos, pasos reproducibles y un resultado esperado observable.
- No los escribas "a ojo": usa técnicas de caja negra de ISTQB como partición de equivalencia, valores frontera, tabla de decisión y transición de estados para cubrir más con menos casos.
- Incluye casos positivos (todo sale bien) y negativos (datos inválidos, errores), y no olvides lo no funcional.
- Prioriza por riesgo: primero los casos que cubren lo que más daño haría si fallara.
- Abajo tienes ejemplos resueltos, una plantilla en tabla para copiar y una plantilla en Excel gratuita con listas desplegables, resumen automático y matriz de trazabilidad.
Escribir casos de prueba parece sencillo hasta que te piden probar un formulario con diez campos y te das cuenta de que podrías escribir mil casos... o tres que no sirven. La diferencia entre ambos extremos está en las técnicas de diseño.
En esta guía aprenderás qué es un caso de prueba según ISTQB, cómo escribirlo paso a paso, cómo aplicar las cuatro técnicas de caja negra del programa ISTQB Foundation Level 4.0 con ejemplos resueltos, y te llevas una plantilla lista para usar.
¿Qué es un caso de prueba?
Un caso de prueba (test case) es la especificación de cómo comprobar algo: en qué estado debe estar el sistema antes (precondiciones), qué datos usar, qué acciones realizar y qué resultado esperar.
Para entenderlo bien, conviene distinguir tres conceptos que ISTQB usa en el proceso de prueba:
| Concepto | Responde a | Ejemplo |
|---|---|---|
| Condición de prueba | ¿Qué hay que probar? (análisis) | "El sistema solo permite registrarse a personas de 18 a 75 años." |
| Caso de prueba | ¿Cómo lo pruebo? (diseño) | "Registrar a una persona de 17 años y verificar que se muestra el mensaje 'Edad no permitida'." |
| Procedimiento de prueba | ¿En qué orden ejecuto varios casos? (implementación) | "Ejecutar CP-REG-001 a CP-REG-006 en secuencia con el mismo usuario de prueba." |
El análisis responde a qué probar y el diseño a cómo probar. Si quieres ver el proceso completo y dónde encaja cada actividad, revisa qué hace un QA tester y la guía de tipos de pruebas de software.
Partes de un caso de prueba
| Campo | Para qué sirve | Ejemplo |
|---|---|---|
| ID | Identificarlo de forma única y estable | CP-LOGIN-003 |
| Título | Decir en una línea qué se comprueba | Bloqueo de cuenta al tercer intento fallido |
| Requisito / criterio | Trazabilidad: qué requisito o criterio de aceptación cubre | HU-01 / CA-3 |
| Prioridad | Decidir el orden de ejecución | Alta |
| Técnica de diseño | Saber de dónde salió el caso | Transición de estado |
| Precondiciones | Estado necesario antes de empezar | Usuario activo con 0 intentos fallidos |
| Datos de prueba | Valores exactos a usar | Correo ana.qa@ejemplo.com, contraseña incorrecta "Xyz123" |
| Pasos | Acciones numeradas y reproducibles | 1. Abrir login. 2. Capturar datos. 3. Clic en Entrar (x3) |
| Resultado esperado | Lo que debe pasar, observable y verificable | La cuenta queda bloqueada y se envía correo de desbloqueo |
| Resultado real y estado | Se llenan al ejecutar | Pasó / Falló / Bloqueado |
La trazabilidad no es burocracia: ISTQB explica que permite evaluar la cobertura (¿qué requisitos ya tienen pruebas?), analizar el impacto de un cambio y entender los informes de avance.
Cómo escribir casos de prueba paso a paso
- Lee la base de prueba. Requisitos, historias de usuario, criterios de aceptación, diseños. Si algo es ambiguo, pregúntalo antes: eso es prueba estática y evita defectos.
- Identifica las condiciones de prueba. Qué comportamientos hay que comprobar, priorizados por riesgo.
- Elige la técnica adecuada. Rangos de datos: partición y fronteras. Reglas de negocio combinadas: tabla de decisión. Flujos con estados: transición de estado.
- Identifica los elementos de cobertura (particiones, fronteras, columnas de la tabla, transiciones) y define cuántos casos necesitas para cubrirlos.
- Escribe el caso con datos concretos, pasos reproducibles y un resultado esperado verificable.
- Revísalo con alguien más. Un compañero encontrará pasos ambiguos o resultados esperados poco claros.
Técnicas de caja negra con ejemplos resueltos
Las técnicas de caja negra se basan en el comportamiento especificado, sin mirar el código. Su gran ventaja: si la implementación cambia pero el comportamiento requerido sigue igual, tus casos siguen sirviendo.
1. Partición de equivalencia
Divide los datos en particiones cuyos valores el sistema debería procesar igual. Si un valor de la partición detecta un defecto, cualquier otro valor de esa partición también debería detectarlo; por eso basta un caso por partición. Las particiones no deben solaparse ni estar vacías.
Ejemplo: una aseguradora permite cotizar seguro de auto a personas de 18 a 75 años (edad en números enteros).
| Partición | Rango | Tipo | Valor elegido | Resultado esperado |
|---|---|---|---|---|
| P1 | 0 a 17 | No válida | 12 | Mensaje "Edad no permitida" |
| P2 | 18 a 75 | Válida | 40 | Se muestra la cotización |
| P3 | 76 o más | No válida | 82 | Mensaje "Edad no permitida" |
Con 3 casos logras el 100% de cobertura de particiones. Con varios parámetros (por ejemplo, edad y tipo de vehículo) puedes usar la cobertura Cada Elección (Each Choice): cada partición de cada parámetro se usa al menos una vez, sin necesidad de probar todas las combinaciones.
Ejemplo de Cada Elección: tipo de cliente (regular, premium) y método de pago (tarjeta, transferencia, efectivo). En lugar de 6 combinaciones, 3 casos bastan: regular + tarjeta, premium + transferencia, regular + efectivo.
2. Análisis de valores frontera
Los desarrolladores se equivocan con más frecuencia en los límites (un > en lugar de >=). Esta técnica prueba los valores mínimo y máximo de cada partición ordenada. CTFL 4.0 estudia dos versiones:
- 2 valores: por cada frontera, el valor frontera y su vecino más cercano en la partición adyacente.
- 3 valores: por cada frontera, el valor frontera y sus dos vecinos. Es más rigurosa.
Siguiendo con la edad de 18 a 75:
| Versión | Valores a probar | Número de casos |
|---|---|---|
| 2 valores | 17, 18, 75, 76 | 4 |
| 3 valores | 17, 18, 19, 74, 75, 76 | 6 |
La cobertura se mide como valores probados entre valores identificados. Si en la versión de 2 valores solo probaste 17, 18 y 75, tienes 3/4 = 75% de cobertura.
Ejercicio: ¿qué valores probarías? (ver solución)
Enunciado: una transferencia acepta montos de $10.00 a $50,000.00, con centavos. ¿Qué valores usarías con valores frontera de 2 valores?
Solución: como el incremento mínimo es un centavo, los vecinos están a $0.01: $9.99, $10.00, $50,000.00 y $50,000.01. Cuatro casos.
3. Tabla de decisión
Sirve cuando el resultado depende de combinaciones de condiciones, como las reglas de negocio. Las condiciones y acciones son las filas; cada columna es una regla. Para 100% de cobertura debes probar todas las columnas factibles.
Ejemplo: una tienda aprueba una solicitud de crédito así: se aprueba si el ingreso es suficiente y el historial es positivo; si solo una de las dos condiciones se cumple, pasa a revisión manual cuando la persona ya es cliente y se rechaza si no lo es; si ninguna se cumple, se rechaza.
| Condiciones / acciones | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| C1. Ingreso ≥ $10,000 | V | V | V | V | F | F | F | F |
| C2. Historial crediticio positivo | V | V | F | F | V | V | F | F |
| C3. Ya es cliente | V | F | V | F | V | F | V | F |
| A1. Aprobar | X | X | ||||||
| A2. Revisión manual | X | X | ||||||
| A3. Rechazar | X | X | X | X |
La tabla completa tiene 8 reglas (2³). Se puede minimizar fusionando columnas donde una condición no afecta el resultado: R1 y R2 se vuelven una regla "V, V, –" (aprobar sin importar si es cliente) y R7 y R8 una regla "F, F, –" (rechazar). Quedan 6 columnas, es decir, 6 casos de prueba.
Un beneficio extra: al armar la tabla descubres huecos en el requisito. Si el documento no decía qué pasa con R6 (ingreso bajo, historial positivo, no cliente), acabas de encontrar un defecto en la especificación antes de escribir una línea de código.
4. Transición de estados
Sirve para sistemas cuyo comportamiento depende de su estado actual y de su historia: cuentas, pedidos, flujos de aprobación. Se modela con un diagrama o una tabla de estados.
Ejemplo: el inicio de sesión bloquea la cuenta al tercer intento fallido; la cuenta se desbloquea con un enlace enviado por correo.
| Estado actual | Contraseña correcta | Contraseña incorrecta | Clic en enlace de desbloqueo |
|---|---|---|---|
| S0. Activa (0 fallos) | Sesión iniciada | S1 | (no válida) |
| S1. 1 fallo | Sesión iniciada | S2 | (no válida) |
| S2. 2 fallos | Sesión iniciada | Bloqueada / enviar correo | (no válida) |
| Bloqueada | (no válida) | (no válida) | S0 |
Hay 7 transiciones válidas. Para lograr el 100% de cobertura de transiciones válidas (la más usada) bastan 3 casos:
- Caso 1: S0 → incorrecta → S1 → incorrecta → S2 → incorrecta → Bloqueada → desbloqueo → S0 → correcta → Sesión iniciada (cubre 5 transiciones).
- Caso 2: S0 → incorrecta → S1 → correcta → Sesión iniciada.
- Caso 3: S0 → incorrecta → S1 → incorrecta → S2 → correcta → Sesión iniciada.
Para la cobertura de todas las transiciones también debes intentar las no válidas (por ejemplo, contraseña correcta con la cuenta bloqueada: debe seguir bloqueada). ISTQB recomienda probar solo una transición no válida por caso para evitar que un defecto oculte a otro.
Técnicas basadas en la experiencia
Complementan a las anteriores: predicción de errores (anticipar fallos típicos: campos vacíos, caracteres especiales, doble clic en "Pagar"), prueba exploratoria (diseñar y ejecutar al mismo tiempo, idealmente en sesiones con un objetivo) y listas de comprobación.
Ejemplo completo de caso de prueba
Así se ve un caso de prueba bien escrito, derivado de la tabla de decisión anterior (regla R3):
| Campo | Contenido |
|---|---|
| ID | CP-CRED-003 |
| Título | Solicitud de cliente existente con ingreso suficiente e historial negativo pasa a revisión manual |
| Requisito | HU-14 / Regla R3 |
| Prioridad / técnica | Alta / Tabla de decisión |
| Precondiciones | Cliente "Luis Prueba" existe en el sistema; su historial de buró simulado es negativo. |
| Datos de prueba | Ingreso mensual: $12,500. RFC/ID de prueba: LUPR800101XX1. |
| Pasos | 1. Iniciar sesión como Luis Prueba. 2. Ir a "Solicitar crédito". 3. Capturar ingreso $12,500. 4. Enviar la solicitud. |
| Resultado esperado | Estado de la solicitud: "En revisión manual". Se muestra el mensaje "Te contactaremos en 48 horas". No se aprueba ni se rechaza automáticamente. |
El mismo caso en formato Dado / Cuando / Entonces
En equipos ágiles que usan BDD o ATDD, los criterios de aceptación y los casos se escriben así:
Dado que soy cliente existente con historial crediticio negativo
Cuando solicito un crédito declarando un ingreso de $12,500
Entonces la solicitud queda "En revisión manual"
Y veo el mensaje "Te contactaremos en 48 horas"
Plantilla de casos de prueba (copiar y pegar)
Copia esta tabla en tu documento, hoja de cálculo o herramienta de gestión. Incluye un ejemplo y un renglón vacío:
| ID | Requisito | Título | Prioridad | Técnica | Precondiciones | Datos de prueba | Pasos | Resultado esperado | Resultado real | Estado |
|---|---|---|---|---|---|---|---|---|---|---|
| CP-REG-001 | HU-02 / CA-1 | Edad 17 es rechazada | Media | Valores frontera | Formulario disponible | Edad: 17 | 1. Abrir registro 2. Capturar edad 17 3. Enviar | Mensaje "Edad no permitida"; no se crea la cuenta | No ejecutado | |
¿Prefieres trabajar en Excel? Descarga nuestra plantilla gratuita. Incluye listas desplegables de estado, prioridad, nivel, tipo y técnica; formato de color automático (pasó, falló, bloqueado); una hoja de resumen que calcula avance y tasa de éxito; y una matriz de trazabilidad que marca en rojo los requisitos sin casos.
Buenas prácticas para escribir casos de prueba
| Evita | Mejor así |
|---|---|
| "Probar el login" | "Rechazo de inicio de sesión con contraseña incorrecta" |
| "Usar un usuario válido" | "Correo: ana.qa@ejemplo.com / Contraseña: Prueba#2027" |
| "Verificar que funcione correctamente" | "Se muestra el panel con el texto 'Hola, Ana' y la URL cambia a /mi-cuenta" |
| Un caso que prueba registro, login y compra a la vez | Un objetivo por caso; los flujos largos van en un procedimiento |
| Solo casos donde todo sale bien | Casos positivos, negativos y no funcionales |
- Escribe para otra persona. Alguien que no conoce el sistema debe poder ejecutarlo sin preguntarte.
- Mantén la trazabilidad. Cada caso apunta a un requisito o criterio de aceptación.
- Prioriza. ISTQB describe priorización basada en riesgo, en cobertura y en requisitos. Si un caso de alta prioridad depende de uno de baja, ejecuta primero el de baja.
- Actualiza tus casos. Las pruebas se desgastan: si siempre ejecutas los mismos con los mismos datos, dejan de encontrar defectos nuevos.
- Piensa en la automatización. Los casos de regresión bien escritos son la base para automatizar. Lee automatización de pruebas desde cero y, cuando estés listo, practica con el curso de Playwright o el curso de pruebas de API con Postman.
Errores comunes al diseñar casos de prueba
- Probar solo un valor de un rango y olvidar las fronteras.
- Combinar demasiados datos inválidos en un solo caso: si falla, no sabrás cuál de ellos causó el error (enmascaramiento de defectos).
- Resultados esperados copiados del sistema en lugar de la especificación: si el sistema está mal, tu caso también.
- No revisar los casos: los casos de prueba también son productos de trabajo y se pueden revisar con prueba estática.
Los casos de prueba son una parte del trabajo; para organizarlos dentro de un proyecto necesitas un plan. Te lo explicamos en la guía del plan de pruebas de software (con plantilla en Word). Y si quieres profundizar en técnicas más avanzadas (pruebas combinatorias, casos de uso, análisis de dominio), ese es el terreno de la certificación ISTQB Test Analyst (CTAL-TA).
Preguntas frecuentes
¿Qué es un caso de prueba?
Es la especificación de cómo comprobar una condición de prueba: precondiciones, datos de entrada, pasos a seguir y resultado esperado. Se diseña a partir de la base de prueba (requisitos, historias de usuario, criterios de aceptación).
¿Qué debe contener un caso de prueba?
Como mínimo: ID único, título, requisito que cubre, prioridad, precondiciones, datos de prueba, pasos y resultado esperado. Al ejecutarlo se registran el resultado real, el estado y, si falla, el ID del defecto.
¿Cuál es la diferencia entre condición de prueba y caso de prueba?
La condición de prueba indica qué hay que probar (por ejemplo, "solo se permiten edades de 18 a 75 años"). El caso de prueba indica cómo probarlo, con datos y pasos concretos (por ejemplo, "capturar edad 17 y verificar el mensaje de error").
¿Qué técnicas se usan para diseñar casos de prueba?
ISTQB clasifica las técnicas en caja negra (partición de equivalencia, valores frontera, tabla de decisión, transición de estado), caja blanca (cobertura de sentencias y de ramas) y basadas en la experiencia (predicción de errores, prueba exploratoria y listas de comprobación).
¿Cuántos casos de prueba necesito?
Los suficientes para alcanzar la cobertura acordada según el riesgo. Las técnicas te dicen cuántos: por ejemplo, un caso por partición de equivalencia, cuatro valores por rango con fronteras de 2 valores o un caso por columna factible de una tabla de decisión.
¿Qué es un caso de prueba negativo?
Es un caso que usa datos o acciones no válidos para comprobar que el sistema los rechaza o los maneja correctamente, por ejemplo, capturar una edad de 17 años cuando el mínimo es 18.
¿Dónde puedo descargar una plantilla de casos de prueba?
En esta misma guía puedes descargar gratis la plantilla de casos de prueba de Cool Testers en Excel, con listas desplegables, resumen automático de ejecución y matriz de trazabilidad.