Las técnicas de caja negra te permiten encontrar bugs sin ver ni entender el código fuente del sistema.
El tester que no necesita ver el motor
Imagina que eres inspector de calidad en Bimbo. Tu trabajo es revisar que el pan salga bien horneado. No necesitas saber cómo funciona el horno por dentro. Solo necesitas definir qué entra, qué debe salir, y verificar que el resultado sea correcto.
Eso es exactamente una prueba de caja negra. Tú defines entradas, ejecutas el sistema, y verificas las salidas. El código interno no te importa.
Esta independencia del código es una ventaja enorme. Puedes probar sistemas sin ser programador. Además, encuentras bugs que los desarrolladores no ven porque están demasiado cerca del código.
El Sistema ENTRADA-FRONTERA-REGLA
Existen tres técnicas clásicas de caja negra que todo tester profesional debe dominar. Juntas forman el Sistema ENTRADA-FRONTERA-REGLA.
Cada técnica ataca un tipo diferente de bug. Usarlas en conjunto te da cobertura amplia sin necesitar miles de casos de prueba.
Las tres técnicas son: Partición de Equivalencias, Análisis de Valores Límite y Tablas de Decisión.
Técnica 1: Partición de Equivalencias
La partición de equivalencias divide todos los posibles valores de entrada en grupos. Dentro de cada grupo, el sistema debería comportarse de la misma manera.
Si el sistema trata igual a todos los valores del grupo, no necesitas probar cada uno. Solo prueba un representante de cada grupo.
Ejemplo con Liverpool:
El sistema de cupones de Liverpool acepta descuentos del 5% al 50%. Puedes dividir las entradas en tres particiones:
- Partición inválida inferior: valores menores a 5 (por ejemplo, 0, 2, 4)
- Partición válida: valores entre 5 y 50 (por ejemplo, 10, 25, 40)
- Partición inválida superior: valores mayores a 50 (por ejemplo, 51, 75, 100)
No necesitas probar los 100 posibles valores. Con tres casos de prueba —uno por partición— cubres el comportamiento completo.
| Partición | Valor representativo | Resultado esperado |
|---|---|---|
| Inválida inferior | 3 | Mensaje de error: "Descuento mínimo es 5%" |
| Válida | 20 | Descuento aplicado correctamente |
| Inválida superior | 60 | Mensaje de error: "Descuento máximo es 50%" |
Esta técnica reduce drásticamente el número de casos de prueba. Es la base de todo diseño eficiente.
Técnica 2: Análisis de Valores Límite
Los bugs viven en las fronteras. Esta es una verdad universal del testing.
El análisis de valores límite se enfoca en los valores exactos del borde de cada partición. Si el rango válido va del 5 al 50, los valores límite son: 4, 5, 50 y 51.
¿Por qué los bordes fallan tanto?
Porque los programadores cometen errores comunes con los operadores de comparación. Escriben > 5 cuando debían escribir >= 5. O escriben < 50 cuando debían escribir <= 50. Esos errores son invisibles en el centro del rango, pero explotan en el borde.
Ejemplo con Mercado Libre:
El sistema de Mercado Libre cobra comisión según el precio del producto:
- Productos de $1 a $999: comisión del 14%
- Productos de $1,000 a $9,999: comisión del 12%
- Productos de $10,000 en adelante: comisión del 10%
Los valores límite que debes probar son:
| Valor | Partición esperada | Comisión esperada |
|---|---|---|
| $1 | Primera | 14% |
| $999 | Primera | 14% |
| $1,000 | Segunda | 12% |
| $9,999 | Segunda | 12% |
| $10,000 | Tercera | 10% |
Nota que NO pruebas $500 ni $5,000. Esos valores están en el centro y rara vez fallan. El dinero está en los bordes.
Si el sistema calcula 14% para un producto de $1,000, encontraste un bug real. Ese bug cuesta dinero a los vendedores.
Técnica 3: Tablas de Decisión
Algunas reglas de negocio combinan múltiples condiciones. Cuando tienes dos o más condiciones que se combinan, una tabla de decisión es tu mejor herramienta.
Una tabla de decisión lista todas las combinaciones posibles de condiciones y define qué debe ocurrir en cada caso.
Ejemplo con FEMSA:
El sistema de crédito de FEMSA para tiendas Oxxo evalúa dos condiciones para aprobar crédito:
- ¿La tienda tiene más de 12 meses activa?
- ¿Las ventas mensuales superan los $80,000?
Las posibles combinaciones son cuatro:
| Condición A: ¿Más de 12 meses? | Condición B: ¿Ventas > $80,000? | Resultado esperado |
|---|---|---|
| Sí | Sí | Crédito aprobado |
| Sí | No | Crédito rechazado |
| No | Sí | Crédito rechazado |
| No | No | Crédito rechazado |
Cada fila de la tabla es un caso de prueba independiente. Cuatro condiciones cubren toda la lógica de negocio.
Si el sistema aprueba crédito cuando la tienda tiene 8 meses pero ventas altas, encontraste un bug. La tabla te lo revela de forma sistemática.
Cómo aplicar el Sistema ENTRADA-FRONTERA-REGLA paso a paso
No uses las tres técnicas de forma aleatoria. Sigue este orden para maximizar la cobertura:
Paso 1 — Identifica cada campo de entrada. Lista todos los campos del formulario, parámetro o funcionalidad que vas a probar. Para un sistema de nómina del SAT, esos campos pueden ser: RFC, salario bruto, días trabajados.
Paso 2 — Aplica Partición de Equivalencias. Define las particiones válidas e inválidas para cada campo. Diseña un caso de prueba por partición. Esto te da la cobertura mínima funcional.
Paso 3 — Aplica Análisis de Valores Límite. Toma los bordes de cada partición. Agrega esos valores como casos de prueba adicionales. Estos casos son pequeños de diseñar pero altamente efectivos para encontrar bugs.
Paso 4 — Identifica combinaciones de condiciones. Si existen reglas que dependen de dos o más condiciones simultáneas, construye una tabla de decisión. Cada fila es un caso de prueba.
Paso 5 — Revisa que no falte ningún resultado posible. Si el sistema puede devolver cuatro tipos de respuesta distintos, asegúrate de tener al menos un caso de prueba que ejercite cada una.
Errores comunes al aplicar estas técnicas
Error 1: Olvidar las particiones inválidas. Muchos testers solo diseñan casos para la partición válida. Los bugs más comunes ocurren cuando el sistema recibe datos inesperados. Siempre prueba qué pasa con datos fuera de rango.
Error 2: Probar solo los valores límite y olvidar los representativos. Los valores límite detectan errores de operadores de comparación. Los valores representativos detectan errores en la lógica general. Necesitas ambos.
Error 3: Construir tablas de decisión incompletas. Si tienes dos condiciones booleanas, siempre hay cuatro combinaciones posibles. Si tienes tres condiciones, hay ocho. No omitas filas. Un bug puede esconderse exactamente en la combinación que no probaste.
Error 4: No incluir el valor cero o cadenas vacías. El cero y el campo vacío son particiones inválidas frecuentemente olvidadas. Un sistema de IMSS que acepta $0 como salario base tiene un bug grave. Inclúyelo siempre en tus particiones.
Cuándo usar cada técnica
- Usa Partición de Equivalencias cuando el campo tiene un rango de valores numéricos o un conjunto de opciones definidas.
- Usa Análisis de Valores Límite siempre que identifiques bordes de rango. Es complementaria a la partición, no sustituta.
- Usa Tablas de Decisión cuando la funcionalidad depende de dos o más condiciones que se combinan para producir resultados diferentes.
En la práctica, usarás las tres juntas en la mayoría de los módulos.
El principio detrás de la caja negra
Las técnicas de caja negra no buscan probar todo. Buscan probar lo correcto.
Un tester amateur prueba 200 casos aleatorios y encuentra pocos bugs. Un tester profesional diseña 20 casos con estas técnicas y encuentra los bugs que importan.
La caja negra no te pide que adivines dónde está el bug: te da un sistema para ir directo a donde los bugs viven.