Diseño de caso de pruebas de software

 Diseño de caso de pruebas de software

Diseñar casos de prueba es una actividad central dentro del aseguramiento de la calidad: consiste en transformar objetivos de prueba generales en condiciones y pasos concretos que permitan verificar si el software cumple los requisitos y se comporta correctamente ante entradas válidas, inválidas y situaciones límite. Esta entrada explica qué es el diseño de casos de prueba, muestra técnicas y ejemplos prácticos, y aclara en qué consisten las pruebas de componentes (unitarias/module/component) y las pruebas del sistema.

¿Qué es el diseño de casos de prueba?

El diseño de casos de prueba (test design) es el proceso mediante el cual se identifican y especifican las condiciones de prueba, los datos y los pasos necesarios para comprobar los requisitos del software. No es solo escribir “entradas y salidas”: incluye seleccionar técnicas de diseño (black-box, White-box), priorizar casos por riesgo/impacto, y documentar precondiciones y criterios de aceptación. Los marcos y guías profesionales (por ejemplo ISTQB) definen este proceso como una transformación sistemática de objetivos de prueba en condiciones y casos concretos.

Pasos para diseñar un caso de prueba

1. Analizar los requisitos

   • Revisar qué funcionalidad se debe probar y qué reglas de negocio aplica.

2. Definir el objetivo de la prueba

   • Establecer qué se busca validar (ejemplo: validar que el login funcione con credenciales válidas).

3. Identificar entradas y datos de prueba

   • Seleccionar valores válidos, inválidos y límites para cubrir todas las condiciones.

4. Establecer precondiciones

   • Determinar lo que debe cumplirse antes de ejecutar la prueba (usuario creado, sesión iniciada, etc.).

5. Diseñar los pasos de ejecución

   • Redactar las acciones que el tester debe seguir de forma clara y ordenada.

6. Definir resultados esperados

   • Especificar qué debería pasar si el sistema funciona correctamente.

7. Asignar prioridad/severidad

   • Clasificar la importancia del caso y el impacto que tendría si falla.

8. Revisar y validar el caso

   • Verificar que el caso cubre el requisito y que es entendible para cualquier tester.

Técnicas principales de diseño de casos de prueba

A continuación las técnicas más útiles y comunes, con breve explicación de su propósito:

• Particionamiento de equivalencia : dividir el conjunto de entradas en “clases” que deberían comportarse igual; elegir 1 ó 2 valores representativos por clase. Útil para reducir cantidad de pruebas de entrada. 

• Análisis de valores límite : probar valores en los límites de las particiones (y justo fuera de ellos). Muy efectivo para errores en comparaciones y validaciones. 

• Tablas de decisión: modelar reglas de negocio combinando condiciones y acciones; generar casos que cubran combinaciones relevantes. Ideal cuando hay varias reglas condicionales. 

• Pruebas de transición de estado : cuando el comportamiento depende del estado del sistema (p. ej. estados de un pedido), se modelan transiciones y se prueban rutas relevantes. 

• Técnicas estructurales: cobertura de sentencias, ramas y caminos para verificar la lógica interna. Útiles en pruebas a nivel de código (unit/component). 

Consejo práctico: combina técnicas. Por ejemplo, usa particionamiento + BVA para campos numéricos y tablas de decisión para reglas de descuento/combinaciones.

Ejemplos prácticos de diseño de casos de prueba

1) Caso: Formulario de Login (ejemplo completo)

Contexto: Aplicación web con los campos username y password. Reglas: password mínimo 8 y máximo 16 caracteres; bloquea cuenta tras 5 intentos fallidos.

Plantilla de caso (campos sugeridos)

• ID: TC-LOGIN-001

• Título: Inicio de sesión exitoso con usuario válido

• Objetivo: Verificar que un usuario con credenciales válidas puede iniciar sesión.

• Precondición: Usuario juan ya registrado con password P@ssw0rd123.

• Pasos:

  1. Ir a /login.

  2. Ingresar username juan.

  3. Ingresar password P@ssw0rd123.

  4. Pulsar "Entrar".

• Datos de prueba: username/password (ver arriba).

• Resultado esperado: Redirección a /dashboard; mensaje “Bienvenido, Juan”.

• Prioridad/Severidad: Alta / Crítica.
  (Plantillas estandarizadas modernas siguen ISO/IEC/IEEE 29119 y ejemplos de plantillas están disponibles en recursos de QA). 

Casos derivados (positivos/negativos / seguridad):

• TC-LOGIN-002: Password incorrecto → mostrar “Credenciales inválidas” (negativo).

• TC-LOGIN-003: Username vacío → validar mensaje “El usuario es obligatorio”. (equivalence partition)

• TC-LOGIN-004: Password con 7 caracteres (BVA — justo por debajo del mínimo) → rechazo.

• TC-LOGIN-005: Password con 8 caracteres (BVA — mínimo válido) → aceptación.

• TC-LOGIN-006: Inyección SQL en username → debe sanitizar y devolver error sin filtrar (prueba de seguridad).
  Para más ejemplos y plantillas de login, hay listados extensos (p. ej. catálogos de test cases para login).

