¿Qué es un caso de prueba? – Definición y ejemplo

Imagina que eres un piloto de pruebas a punto de volar un prototipo de avión. No te lanzarías a la pista sin una lista de verificación detallada: ¿Responden los alerones? ¿El tren de aterrizaje se pliega correctamente a 180 nudos? ¿Qué sucede si falla un motor en el despegue? En el desarrollo de software, esa lista de verificación vital, ese protocolo meticuloso que separa un lanzamiento exitoso de un fracaso costoso, se llama caso de prueba.

Un caso de prueba es, en esencia, un experimento. Es un conjunto de condiciones, pasos, datos de entrada y resultados esperados, diseñado con un único y crucial propósito: verificar que una funcionalidad específica de un sistema de software se comporta exactamente como debe. No es una simple corazonada o un «clic a ver qué pasa». Es la materialización de una pregunta de investigación aplicada al código, y su respuesta, ya sea un «sí, funciona» o un «no, aquí hay un defecto», es un tesoro de información para el equipo de desarrollo.

Pero su verdadero poder reside en algo más profundo que una simple verificación. Los casos de prueba son la red de seguridad que permite a los equipos moverse rápido y con confianza. Son la documentación viva del sistema, el lenguaje común entre desarrolladores, testers y analistas de negocio, y la defensa más sólida contra la regresión silenciosa de errores. Sin ellos, cada nueva funcionalidad es un salto al vacío, y cada corrección, una potencial nueva ruptura en un lugar inesperado del sistema.

Más allá de la definición: La anatomía de un caso de prueba

Un caso de prueba robusto no es una simple frase en un documento. Es una entidad estructurada con componentes bien definidos. Ignorar esta estructura es como intentar construir una casa sin planos. Estos son sus elementos atómicos:

1. ID del Caso de Prueba (Identificador Único): Un código alfanumérico que lo distingue de forma inequívoca (ej: CP-LOGIN-001). Es esencial para la trazabilidad y la automatización.
2. Título o Nombre: Una descripción concisa pero significativa. Debe indicar qué se prueba y en qué escenario. Malo: «Probar login». Bueno: «Verificar error de autenticación con contraseña expirada».
3. Condiciones Previas (Precondiciones): El estado del sistema antes de ejecutar la prueba. Son los requisitos que deben cumplirse para que la prueba sea válida. Ej: «El usuario ‘testuser’ debe estar registrado y su cuenta no debe estar bloqueada.» Sin cumplir las precondiciones, el resultado de la prueba es basura.
4. Datos de Prueba: Las variables o inputs concretos que se introducirán. No son solo valores, son el «combustible» del experimento. Pueden ser válidos, inválidos, límite o aleatorios, dependiendo de la técnica de diseño. Ej: Email = testuser@example.com, Contraseña = P@ssw0rd123.
5. Pasos de Ejecución: La secuencia de acciones atómica y sin ambigüedades que el tester debe realizar. Debe ser tan clara que una máquina (en pruebas automatizadas) o un nuevo empleado puedan seguirla sin dudar.
   • Paso 1: Navegar a https://miapp.com/login.
   • Paso 2: Hacer clic en el campo «Email».
   • Paso 3: Ingresar el dato de prueba testuser@example.com.
   • Paso 4: Hacer clic en el campo «Contraseña».
   • Paso 5: Ingresar el dato de prueba P@ssw0rd123.
   • Paso 6: Hacer clic en el botón «Iniciar Sesión».
6. Resultado Esperado: Este es el corazón de la prueba. Describe, con precisión milimétrica, el estado del sistema tras la ejecución si su comportamiento es correcto. No es una opinión, es un criterio de aceptación objetivo. Ej: «El sistema debe redirigir al usuario al panel de control (/dashboard). Debe mostrarse un mensaje de bienvenida: ‘¡Hola, Test User!’. La sesión debe crearse con una cookie segura.»
7. Resultado Real (a completar durante la ejecución): Lo que realmente ocurrió. La comparación entre este campo y el «Resultado Esperado» determina el veredicto.
8. Veredicto o Estado: Aprobado (Pass) si el resultado real coincide con el esperado; Fallado (Fail) si hay discrepancia. También puede estar Bloqueado (no se puede ejecutar) o No Ejecutado.
9. Prioridad: La importancia del caso de prueba para el negocio. Una funcionalidad crítica como el pago tendrá prioridad Alta o Crítica.
10. Severidad (del defecto, si se encuentra): El impacto del fallo en el sistema. Un fallo visual menor es de baja severidad, uno que impide el pago es crítica.

Un ejemplo práctico paso a paso: El arte de probar una calculadora

