¿Cómo diseñar casos de prueba efectivos?

Un caso de prueba efectivo es un documento claro, reproducible y sin ambigüedades que cualquier tester puede ejecutar y obtener el mismo resultado.

La frustración de un caso de prueba mal escrito

Imagina que eres nuevo en el equipo de QA de Liverpool. Tu líder te pasa un caso de prueba que dice: "Verificar que el carrito funcione bien". ¿Qué significa "bien"? ¿Con un producto o con diez? ¿Con stock disponible o sin él? No puedes ejecutarlo sin adivinar. Eso es exactamente lo que queremos evitar.

Un caso de prueba mal redactado genera pruebas inconsistentes. Dos testers ejecutan el mismo caso y obtienen resultados distintos. El bug nunca se reproduce, el desarrollador no puede corregirlo, y el error llega a producción.

La solución es usar un formato estándar. Cuando todos siguen la misma estructura, las pruebas son predecibles y confiables.

El Framework PRECOND-PASOS-RESULTADO

Este es el sistema que usan equipos profesionales de QA en todo México y el mundo. Se llama Framework PRECOND-PASOS-RESULTADO y tiene tres componentes obligatorios:

• Precondición: el estado exacto del sistema antes de empezar.
• Pasos: las acciones numeradas que el tester debe ejecutar.
• Resultado esperado: lo que debe ocurrir si el sistema funciona correctamente.

Además, un caso de prueba completo incluye un ID único, un título descriptivo, la prioridad (Alta, Media, Baja) y el entorno donde se ejecuta (desarrollo, staging, producción).

Este framework convierte una idea vaga como "probar el carrito" en un procedimiento preciso que cualquiera puede repetir mañana, la próxima semana o en seis meses.

Ejemplo 1: Prueba en el checkout de Mercado Libre

Supón que estás probando el flujo de compra de Mercado Libre México. Aquí está un caso de prueba bien diseñado:

ID: CP-001 Título: Verificar compra exitosa con tarjeta de débito BBVA Prioridad: Alta Entorno: Staging

Precondición:

• El usuario tiene cuenta activa y está logueado.
• El carrito contiene un artículo con precio de $1,299 y stock disponible.
• El usuario tiene una tarjeta de débito BBVA registrada con fondos suficientes.

Pasos:

1. Ir a la sección "Mi carrito".
2. Hacer clic en "Comprar ahora".
3. Seleccionar la tarjeta de débito BBVA como método de pago.
4. Hacer clic en "Confirmar compra".

Resultado esperado:

• El sistema muestra la pantalla de confirmación con el número de orden.
• El usuario recibe un correo de confirmación en menos de 2 minutos.
• El saldo de la tarjeta se reduce en $1,299.

¿Ves la diferencia? No hay ambigüedad. Cualquier tester sabe exactamente qué hacer y qué esperar.

Ejemplo 2: Prueba de cálculo de nómina en una empresa con IMSS

Los sistemas de nómina en México son críticos. Un error puede generar multas del SAT o descuentos incorrectos al trabajador. Aquí un caso de prueba para ese contexto:

ID: CP-015 Título: Verificar cálculo correcto de descuento IMSS para salario de $18,500 mensuales Prioridad: Alta Entorno: Desarrollo

Precondición:

• El sistema de nómina está configurado con las tablas vigentes del IMSS 2024.
• Existe un empleado de prueba con salario bruto de $18,500 mensuales.
• El período de cálculo corresponde al mes de enero 2024 (31 días).

Pasos:

1. Acceder al módulo de nómina como usuario administrador.
2. Seleccionar al empleado de prueba "Juan Pérez".
3. Ejecutar el cálculo de nómina para el período enero 2024.
4. Navegar a la sección "Desglose de deducciones".

Resultado esperado:

• El descuento por cuota obrera del IMSS muestra $555 (3% sobre el salario integrado diario).
• El ISR retenido corresponde al tabulador vigente para ese rango de ingreso.
• El recibo de nómina muestra el neto a pagar correctamente descontado.

