Módulo 04: Técnicas de Diseño de Pruebas

Objetivos del módulo

  • Dominar las técnicas clásicas de diseño de pruebas de caja negra
  • Aplicar partición de equivalencia y valores límite
  • Crear tablas de decisión y diagramas de transición
  • Comprender el testing exploratorio

1. ¿Por qué necesitamos técnicas?

Es imposible probar todas las combinaciones de entradas posibles. Las técnicas nos ayudan a seleccionar un subconjunto representativo que maximize la probabilidad de encontrar defectos.

📘 Concepto: Las técnicas de diseño de pruebas son métodos sistemáticos para crear casos de prueba efectivos con la menor cantidad de tests posible.

2. Partición de equivalencia (EP)

Concepto

Divide los datos de entrada en clases de equivalencia: grupos donde todos los valores se comportan igual.

Si un valor de la clase funciona, todos los demás también deberían funcionar.

Ejemplo: Campo “Edad” (aceptable: 18-65)

Clase Rango Tipo Ejemplo
CE1 edad < 18 Inválida 10
CE2 18 ≤ edad ≤ 65 Válida 30
CE3 edad > 65 Inválida 70

Casos de prueba mínimos: 3 (uno por clase)

Test Entrada Clase Resultado esperado
T1 edad = 10 CE1 (inválida) Rechazado
T2 edad = 30 CE2 (válida) Aceptado
T3 edad = 70 CE3 (inválida) Rechazado

Ejemplo: Campo “Email”

Clase Descripción Ejemplo
CE1 Email válido user@mail.com
CE2 Sin @ usermail.com
CE3 Sin dominio user@
CE4 Sin nombre @mail.com
CE5 Vacío ””

Reglas de aplicación

  1. Identificar las entradas del sistema
  2. Dividir cada entrada en clases válidas e inválidas
  3. Seleccionar un representante de cada clase
  4. Crear un caso de prueba por clase

3. Análisis de valores límite (BVA)

Concepto

Los defectos se concentran en los bordes de las clases de equivalencia. Probamos los valores exactamente en el límite.

Ejemplo: Campo “Edad” (18-65) 

   10    17  [18   19  ···  64   65]  66    70
   ───────┼───┼────┼──────────┼────┼───┼────────
  Inválido │ L │ V  │  Válido  │ V  │ L │ Inválido
Test Valor Tipo
T1 17 Límite inferior - 1 (inválido)
T2 18 Límite inferior (válido)
T3 19 Límite inferior + 1 (válido)
T4 64 Límite superior - 1 (válido)
T5 65 Límite superior (válido)
T6 66 Límite superior + 1 (inválido)

⚠️ Importante: Siempre prueba: límite - 1, límite, límite + 1 en cada extremo.

Ejemplo: Campo “Contraseña” (mín 8, máx 20 caracteres)

Test Longitud Resultado esperado
T1 7 caracteres Rechazada
T2 8 caracteres Aceptada
T3 9 caracteres Aceptada
T4 19 caracteres Aceptada
T5 20 caracteres Aceptada
T6 21 caracteres Rechazada

BVA + EP combinados

Para el campo “Cantidad de productos” (1-99):

Valor EP BVA Tipo
0 Inválida inferior Límite -1 ❌
1 Válida Límite inferior ✅
2 Válida Límite +1 ✅
50 Válida Medio (EP) ✅
98 Válida Límite -1 ✅
99 Válida Límite superior ✅
100 Inválida superior Límite +1 ❌

4. Tablas de decisión

Concepto

Cuando el resultado depende de combinaciones de condiciones, una tabla de decisión muestra todas las combinaciones y sus resultados.

Ejemplo: Descuento en tienda online

Reglas:

  • Clientes premium: 20% descuento
  • Compra > 100€: 10% descuento
  • Si es premium Y compra > 100€: 25% descuento
  • En caso contrario: 0% descuento
Condición R1 R2 R3 R4
¿Es premium? Sí Sí No No
¿Compra > 100€? Sí No Sí No
Descuento 25% 20% 10% 0%

Casos de prueba derivados:

Test Premium Importe Descuento esperado
T1 Sí 150€ 25% → Paga 112.50€
T2 Sí 50€ 20% → Paga 40€
T3 No 150€ 10% → Paga 135€
T4 No 50€ 0% → Paga 50€

Ejemplo: Login con 2FA

Condición R1 R2 R3 R4 R5 R6
Email correcto Sí Sí Sí No Sí Sí
Password correcta Sí Sí No - Sí Sí
2FA activado Sí No - - Sí Sí
Código 2FA correcto Sí - - - No -
Resultado Login OK Login OK Error pass Error email Error 2FA Pide 2FA

💡 Consejo: Simplifica la tabla eliminando combinaciones imposibles o redundantes. Con n condiciones booleanas hay $2^n$ combinaciones posibles.

5. Transición de estados

Concepto

Cuando el sistema tiene estados y cambia entre ellos según eventos, modelamos las transiciones y probamos cada una.

Ejemplo: Estado de un pedido 

stateDiagram-v2
    [*] --> Pendiente: Crear pedido
    Pendiente --> Pagado: Pagar
    Pendiente --> Cancelado: Cancelar
    Pagado --> Enviado: Enviar
    Pagado --> Reembolsado: Reembolsar
    Enviado --> Entregado: Confirmar entrega
    Enviado --> Devuelto: Devolver
    Entregado --> [*]
    Cancelado --> [*]
    Reembolsado --> [*]
    Devuelto --> Reembolsado: Procesar devolución

