12. Pruebas de caja negra, caja blanca y caja gris

12.1 Introducción

Las pruebas pueden clasificarse según el conocimiento que tenemos sobre el funcionamiento interno del sistema. Desde esta perspectiva aparecen tres enfoques importantes: caja negra, caja blanca y caja gris.

En las pruebas de caja negra nos concentramos en entradas y salidas sin mirar el código interno. En las pruebas de caja blanca usamos conocimiento del código, estructura o lógica interna. En las pruebas de caja gris combinamos ambas miradas.

Estos enfoques no compiten entre sí. Cada uno ayuda a encontrar distintos tipos de defectos.

12.2 La idea de "caja"

La palabra "caja" se usa como metáfora. Imaginemos que el sistema es una caja que recibe datos de entrada y produce resultados.

• Si no miramos dentro de la caja y solo observamos entradas y salidas, hablamos de caja negra.
• Si podemos ver completamente lo que ocurre dentro de la caja, hablamos de caja blanca.
• Si conocemos algunas partes internas, pero seguimos probando desde el comportamiento externo, hablamos de caja gris.

12.3 ¿Qué son las pruebas de caja negra?

Las pruebas de caja negra evalúan el comportamiento externo del sistema sin analizar su código interno. El tester se basa en requisitos, criterios de aceptación, reglas de negocio, casos de uso o experiencia esperada del usuario.

En este enfoque nos interesan preguntas como:

• ¿Qué ocurre si ingreso datos válidos?
• ¿Qué ocurre si ingreso datos inválidos?
• ¿El resultado obtenido coincide con el resultado esperado?
• ¿El sistema muestra el mensaje correcto?
• ¿Se aplican las reglas de negocio?
• ¿El usuario puede completar el flujo previsto?

El tester no necesita saber cómo está programada la solución para diseñar estas pruebas.

12.4 Ejemplo de caja negra

Supongamos que debemos probar una función de inicio de sesión desde la interfaz web. Desde caja negra, podríamos diseñar casos como:

• Correo y contraseña correctos: el sistema debe permitir el acceso.
• Contraseña incorrecta: el sistema debe rechazar el acceso.
• Correo vacío: el sistema debe mostrar mensaje de campo obligatorio.
• Correo con formato inválido: el sistema debe informar formato incorrecto.
• Usuario bloqueado: el sistema debe impedir el ingreso e indicar cómo recuperar la cuenta.

No necesitamos conocer la base de datos, el algoritmo de autenticación ni las clases internas. Solo necesitamos saber qué comportamiento se espera.

12.5 Técnicas comunes de caja negra

Muchas técnicas de diseño de pruebas pertenecen al enfoque de caja negra. Algunas de ellas se estudiarán en temas posteriores:

• Clases de equivalencia: dividir datos en grupos que deberían comportarse igual.
• Valores límite: probar valores cercanos a los bordes permitidos.
• Tablas de decisión: analizar combinaciones de condiciones y acciones.
• Transiciones de estado: revisar cómo cambia el sistema entre estados.
• Casos de uso: probar flujos completos desde la perspectiva del usuario.
• Pruebas exploratorias: investigar el sistema buscando comportamientos inesperados.

Estas técnicas son muy útiles cuando queremos probar comportamiento funcional desde afuera del sistema.

12.6 Ventajas de caja negra

Las pruebas de caja negra tienen varias ventajas:

• Se enfocan en el usuario y en los requisitos.
• No requieren conocer el código interno.
• Ayudan a validar reglas de negocio.
• Son útiles para testers, analistas y usuarios de negocio.
• Permiten probar sistemas completos, pantallas, APIs o flujos.
• Pueden diseñarse antes de que el código esté terminado.

Este enfoque es fundamental porque el usuario final interactúa con el comportamiento visible, no con el código interno.

12.7 Límites de caja negra

Las pruebas de caja negra también tienen limitaciones:

• Puede ser difícil saber qué partes internas quedaron sin cubrir.
• No siempre detectan caminos de código no ejecutados.
• Podrían repetir pruebas similares sin saberlo.
• No ayudan tanto a localizar la causa técnica de un defecto.
• Dependen mucho de la calidad de requisitos y criterios de aceptación.

Por ejemplo, dos casos de prueba diferentes desde la interfaz podrían ejecutar exactamente la misma rama interna del código, mientras que otra rama importante nunca se prueba.