Este caso protege al trabajador y a la empresa. Si el sistema calcula mal, lo detectas antes de que impacte en la nómina real.

Ejemplo 3: Prueba negativa en el registro de FEMSA

No todos los casos de prueba verifican el camino feliz. Los casos negativos son igual de importantes. Prueban qué pasa cuando el usuario hace algo incorrecto.

ID: CP-022 Título: Verificar mensaje de error al registrar RFC inválido en portal FEMSA Prioridad: Media Entorno: Staging

Precondición:

• El portal de proveedores de FEMSA está disponible.
• El tester tiene acceso al formulario de registro de proveedor.

Pasos:

1. Abrir el formulario de registro de nuevo proveedor.
2. Ingresar el RFC "XXXX123456" (formato incorrecto).
3. Completar el resto del formulario con datos válidos.
4. Hacer clic en "Enviar solicitud".

Resultado esperado:

• El sistema NO procesa el registro.
• Se muestra el mensaje: "El RFC ingresado no tiene el formato correcto. Verifica e intenta de nuevo".
• El campo RFC se resalta en rojo.
• Los demás campos conservan la información ya ingresada.

Este tipo de prueba evita que datos corruptos entren a la base de datos. Si el sistema acepta un RFC inválido, el error llegará al SAT.

Cómo aplicar el framework desde hoy

Siguiendo estos pasos puedes diseñar tu primer caso de prueba profesional en menos de 30 minutos:

1. Identifica la funcionalidad a probar. Escoge una sola función específica. No intentes abarcar todo el módulo en un caso.
2. Define la precondición exacta. Pregúntate: ¿qué necesita estar listo antes de empezar? Incluye datos de prueba concretos, no genéricos.
3. Escribe los pasos en orden. Usa verbos de acción: "Hacer clic en", "Ingresar", "Seleccionar", "Navegar a". Sé tan específico que un robot pueda seguirlos.
4. Escribe el resultado esperado en positivo. No digas "no debe fallar". Di qué DEBE mostrar, qué DEBE ocurrir, en cuánto tiempo.
5. Clasifica la prioridad. Alta para flujos críticos (pagos, accesos), Media para flujos frecuentes, Baja para casos edge poco comunes.

Errores comunes al diseñar casos de prueba

Incluso testers con experiencia caen en estos errores. Reconocerlos te ahorra horas de trabajo:

Error 1: Precondiciones vagas. Escribir "el usuario debe estar registrado" sin especificar qué tipo de usuario, qué permisos tiene, o si tiene datos previos cargados. La solución es siempre nombrar datos concretos: "El usuario admin@bimbo.com.mx tiene rol de supervisor activo".

Error 2: Pasos que asumen conocimiento. Escribir "ir al módulo de ventas" sin indicar la ruta exacta. Un tester nuevo no sabe si es un menú lateral, una URL directa o un botón en el dashboard. Siempre escribe la ruta completa.

Error 3: Resultados esperados con adjetivos subjetivos. Decir que la página debe cargar "rápido" o que el mensaje debe ser "amigable" no es medible. Di: "La página carga en menos de 3 segundos" o "El mensaje muestra el texto exacto: 'Tu pedido fue confirmado'".

Error 4: Un caso de prueba que prueba todo a la vez. Querer verificar el login, el carrito y el pago en un solo caso. Si falla, no sabes dónde está el problema. Un caso de prueba debe tener un único objetivo.

Error 5: Olvidar los casos negativos. El 80% de los bugs vive en los caminos alternativos, no en el camino feliz. Por cada caso positivo que diseñes, piensa en al menos un caso negativo: ¿qué pasa si el dato está vacío, tiene formato incorrecto o supera el límite permitido?

Tabla de referencia rápida

La regla de oro del diseño de casos

Antes de terminar de escribir un caso de prueba, aplica esta prueba rápida: ¿podría un tester que nunca vio este sistema ejecutarlo correctamente sin hacerte una sola pregunta? Si la respuesta es no, el caso necesita más detalle.

Un caso de prueba bien diseñado no deja nada a la interpretación: es un contrato entre el equipo de QA y el sistema que se está probando.