Cuando un campo acepta números del 1 al 1000, la intuición dice que necesitas cientos de casos de prueba. La realidad es que siete valores elegidos con precisión bastan para obtener una cobertura estructural sólida. Las dos técnicas de caja negra más utilizadas en testing profesional —particiones de equivalencia y análisis de valores límite— permiten reducir drásticamente el esfuerzo sin sacrificar calidad. A continuación se explica cómo funcionan y por qué son tan efectivas.
¿Qué es el testing de caja negra y por qué importa?
En el testing de caja negra no se observa el código fuente. Solo se analiza qué entra y qué sale del sistema, como meter ingredientes en una licuadora sin ver el motor [0:27]. Las pruebas se diseñan a partir de los requisitos, no de la implementación. Esto significa que cualquier persona con acceso a la especificación puede ejecutarlas, sin importar el lenguaje de programación ni la arquitectura.
Tanto las particiones de equivalencia como los valores límite son técnicas de caja negra pura. Funcionan en cualquier nivel de prueba: unitaria, integración, sistema o aceptación. El único insumo necesario es conocer qué entradas acepta el sistema y cuál debería ser la respuesta esperada para cada una.
¿Cómo funcionan las particiones de equivalencia?
La partición de equivalencia parte de una premisa simple: si un grupo de valores produce exactamente el mismo comportamiento en el sistema, basta con probar un solo representante del grupo [1:10]. Si ese caso pasa, se asume que todos pasan; si falla, todos fallan. Es como probar una manzana de una bolsa del mismo árbol: si está ácida, se asume que toda la bolsa lo está.
Para un campo que acepta del 1 al 1000, las particiones quedan así:
- Valores menores a 1 (ejemplo: 0) — partición inválida, el sistema debe rechazarlos.
- Valores entre 1 y 1000 (ejemplo: 500) — partición válida.
- Valores mayores a 1000 (ejemplo: 1500) — partición inválida.
Tres particiones, tres casos en lugar de miles.
¿Por qué es un error probar solo el camino feliz?
El error clásico del tester principiante es verificar únicamente que el sistema acepta lo correcto y detenerse ahí [2:07]. Las particiones inválidas cubren un riesgo completamente distinto: que el sistema deje pasar una entrada mala, provocando cálculos incorrectos o corrupción de datos. Piensa en un portero de discoteca con regla de 21 a 55 años; si solo verificas que alguien de 30 entra, nunca descubrirás que también deja pasar a alguien de 15.
La cobertura se calcula dividiendo particiones probadas entre particiones totales. Si tienes tres y solo pruebas la válida, tu cobertura es apenas un tercio.
¿Dónde se esconden realmente los defectos?
En los bordes. Ahí entra el análisis de valores límite [2:38]. Los desarrolladores cometen errores frecuentes al codificar condiciones de frontera, el famoso off-by-one: escribir "mayor que 10" en lugar de "mayor o igual que 10". Ese error es invisible si pruebas con 5, pero explota si pruebas con exactamente 10.
Para cada frontera se prueba el valor exacto del límite y su vecino inmediato del otro lado. En el campo de 1 a 1000, los siete valores quedan así:
- 0 — rechazado.
- 1 — aceptado.
- 2 — aceptado.
- 500 — nominal, representante de la partición válida.
- 999 — aceptado.
- 1000 — aceptado.
- 1001 — rechazado.
Siete valores, cobertura quirúrgica [3:15].
¿Cómo influye la granularidad del tipo de dato?
Un detalle que separa al tester riguroso del promedio: "justo arriba" del límite depende del tipo de dato [3:32].
- Para enteros, el paso es 1.
- Para decimales (campo de 1.0 a 1000.0), justo debajo del mínimo es 0.9, no 0.
- Para cadenas de texto, el límite se mide en longitud: contraseña de 8 a 14 caracteres requiere probar con 7, 8, 14 y 15.
- Para fechas, la granularidad puede ser días u horas según cómo calcula el sistema.
La regla es clara: no sumes uno automáticamente. Pregúntate cuál es la unidad mínima que el sistema distingue.
¿Cómo se aplican ambas técnicas en un caso real?
Imagina un seguro que acepta solicitantes de 0 a 85 años [4:05]. Las particiones son: 0 a 85 válida, 86 en adelante inválida, negativos como otra inválida. Los representantes: 40, 90 y menos 5. Los valores límite: menos 1, 0 y 1 en el borde inferior; 84, 85 y 86 en el superior. Resultado: siete casos con resultados esperados claros.
Piensa en tu proyecto actual. ¿Qué campo de entrada podrías particionar hoy mismo? Elige uno, dibuja las particiones, marca los bordes. El diseño prácticamente se escribe solo. Y cuando alguien pregunte por qué solo siete pruebas, la respuesta es estructural: un valor por partición confirma el comportamiento normal, los valores límite confirman los puntos más propensos a error. No es azar, es estrategia.
Estas dos técnicas resuelven el caso de un solo campo de entrada. Pero cuando el comportamiento depende de combinaciones de condiciones, las particiones ya no alcanzan. El siguiente paso lógico son las tablas de decisión para reglas de negocio, donde se maneja esa complejidad combinatoria de forma sistemática. ¿Ya identificaste un campo en tu proyecto donde aplicar particiones y valores límite? Comparte tu ejemplo y discutamos.
