La partición de equivalencia divide los datos de entrada en clases dentro de las cuales el sistema debería comportarse de la misma manera. En lugar de comprobar decenas de valores similares, QA selecciona uno o dos representantes de cada clase significativa.
La idea básica
Si el sistema trata todo un intervalo de forma idéntica, comprobar cada valor aporta poco. Identifica clases: valores válidos, no válidos, vacíos, demasiado grandes, formatos prohibidos, etcétera.
Un ejemplo sencillo
Supongamos que un campo Edad acepta valores entre 18 y 60, ambos incluidos. Hay al menos tres clases: menores de 18, de 18 a 60 y mayores de 60. Elige un valor representativo de cada clase en lugar de probar todos los números.
Aplicación práctica
- →Primero comprende las reglas de validación y el significado de negocio del campo o parámetro.
- →Identifica las clases con resultados esperados diferentes.
- →Selecciona un valor de cada clase y analiza los límites por separado.
- →Comprueba valores válidos junto con entradas vacías, de tipo incorrecto, prohibidas y con contradicciones lógicas.
Errores frecuentes
- →Definir clases mecánicamente sin comprender la lógica de negocio.
- →Olvidar que las clases de equivalencia no sustituyen al análisis de valores límite.
- →Suponer que los valores son equivalentes cuando el sistema los trata de manera distinta.
- →Utilizar solo clases válidas e ignorar las entradas negativas.
La partición de equivalencia resulta especialmente útil para formularios, parámetros de API, filtros, intervalos, estados y cualquier entrada cuyo examen exhaustivo sea impracticable o carezca de sentido. Su fortaleza consiste en reducir el volumen de pruebas conservando la cobertura lógica.
Ejemplo desarrollado: edad entera admitida
Regla didáctica: una aplicación acepta una edad entera de entre 18 y 65 años, ambos incluidos. Para esta regla, considera tres particiones que no se solapan: enteros menores de 18, enteros entre 18 y 65 y enteros mayores de 65. Elige un representante de cada una antes de añadir las comprobaciones de límites.
Partición Representante Esperado
Entero menor que 18 16 Rechazar: fuera del rango de edad permitido
Entero de 18 a 65 40 Aceptar
Entero mayor que 65 70 Rechazar: fuera del rango de edad permitidoEl modelo supone que los valores de cada partición se procesan de forma similar. Es una hipótesis de diseño de pruebas, no una demostración de que un único valor detecta todos los defectos. Si la regla de negocio introduce un resultado distinto para las edades de 60 a 65, divide la partición válida. No agrupes resultados diferentes simplemente porque las entradas tengan el mismo tipo de datos.
Separar los errores de representación
Define también el contrato de transmisión. En este ejercicio, el campo JSON age debe estar presente y contener un número entero; las cadenas, las fracciones y null no son válidos. Los valores siguientes no son representantes adicionales de las tres particiones de enteros.
Cuerpo de la solicitud Esperado
{} Rechazar: falta un campo obligatorio
{"age": null} Rechazar: se requiere un entero
{"age": "40"} Rechazar: se requiere un entero
{"age": 40.5} Rechazar: se requiere un entero
{"age": 40} AceptarEjercicio y respuesta
¿Cubrirían 25, 40 y 55 las tres particiones de enteros? No: los tres valores pertenecen a la partición válida. Un conjunto como 16, 40 y 70 cubre las tres; después añade 17, 18, 19, 64, 65 y 66 para investigar el comportamiento específico de los límites. Los resultados esperados proceden de la regla indicada, mientras que los códigos de estado HTTP y los esquemas de error requieren un contrato de API independiente.