2) Ejemplo: Campo Edad (aplicando particionamiento y BVA)

Supongamos requisito: edad válida entre 18 y 65 (inclusivo).

• Equivalence partitions (clases):

  • Válidos: 18–65.

  • Inválidos bajos: < 18 (p. ej. 0–17).

  • Inválidos altos: > 65 (p. ej. 66+).

• Casos BVA: 17 (inválido), 18 (válido), 65 (válido), 66 (inválido).
  Documenta además datos extremos (nulos, cadenas, caracteres especiales).

3) Ejemplo: Tabla de decisión — descuentos

Reglas:

• Si cliente es mayor de 65 → descuento 20%.

• Si cliente es miembro premium → descuento 15%.

• Si ambas condiciones se cumplen → aplica solo el mayor descuento (20%).
  Tabla simplificada:

Caso	>65	Premium	Descuento
1	No	No	0%
2	No	Sí	15%
3	Sí	No	20%
4	Sí	Sí	20%

Genera un caso por fila y verifica cálculo final. Las tablas de decisión ayudan a cubrir combinaciones de reglas. 

Pruebas de componentes vs Pruebas del sistema

Pruebas de componentes (component testing)

• Qué son: pruebas de unidades o componentes individuales (módulos, clases, funciones) en aislamiento. También llamadas unit tests o module tests. Su objetivo es detectar defectos localizados dentro de una sola unidad. 

• Quién las realiza: normalmente desarrolladores o equipos de QA con conocimiento técnico.

• Ambiente: aislado; se usan stubs/drivers/mocks para simular dependencias.

• Herramientas típicas: JUnit, pytest, NUnit, frameworks de mocking.

• Ventaja: rápidas, fáciles de automatizar, detectan errores tempranos.

Pruebas del sistema (system testing)

• Qué son: pruebas ejecutadas sobre el sistema completo integrado (end-to-end) para verificar que cumple los requisitos funcionales y no funcionales. Validan flujo, integración con infra, rendimiento, seguridad, etc. 

• Quién las realiza: equipo de QA (independiente idealmente), a veces con soporte de operaciones.

• Ambiente: entorno lo más cercano a producción (datos y configuración reales).

• Tipos comunes: pruebas funcionales del sistema, pruebas de rendimiento, pruebas de seguridad, pruebas de compatibilidad.

• Diferencia clave: las pruebas de componente validan unidades individuales en aislamiento; las pruebas del sistema validan el comportamiento global y la interacción entre todos los componentes.

Resumen visual: componentes → pruebas internas, rápidas y aisladas; sistema → pruebas integradas, completas y más costosas.

 

Plantilla recomendada de caso de prueba (basada en estándares ISO/IEEE)

Campos básicos a incluir (mínimo):

• ID

• Título

• Objetivo / Requisito asociado (link a requisito)

• Precondiciones

• Pasos (nítidos y ejecutables)

• Datos de prueba

• Resultado esperado

• Post-condiciones

• Prioridad / Severidad

• Tipo (funcional / de integración / de sistema / de regresión / de seguridad)

• Responsable / Ejecutor

• Fecha de ejecución

• Estado / Resultado (Pasó / Falló)
  Los estándares modernos (ISO/IEC/IEEE 29119) recomiendan vincular casos con requisitos y mantener historial/versionado en la documentación.

Buenas prácticas al diseñar casos de prueba

• Prioriza por riesgo: más cobertura en áreas críticas.

• Escribe pasos reproducibles y atómicos (un objetivo por caso).

• Reusa datos y keywords para automatización.

• Combina técnicas (EP + BVA + tablas) para eficiencia.

• Vincula cada caso a un requisito para trazabilidad.

• Revisa y actualiza cuando cambian requisitos; mantén versionado. (Estándares y guías recomiendan control y trazabilidad).

Conclusión

El diseño de casos de prueba es una mezcla de arte y método: las técnicas (particionamiento, BVA, tablas de decisión, state-transition, técnicas estructurales) nos permiten transformar requisitos en pruebas efectivas y eficientes. Las pruebas de componentes buscan calidad en unidades aisladas; las pruebas del sistema validan la solución completa frente a los requisitos y el entorno. Usar plantillas estándares (ISO/IEC/IEEE 29119 / IEEE 829 modernizado) y priorizar por riesgo hará que tus campañas de prueba sean más efectivas y mantenibles.

Bibliografía

Certified Tester Foundation Level (CTFL) v4.0. (2024, octubre 19). International Software Testing Qualifications Board. https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/

Iso/iec/ieee 29119-1:2013. (2022). ISO. https://www.iso.org/standard/45142.html

Singh, M. (2025, agosto 28). Test case design techniques in software testing. BrowserStack. https://www.browserstack.com/guide/test-case-design-techniques

Tran, L. (2023, agosto 21). 5 test case design techniques for better software testing. LQA. https://www.lotus-qa.com/blog/test-case-design-techniques/