Partición de Equivalencia

¿Qué Es Equivalence Partitioning? #

Equivalence Partitioning (EP) es una de las técnicas de test design de caja negra más fundamentales. La idea central es simple pero poderosa: en lugar de probar cada input posible, divides el dominio de input en clases de equivalencia — grupos de valores que el sistema debería tratar de forma idéntica.

Si el sistema maneja correctamente un valor de una clase, debería manejar correctamente todos los valores de esa clase. Esta suposición te permite reducir miles de test cases potenciales a un número manejable.

Por Qué Es Importante #

Considera un campo que acepta enteros del 1 al 10,000. Probar cada valor requeriría 10,000 test cases — más los valores inválidos. Con equivalence partitioning, necesitas tan solo 3 test cases:

Pasaste de 10,000+ tests a 3, cubriendo toda la lógica central.

El Proceso #

Paso 1: Identificar el dominio de input. Revisa la especificación para entender qué acepta el campo o parámetro.

Paso 2: Dividir en clases de equivalencia. Agrupa valores que deberían procesarse de forma idéntica. Cada clase debe ser mutuamente excluyente — un valor pertenece a exactamente una clase.

Paso 3: Seleccionar representantes. Elige un valor de cada clase. Evita los valores límite — esos se cubren con una técnica separada (Boundary Value Analysis).

Paso 4: Escribir test cases. Crea un test case por valor representativo.

Tipos de Clases de Equivalencia #

Clases válidas contienen valores que el sistema debería aceptar y procesar normalmente.

Clases inválidas contienen valores que el sistema debería rechazar o manejar como errores.

Un error común es enfocarse solo en las clases válidas. Las clases inválidas frecuentemente revelan más defectos porque el manejo de errores generalmente está sub-testeado.

Aplicando EP a Diferentes Tipos de Datos #

Equivalence partitioning funciona con cualquier tipo de input:

Rangos numéricos:

• Campo de edad (18-65): las clases son <18, 18-65, >65

Inputs de texto:

• Username (3-20 caracteres, alfanumérico): las clases incluyen longitud válida + caracteres válidos, muy corto, muy largo, caracteres especiales, string vacío

Enumeraciones:

• Método de pago (tarjeta de crédito, débito, PayPal): cada opción es su propia clase válida; un método no soportado es una clase inválida

Boolean:

• Checkbox (marcado/desmarcado): dos clases válidas

Ejemplo Real: Descuento en E-Commerce #

Una tienda aplica descuentos según el total del carrito:

Clases de equivalencia:

Cinco test cases cubren toda la lógica de descuentos.

Equivalence Partitioning Avanzado #

Particionamiento Multi-Parámetro #

Las aplicaciones reales rara vez tienen un solo input. Cuando tienes múltiples parámetros, cada uno tiene su propio conjunto de clases de equivalencia. El desafío es combinarlos efectivamente.

Ejemplo: Formulario de registro de usuario

Para testing de clases válidas, crea un solo test case usando un representante válido de cada parámetro simultáneamente:

Test Case 1: Edad=30, Email=user@test.com, Password=Secure1pass
Esperado: Registro exitoso

Para testing de clases inválidas, varía un parámetro a la vez manteniendo los demás válidos:

Test Case 2: Edad=15, Email=user@test.com, Password=Secure1pass
Esperado: Error de validación de edad

Test Case 3: Edad=30, Email=email-invalido, Password=Secure1pass
Esperado: Error de validación de email

Este enfoque se llama Single Fault Assumption — probar un parámetro inválido a la vez para aislar cuál validación se activa.

Particionamiento Basado en Outputs #

A veces es más efectivo particionar basándose en los outputs en lugar de los inputs. Si una función retorna diferentes tipos de resultado, trabaja hacia atrás:

def categorizar_imc(imc):
    if imc < 18.5:
        return "Bajo peso"
    elif imc < 25:
        return "Normal"
    elif imc < 30:
        return "Sobrepeso"
    else:
        return "Obesidad"

Particiones de output: Bajo peso, Normal, Sobrepeso, Obesidad. Elige un input que active cada output.

Errores Comunes #

1. Olvidar la clase “vacía”. Siempre considera string vacío, null o cero como una clase separada.
2. Ignorar tipos de datos. Un campo numérico podría recibir letras — esa es una clase inválida separada.
3. Clases superpuestas. Cada valor debe pertenecer a exactamente una clase. Si las clases se superponen, tu particionamiento está mal.
4. Pocas clases inválidas. Generalmente hay más clases inválidas que válidas.

Ejercicio: Diseña Clases de Equivalencia #

Escenario: Un sistema de reserva de vuelos acepta los siguientes inputs:

• Pasajeros: 1–9 (entero)
• Clase: Economy, Business, First
• Tipo de viaje: Solo ida, Ida y vuelta

Tarea: Identifica todas las clases de equivalencia para cada parámetro y escribe el conjunto mínimo de test cases necesarios.

TC1: Pasajeros=4, Clase=Economy, Viaje=Solo ida → Éxito
TC2: Pasajeros=4, Clase=Business, Viaje=Ida y vuelta → Éxito
TC3: Pasajeros=4, Clase=First, Viaje=Solo ida → Éxito

TC4: Pasajeros=0, Clase=Economy, Viaje=Solo ida → Error
TC5: Pasajeros=15, Clase=Economy, Viaje=Solo ida → Error
TC6: Pasajeros=2.5, Clase=Economy, Viaje=Solo ida → Error
TC7: Pasajeros="abc", Clase=Economy, Viaje=Solo ida → Error
TC8: Pasajeros=4, Clase="Premium", Viaje=Solo ida → Error
TC9: Pasajeros=4, Clase=Economy, Viaje="Multi-ciudad" → Error

Tips de Profesional #

• Combina EP con Boundary Value Analysis. EP reduce el espacio de input; BVA se enfoca en los bordes de cada clase. Juntas forman la base del testing basado en especificaciones.
• Documenta tus particiones. Antes de escribir test cases, lista todas las clases de equivalencia en una tabla. Esto facilita las revisiones y asegura completitud.
• Revisa las particiones cuando cambian las especificaciones. Un cambio en el rango válido o un nuevo tipo de input significa nuevas clases de equivalencia.
• Usa EP para parámetros de API también. Cada parámetro de endpoint de API tiene clases válidas e inválidas — aplica la misma técnica a request bodies, query parameters y headers.