Tabla de transiciones

Estado actual Evento Estado siguiente Acción
Pendiente Pagar Pagado Procesar pago
Pendiente Cancelar Cancelado Liberar stock
Pagado Enviar Enviado Generar tracking
Pagado Reembolsar Reembolsado Devolver dinero
Enviado Confirmar Entregado Cerrar pedido
Enviado Devolver Devuelto Iniciar devolución
Devuelto Procesar Reembolsado Devolver dinero

Transiciones inválidas (pruebas negativas)

Estado actual Evento inválido Resultado esperado
Pendiente Enviar Error: “Debe pagar primero”
Cancelado Pagar Error: “Pedido cancelado”
Entregado Cancelar Error: “Ya entregado”
Enviar Pagar Error: “Ya pagado”

📘 Concepto: Probar transiciones inválidas es tan importante como probar las válidas. Muchos bugs aparecen cuando el sistema intenta transiciones no permitidas.

6. Pairwise Testing (pruebas por pares)

Concepto

Cuando hay muchos parámetros, probar todas las combinaciones es inviable. El pairwise testing garantiza que cada par de valores aparece al menos una vez.

Ejemplo: Formulario con 3 campos

Campo Valores posibles
Navegador Chrome, Firefox, Edge
SO Windows, Mac, Linux
Idioma ES, EN

Combinaciones totales: 3 × 3 × 2 = 18 Con pairwise: Solo 9 combinaciones cubren todos los pares

Test Navegador SO Idioma
T1 Chrome Windows ES
T2 Chrome Mac EN
T3 Chrome Linux ES
T4 Firefox Windows EN
T5 Firefox Mac ES
T6 Firefox Linux EN
T7 Edge Windows ES
T8 Edge Mac EN
T9 Edge Linux ES

💡 Consejo: Herramientas como PICT (Microsoft) o AllPairs generan automáticamente las combinaciones pairwise.

7. Testing exploratorio

Concepto

El testing exploratorio combina diseño y ejecución de pruebas simultáneamente. El tester aprende el sistema mientras lo prueba.

No es “testing sin plan”. Es testing guiado por la intuición y experiencia del tester, dentro de un marco de tiempo definido.

Session-Based Test Management (SBTM)

Elemento Descripción
Charter Misión de la sesión: qué explorar y por qué
Duración Time-box de 60-90 minutos
Notas Qué se probó, qué se encontró
Bugs Defectos encontrados durante la sesión
Debrief Revisión posterior con el equipo

Ejemplo de charter 

Charter: Explorar el proceso de checkout como usuario nuevo
Área: Carrito → Checkout → Pago → Confirmación
Tiempo: 60 minutos
Enfoque: 
  - ¿Qué pasa con el carrito vacío?
  - ¿Qué pasa si se cierra la sesión a mitad del proceso?
  - ¿Los precios son correctos con descuentos?
  - ¿Qué pasa con caracteres especiales en la dirección?

Heurísticas para exploración

Heurística Pregunta
CRUD ¿Crear, Leer, Actualizar, Borrar funciona?
Goldilocks ¿Qué pasa con valores muy grandes/pequeños/justos?
Interrupciones ¿Qué pasa si se corta el proceso a mitad?
Roles ¿Funciona igual para admin, user, invitado?
Datos ¿Qué pasa con caracteres especiales, emojis, vacíos?
Concurrencia ¿Qué pasa si 2 usuarios editan lo mismo?
Navegación ¿Botón atrás? ¿URLs directas? ¿Refresh?

8. Ejercicios prácticos

Ejercicio 1: Partición de equivalencia + BVA

Para un formulario de registro con:

  • Nombre: 2-50 caracteres
  • Edad: 18-120
  • Email: formato válido
  • Contraseña: 8-30 caracteres, al menos 1 número y 1 mayúscula

Diseña los casos de prueba usando EP y BVA para cada campo.

Ejercicio 2: Tabla de decisión

Un servicio de envío tiene estas reglas:

  • Peso < 1kg → Envío 3€
  • Peso 1-5kg → Envío 6€
  • Peso > 5kg → Envío 12€
  • Cliente premium → Envío gratis si compra > 50€
  • Envío exprés → +5€ extra

Crea la tabla de decisión y los casos de prueba correspondientes.

Ejercicio 3: Transición de estados

Modela el diagrama de estados para una cuenta de usuario que puede estar: Inactiva, Activa, Suspendida, Eliminada. Define todas las transiciones válidas e inválidas.

Ejercicio 4: Testing exploratorio

Elige una aplicación web real (ej: Wikipedia, Amazon) y realiza una sesión de testing exploratorio de 30 minutos. Documenta: charter, notas, bugs encontrados.

Resumen

Técnica Cuándo usar Ejemplo
Partición de equivalencia Muchos valores, mismo comportamiento Rangos numéricos, tipos de email
Valores límite Fronteras entre clases edad = 17, 18, 65, 66
Tablas de decisión Combinaciones de condiciones Descuentos, permisos
Transición de estados El sistema tiene estados Pedido: pendiente→pagado→enviado
Pairwise Muchos parámetros Navegador × SO × idioma
Exploratorio Descubrir lo inesperado Sesiones de 60-90 minutos
Navegación  
← Módulo anterior: Gestión con TestLink Siguiente módulo: Pruebas unitarias con NUnit →