12.8 ¿Qué son las pruebas de caja blanca?

Las pruebas de caja blanca usan conocimiento interno del sistema. Quien diseña la prueba puede ver el código, la estructura, las condiciones, los caminos lógicos, las consultas o la arquitectura.

En este enfoque nos interesan preguntas como:

• ¿Todas las ramas importantes del código fueron ejecutadas?
• ¿Qué ocurre cuando una condición es verdadera y cuando es falsa?
• ¿Hay caminos internos sin probar?
• ¿La función maneja correctamente excepciones?
• ¿Se cubren los casos límite definidos por la lógica interna?
• ¿La integración técnica entre módulos se comporta correctamente?

Las pruebas unitarias suelen estar muy asociadas a caja blanca, aunque no son el único caso posible.

12.9 Ejemplo de caja blanca

Supongamos que existe una función que calcula un descuento:

Desde caja blanca, al ver esa lógica interna, diseñaríamos pruebas para ejecutar cada rama:

• Cliente premium con importe mayor a $1000.
• Cliente premium con importe igual o menor a $1000.
• Cliente no premium.
• Valores cercanos al límite de $1000.

El conocimiento del código o de la lógica interna nos ayuda a no dejar caminos importantes sin probar.

12.10 Técnicas comunes de caja blanca

Algunas técnicas y criterios relacionados con caja blanca son:

• Cobertura de sentencias: verificar qué líneas o instrucciones se ejecutaron.
• Cobertura de ramas: probar caminos alternativos de condiciones.
• Cobertura de condiciones: revisar combinaciones lógicas dentro de decisiones.
• Pruebas de caminos: ejecutar rutas específicas a través del código.
• Revisión de excepciones: comprobar manejo de errores internos.
• Análisis estático: revisar código sin ejecutarlo para detectar problemas.

Estos conceptos se profundizarán en cursos posteriores, especialmente en pruebas unitarias, cobertura de código y calidad de código.

12.11 Ventajas de caja blanca

Las pruebas de caja blanca aportan beneficios importantes:

• Permiten cubrir caminos internos específicos.
• Ayudan a detectar errores cerca del código.
• Facilitan encontrar ramas no probadas.
• Son útiles para lógica compleja.
• Ayudan a mejorar diseño, mantenibilidad y testeabilidad.
• Pueden ejecutarse muy temprano durante el desarrollo.

Cuando se aplican bien, reducen la probabilidad de que defectos simples lleguen a niveles de prueba más altos.

12.12 Límites de caja blanca

Las pruebas de caja blanca también tienen límites:

• Pueden enfocarse demasiado en detalles internos y olvidar la necesidad del usuario.
• Requieren conocimiento técnico.
• No garantizan que el sistema cumpla los requisitos de negocio.
• Pueden pasar aunque la especificación esté equivocada.
• Pueden volverse frágiles si prueban detalles de implementación que cambian con frecuencia.

Por ejemplo, una prueba puede cubrir todas las ramas de una función, pero si la regla de negocio implementada está mal entendida, la cobertura interna no alcanza para asegurar calidad.

12.13 ¿Qué son las pruebas de caja gris?

Las pruebas de caja gris combinan conocimiento externo e interno. El tester no necesariamente revisa todo el código, pero conoce aspectos de arquitectura, base de datos, APIs, flujos internos, logs o reglas técnicas que le permiten diseñar mejores pruebas.

Ejemplos de conocimiento usado en caja gris:

• Saber qué tablas se actualizan después de una operación.
• Conocer qué servicio externo participa en un flujo.
• Revisar logs para entender una falla.
• Conocer estados internos de una entidad.
• Saber qué permisos se validan en backend y no solo en pantalla.
• Entender qué procesos asincrónicos ocurren después de una acción.

Este enfoque es muy común en proyectos reales, porque los testers suelen conocer parte del funcionamiento técnico sin ser necesariamente los autores del código.

12.14 Ejemplo de caja gris

Supongamos que una tienda en línea confirma una compra y luego envía un correo al cliente mediante un proceso en segundo plano.

Desde caja negra, podríamos verificar que la pantalla muestre "Compra confirmada". Desde caja gris, además podríamos saber que:

• La compra debe quedar en estado "confirmada" en la base de datos.
• Debe crearse un registro en una cola de envío de correos.
• El servicio de correo procesa esa cola cada cierto tiempo.
• Si el envío falla, debe quedar un registro para reintento.