Dejemos la teoría y ensuciémonos las manos. Supongamos que tenemos una funcionalidad simple: una calculadora web con una operación de división (A / B). Diseñaremos un caso de prueba clásico para una situación límite: la división por cero. Este ejemplo es deliberadamente simple para ilustrar la estructura, pero los principios son idénticos para un sistema de trading de alta frecuencia o una plataforma de telemedicina.

Caso de Prueba: CP-CALC-DIV-002

• Título: Verificar el manejo de error al dividir un número positivo entre cero.
• Objetivo: Asegurar que el sistema no lanza una excepción no controlada, se cuelga o muestra un resultado numérico infinito. Debe mostrar un mensaje de error específico y amigable para el usuario.
• Prioridad: Media
• Precondiciones:
  1. La calculadora web debe estar desplegada y accesible en la URL de pruebas: https://test-calc.ejemplo.com.
  2. La interfaz de usuario se ha cargado completamente sin errores de consola.
  3. El campo de entrada «A» y el campo de entrada «B» están habilitados y vacíos.
• Datos de Prueba:
  • Operando A: 10
  • Operando B: 0
• Pasos de Ejecución:
  1. Abrir un navegador web (Chrome v.120 o superior) y navegar a https://test-calc.ejemplo.com.
  2. Ubicar el campo de texto etiquetado como «Número A».
  3. Hacer clic en el campo y escribir 10.
  4. Ubicar el campo de texto etiquetado como «Número B».
  5. Hacer clic en el campo y escribir 0.
  6. Hacer clic en el botón con el símbolo de división /.
  7. Observar el área de resultados, justo debajo de los campos de entrada.
  8. Observar la interfaz general de la calculadora.
• Resultado Esperado:
  1. El sistema no debe mostrar un resultado numérico (Infinity o NaN) en el área de resultados.
  2. El área de resultados debe mostrar un mensaje de error en texto rojo con el siguiente formato exacto: «Error: No es posible dividir entre cero.»
  3. Los campos de entrada «Número A» y «Número B» deben conservar los valores 10 y 0 respectivamente (no deben limpiarse).
  4. La aplicación no debe congelarse; el usuario debe poder corregir el valor en el campo «Número B» y volver a intentar una operación válida inmediatamente.

Análisis del proceso de ejecución:

Imaginemos que un tester ejecuta este caso de prueba y observa que, al dividir 10 entre 0, el resultado mostrado es Infinity. El resultado esperado dicta un mensaje de error. Hay una discrepancia. El Resultado Real sería «El sistema muestra ‘Infinity’ en texto negro». El Veredicto sería Fallado. La Severidad del defecto se marcaría como Media, porque si bien no rompe el sistema, muestra un resultado matemáticamente incorrecto y técnico que confundiría a un usuario final, degradando la calidad del producto.

Este simple acto de comparar lo esperado con lo real es el ciclo fundamental del testing y la razón de ser del caso de prueba. No se trata de «encontrar bugs por casualidad», sino de una verificación sistemática e incuestionable.

Tipos de casos de prueba: La caja de herramientas completa

No todos los casos de prueba son iguales. Se clasifican según su objetivo y el nivel de conocimiento del sistema que requieren. Un tester experto sabe cuándo usar cada uno.

Por su funcionalidad y flujo

• Caso de Prueba de Ruta Feliz (Happy Path): Verifica el flujo principal y más común, donde todo sale como se espera, sin errores ni excepciones. Es la columna vertebral. Ej: Un usuario se registra, activa su cuenta y realiza una compra con éxito.
• Caso de Prueba Negativo: Diseñado para provocar errores y verificar que el sistema los maneja con gracia. Es igual de importante que el happy path. Ej: El ejemplo de la división por cero, o intentar registrarse con un email de formato inválido.
• Caso de Prueba de Límite (Boundary Value Analysis): Se enfoca en los puntos de inflexión de los rangos de entrada. Los errores aman las fronteras. Si un campo acepta de 1 a 100, se prueba con 0, 1, 100 y 101.
• Caso de Prueba de Regresión: Pruebas que se re-ejecutan para asegurar que nuevas funcionalidades o correcciones no han roto funcionalidades existentes. Son las guardianas de la estabilidad a largo plazo. Suelen ser las primeras candidatas a ser automatizadas.

Por su enfoque y conocimiento del sistema

