Caja negra vs caja blanca: dos formas de mirar el mismo código

La diferencia cabe en una frase: la prueba de caja negra mira el software desde fuera, sin ver el código, y comprueba qué hace; la prueba de caja blanca mira desde dentro, con el código a la vista, y comprueba cómo lo hace. La primera pregunta si el resultado es correcto. La segunda pregunta si cada camino del programa se ejecutó. No son rivales ni etapas: son dos ángulos del mismo objeto, y quien usa uno solo se queda con la mitad del mapa de riesgo.

El nombre viene de una imagen simple. Una caja negra es opaca: metes una entrada, sale una salida, y no ves lo que pasa dentro. Una caja blanca (o de cristal) es transparente: ves los cables, las ramas, los bucles. Esa metáfora decide qué información usa el tester para diseñar sus casos, y por eso cada enfoque atrapa fallos que el otro deja pasar. Este artículo separa los dos, muestra las técnicas concretas de cada uno y explica por qué un plan de pruebas serio los combina a propósito.

01 · desde fueraCaja negra: probar qué hace, sin ver el código

En una prueba de caja negra el tester trata al sistema como una caja opaca. Solo conoce la especificación: qué debería recibir y qué debería devolver. Diseña sus casos a partir de los requisitos, no del código, y por eso puede escribirlos alguien que no sabe programar, o antes de que el código exista. El estándar ISO/IEC/IEEE 29119-4, dedicado a técnicas de prueba, agrupa estas como técnicas basadas en la especificación [2].

Su valor es que verifica el comportamiento tal como lo vive el usuario, sin sesgarse por cómo está construido por dentro. Su límite es el espejo del mismo hecho: como no ve el código, no sabe qué partes quedaron sin ejecutar. Puede pasar todos sus casos y dejar ramas enteras del programa sin tocar.

La caja negra no sabe cómo está hecho el software. Y precisamente por eso encuentra lo que el programador dio por obvio.

Las técnicas clásicas de caja negra, todas descritas en el temario del ISTQB [1], son estas:

• Particiones de equivalencia: agrupar las entradas en clases que el sistema debería tratar igual, y probar un representante de cada clase en vez de todos los valores. Si un campo acepta edades de 18 a 65, probar "un valor válido", "uno por debajo" y "uno por encima" cubre las tres clases sin probar los cien números.
• Análisis de valores límite: los errores se esconden en los bordes. Si el rango válido es 18 a 65, se prueban 17, 18, 65 y 66, porque ahí es donde un "menor que" mal escrito en lugar de "menor o igual" se delata.
• Tabla de decisión: cuando el resultado depende de varias condiciones combinadas (por ejemplo cliente nuevo, con cupón y monto mayor a cierto umbral), se listan todas las combinaciones y su salida esperada, para no olvidar ninguna regla de negocio.
• Transición de estados: útil cuando el sistema se comporta según en qué estado está (un pedido pasa de "creado" a "pagado" a "enviado"). Se prueban las transiciones válidas y, sobre todo, las prohibidas.

02 · desde dentroCaja blanca: probar cómo lo hace, con el código a la vista

En una prueba de caja blanca el tester sí conoce el código. Diseña los casos para recorrer su estructura interna: cada instrucción, cada rama de un "si/entonces", cada condición dentro de esas ramas. El objetivo no es solo que el resultado sea correcto, sino que ninguna parte del programa se quede sin ejecutar durante las pruebas. El ISTQB las llama técnicas basadas en la estructura [1], y la ISO/IEC/IEEE 29119-4 las cataloga como técnicas de prueba estructurales [2].

La medida que sale de aquí es la cobertura: qué porcentaje de la estructura tocaron tus pruebas. Hay varios niveles, y son más exigentes a medida que bajas:

• Cobertura de sentencias: que cada línea de código se haya ejecutado al menos una vez. Es el nivel más básico y el más engañoso, porque una línea ejecutada no significa que se probó cada decisión que la rodea.
• Cobertura de ramas (o decisiones): que cada bifurcación se haya tomado en ambos sentidos, el verdadero y el falso. Un "si el saldo es suficiente" solo está cubierto cuando probaste tanto el caso en que lo es como el caso en que no.
• Cobertura de condiciones y de rutas: niveles más finos que exigen ejercitar cada condición booleana individual, o cada camino completo de principio a fin. Son potentes y costosos: el número de rutas crece rápido con cada bucle y cada condición anidada.

La caja blanca no pregunta si el software sirve al usuario. Pregunta si tus pruebas de verdad recorrieron el programa.

Por eso la caja blanca vive sobre todo en las pruebas unitarias, donde el programador prueba su propio código con la estructura delante. Ahí una herramienta de cobertura le dice, línea por línea, qué ramas quedaron sin ejecutar, y esas ramas huérfanas suelen ser justo donde se esconde el fallo que nadie pensó en probar.

03 · juntasPor qué se complementan y no se eligen

La tentación es preguntar cuál es mejor. Es la pregunta equivocada, porque cada enfoque es ciego justo donde el otro ve. La caja negra confirma que el sistema hace lo que el usuario espera, pero no te dice qué código quedó sin probar. La caja blanca confirma que recorriste el programa, pero no te dice si lo que hace tiene sentido para el negocio: puedes tener 100 % de cobertura de un cálculo de impuesto que está mal especificado desde el requisito.

El ejemplo lo aclara. Imagina una función que aprueba un préstamo. Con caja negra pruebas combinaciones de ingreso, deuda y edad, y verificas que la decisión final sea la correcta según la política. Con caja blanca abres el código y descubres una rama que solo se activa cuando la deuda es exactamente cero, un caso que tus particiones de equivalencia nunca priorizaron. Ninguno de los dos enfoques, por sí solo, cubre ambos huecos. Juntos, sí.

La forma sana de combinarlos es por niveles de la pirámide de pruebas. En las pruebas unitarias, donde el programador tiene el código delante, domina la caja blanca guiada por cobertura. En las pruebas de sistema y de aceptación, donde importa el comportamiento visible, domina la caja negra guiada por los requisitos. Existe además un punto medio, la caja gris, donde el tester conoce algo de la estructura interna (el esquema de la base de datos, una API) sin llegar al detalle del código, y lo usa para diseñar mejores casos de caja negra.

El ISTQB mantiene esta clasificación precisamente para que un plan de pruebas cubra ambos ángulos de forma deliberada y no por accidente, y la ISO/IEC/IEEE 29119-4 estandariza las técnicas concretas de cada familia para que "probamos bien" deje de ser una opinión y pase a ser algo demostrable [1][2]. La lección práctica es una: no preguntes cuál usar, pregunta cuánto de cada uno necesita este nivel de prueba. La caja negra te dice si el software sirve; la caja blanca, si tus pruebas de verdad lo recorrieron. El riesgo vive en el hueco entre ambas.