Con esa información, diseñamos pruebas más completas que no se limitan a lo visible en pantalla.

12.15 Comparación de enfoques

12.16 Relación con roles

Distintos roles pueden aplicar estos enfoques:

• Un tester funcional suele trabajar mucho con caja negra.
• Un desarrollador suele aplicar caja blanca al escribir pruebas unitarias.
• Un tester técnico puede aplicar caja gris al revisar APIs, base de datos o logs.
• Un usuario de negocio participa más en pruebas de caja negra y aceptación.
• Un equipo de QA puede combinar los tres enfoques según el riesgo.

No hay una división obligatoria. Lo importante es usar el enfoque que permita obtener mejor información sobre la calidad del producto.

12.17 Relación con niveles y tipos de prueba

Caja negra, blanca y gris no son niveles de prueba ni tipos funcionales o no funcionales. Son enfoques de diseño basados en cuánto conocimiento interno usamos.

Se pueden combinar con otros conceptos:

• Una prueba unitaria suele ser de caja blanca.
• Una prueba de aceptación suele ser de caja negra.
• Una prueba de API puede ser de caja negra o caja gris.
• Una prueba de sistema puede usar caja negra para flujos visibles y caja gris para validar datos internos.
• Una prueba de seguridad puede usar caja negra, blanca o gris según el objetivo.

El mismo sistema puede necesitar varios enfoques para cubrir riesgos diferentes.

12.18 Ejemplo completo: recuperar contraseña

Para una funcionalidad de recuperación de contraseña, podríamos aplicar los tres enfoques:

Este ejemplo muestra cómo los enfoques se complementan. Cada uno observa un aspecto distinto del mismo problema.

12.19 Errores comunes

Al trabajar con estos enfoques, algunos errores frecuentes son:

• Creer que caja negra es menos técnica o menos importante.
• Confiar solo en caja blanca porque el código tiene alta cobertura.
• Diseñar pruebas sin considerar requisitos ni reglas de negocio.
• Mirar solo la pantalla y no validar efectos importantes en datos o integraciones.
• Probar detalles internos frágiles que cambian sin afectar el comportamiento.
• No comunicar qué enfoque se usó y qué riesgos quedaron fuera.

La solución es elegir conscientemente el enfoque según el objetivo de la prueba.

12.20 Buenas prácticas

Para aplicar estos enfoques de manera efectiva conviene:

• Usar caja negra para validar comportamiento visible y reglas de negocio.
• Usar caja blanca para cubrir lógica interna compleja.
• Usar caja gris para probar efectos internos importantes sin perder la mirada funcional.
• Combinar enfoques en funcionalidades críticas.
• No depender solo de cobertura de código como medida de calidad.
• Diseñar pruebas desde riesgos y resultados esperados.
• Documentar precondiciones, datos y evidencias cuando se usen validaciones internas.
• Evitar pruebas demasiado atadas a detalles internos que no aportan valor.

12.21 Qué debes recordar de este tema

• Caja negra prueba el comportamiento externo sin mirar el código.
• Caja blanca prueba usando conocimiento interno del sistema.
• Caja gris combina comportamiento externo con conocimiento técnico parcial.
• Caja negra es muy útil para requisitos, reglas de negocio y experiencia de usuario.
• Caja blanca es muy útil para lógica interna, ramas y caminos de código.
• Caja gris es frecuente en proyectos reales donde el tester conoce datos, APIs, logs o arquitectura.
• Los tres enfoques se pueden combinar con niveles y tipos de prueba.
• Ningún enfoque por sí solo cubre todos los riesgos.

12.22 Conclusión

Las pruebas de caja negra, caja blanca y caja gris ofrecen tres formas distintas de mirar el software. La caja negra se enfoca en lo que el sistema hace, la caja blanca en cómo está construido y la caja gris en una combinación de comportamiento y conocimiento interno.

Un buen proceso de testing no se limita a una sola mirada. Usa caja negra para validar el comportamiento esperado, caja blanca para revisar lógica interna y caja gris para cubrir efectos técnicos relevantes que no siempre son visibles desde afuera.

En el próximo tema estudiaremos casos de prueba, escenarios de prueba y suites de prueba, conceptos fundamentales para organizar el trabajo de testing.