• Casos de Prueba de Caja Negra (Black-Box Testing): El tester solo conoce las entradas y salidas esperadas, no la estructura interna del código. Se centra en el «qué» hace el software, no en el «cómo». Ideal para pruebas de sistema y aceptación de usuario (UAT).
• Casos de Prueba de Caja Blanca (White-Box Testing): El tester (normalmente un desarrollador) diseña las pruebas con pleno conocimiento del código fuente, los caminos lógicos y las estructuras de datos. Se centra en el «cómo». Permite probar bucles, condicionales y flujos internos.
• Casos de Prueba de Caja Gris (Gray-Box Testing): Un híbrido. El tester tiene un conocimiento parcial del funcionamiento interno, quizás a nivel de base de datos o diagramas de flujo, pero prueba desde la interfaz. Es muy potente para probar servicios web y APIs.

Por qué son importantes: El valor estratégico de un buen diseño

Un caso de prueba bien diseñado es un activo de la organización por varias razones que trascienden la mera detección de fallos:

1. Trazabilidad con los Requisitos: Un caso de prueba debe «mapearse» a una historia de usuario o requisito funcional. Esto permite saber qué porcentaje de los requisitos han sido cubiertos por pruebas, brindando métricas de progreso y calidad (Cobertura de Pruebas). Sin esta ligazón, se prueba a ciegas.
2. Eficiencia en la Automatización: Un caso de prueba manual bien estructurado y con pasos atómicos es un pseudocódigo perfecto para un script de automatización. La inversión en un buen diseño manual se recupera exponencialmente al automatizar.
3. Transferencia de Conocimiento y Onboarding: Un repositorio de casos de prueba es la mejor documentación funcional que puede tener un sistema. Un nuevo miembro del equipo puede leerlos para entender los comportamientos esperados y las reglas de negocio, incluso más que un documento de especificación.
4. Cultura de Calidad: El hábito de diseñar pruebas antes o durante el desarrollo (como en Test-Driven Development) crea una mentalidad preventiva. Todo el equipo empieza a pensar en cómo se va a verificar una funcionalidad, no solo en cómo implementarla.

Errores comunes al diseñar casos de prueba (y cómo evitarlos)

Hasta los testers experimentados caen en trampas. Aquí las más peligrosas:

• El caso de prueba «camaleón»: Aquel que prueba múltiples cosas a la vez. Ej: «Verificar login, mensaje de bienvenida, redirección al dashboard y actualización del carrito de compras». Si falla, no sabes qué parte específica del sistema se rompió. Solución: Un caso de prueba, una única verificación atómica.
• Ambivalencia en el Resultado Esperado: Usar palabras vagas como «debe funcionar bien», «rápido» o «correctamente». «Rápido» no es medible. Solución: Definir criterios objetivos. Ej: «La página debe cargar completamente en menos de 2 segundos en una red 4G simulada.»
• Dependencia de otros casos de prueba: Diseñar el caso CP-002 asumiendo que el CP-001 se ha ejecutado y aprobado justo antes. El CP-002 debe crear sus propias precondiciones o usar datos específicos que no dependan de un estado volátil dejado por otra prueba. Esto es crítico para pruebas en paralelo y automatizadas.
• El «Efecto Pesticida»: Repetir las mismas pruebas una y otra vez. Encontrarán menos bugs con el tiempo. Es vital revisar, actualizar y retirar casos de prueba, combinándolos con pruebas exploratorias que buscan nuevos caminos.

El caso de prueba es el átomo del testing, y como tal, su correcta estructura y filosofía determinan la calidad del producto final. No es una lista de tareas; es un argumento lógico y científico aplicado al software. Dominar su arte es lo que convierte a un «clickeador» en un verdadero ingeniero de calidad.

Resultados de Aprendizaje

Al finalizar la lectura completa de este artículo, deberías ser capaz de:

1. Definir con precisión qué es un caso de prueba en el contexto del aseguramiento de la calidad del software y explicar su propósito fundamental más allá de la simple detección de errores.
2. Identificar y describir detalladamente los nueve componentes clave que forman la anatomía de un caso de prueba robusto, diferenciando entre resultado esperado y real.
3. Aplicar la estructura de un caso de prueba para construir uno completo, utilizando un ejemplo práctico de una funcionalidad de software y definiendo datos, pasos y precondiciones sin ambigüedades.
4. Distinguir entre casos de prueba funcionales (happy path, negativo, límite, regresión) y casos por enfoque (caja negra, caja blanca, caja gris), eligiendo el tipo adecuado para diferentes objetivos de prueba.
5. Argumentar sobre el valor estratégico de un buen diseño de casos de prueba, incluyendo su impacto en la trazabilidad, la automatización, la transferencia de conocimiento y la cultura de calidad.
6. Diagnosticar y evitar los errores de diseño más comunes (como la ambigüedad, múltiples verificaciones y la alta dependencia) para crear casos de prueba eficaces y mantenibles.

Rodrigo Ricardo Editor y fundador