La mayoría de los ingenieros de automatización QA no encajan limpiamente en ninguna de las dos categorías: testean el comportamiento visible desde la perspectiva del usuario (caja negra), pero conocen la estructura de la API, pueden leer código para entender los casos extremos y revisan los reportes de cobertura para encontrar vacíos (elementos de caja blanca). La distinción importa porque cada enfoque está optimizado para bugs distintos: la caja negra detecta discrepancias de requisitos y fallos de comportamiento en la UI, la caja blanca detecta rutas de código sin testear y errores de lógica interna. Este artículo explica qué cubre cada una, qué técnicas pertenecen a cada enfoque, y cómo los tres modos aparecen en la misma función durante un sprint típico.

Testing de caja negra

En el testing de caja negra testeas el sistema sin conocimiento ni referencia a su implementación interna. Tratas el software como una "caja negra": entra un input, sale un output, y no importa qué pasa adentro.

Testeas basándote enteramente en los requisitos ("cuando el usuario ingresa X, debería ocurrir Y"), las especificaciones ("el campo acepta entre 1 y 100 caracteres") y las expectativas del usuario ("esto debería funcionar como cualquier formulario de login estándar").

No miras el código. No sabes, o al menos no te apoyas en saber, qué framework se está usando, cómo se almacenan los datos o qué algoritmo ejecuta el cálculo.

Cómo se ve el testing de caja negra

  • Testear un formulario de login ingresando credenciales válidas e inválidas
  • Verificar que hacer clic en "Agregar al carrito" agrega el ítem correcto
  • Comprobar que una API devuelve los datos correctos para una solicitud válida
  • Confirmar que aparece un mensaje de error cuando un campo obligatorio está vacío
  • Ejecutar tests end-to-end en Playwright

Técnicas del testing de caja negra

  • Partición de equivalencia: dividir los inputs en grupos válidos e inválidos
  • Análisis de valores límite: testear en los extremos de los rangos de input
  • Testing de tabla de decisiones: testear combinaciones de condiciones
  • Testing de transición de estados: testear cómo el sistema se mueve entre estados
  • Testing de casos de uso y escenarios: testear basándose en flujos reales del usuario

Ventajas

  • Testeas lo que los usuarios realmente experimentan, no lo que los desarrolladores creen que construyeron
  • No requiere conocimiento de programación (para el testing funcional de caja negra)
  • Detecta discrepancias de requisitos: cuando la especificación decía una cosa y la implementación hizo otra
  • Funciona desde el primer día, incluso antes de que el sistema esté construido (puedes escribir casos de prueba a partir de los requisitos)

Desventajas

Puedes perderte rutas del código que ningún requisito cubre explícitamente (código muerto, ramas de error). Sin conocer el código, puedes testear la misma lógica muchas veces y perderte otras rutas por completo. No puede verificar cosas que no son visibles desde afuera, como pérdidas de memoria o corrupción interna de datos.

Testing de caja blanca

En el testing de caja blanca testeas con conocimiento de la implementación interna. Conoces el código, la lógica, las estructuras de datos y los algoritmos, y usas ese conocimiento para diseñar los tests.

También se llama: testing de caja de cristal, testing de caja transparente, testing estructural o testing basado en código.

Cómo se ve el testing de caja blanca

  • Escribir unit tests que llaman a funciones directamente y verifican su comportamiento
  • Mirar una rama condicional en el código y escribir un test para cada rama
  • Analizar qué rutas de código no están cubiertas por ningún test existente
  • Verificar que una consulta SQL específica corre correctamente
  • Testear APIs internas o métodos que no están expuestos en la UI

Técnicas del testing de caja blanca

  • Cobertura de sentencias: cada línea de código se ejecuta al menos una vez por los tests
  • Cobertura de ramas: cada rama if/else se ejecuta al menos una vez
  • Cobertura de rutas: cada ruta posible a través del código se testea
  • Testing de mutaciones: cambiar deliberadamente el código para ver si los tests detectan el cambio

Quién lo hace

El testing de caja blanca lo realizan típicamente desarrolladores que escriben unit tests, ingenieros QA que pueden leer código y revisan la cobertura de tests, e ingenieros de seguridad que realizan auditorías de código.

Como ingeniero de automatización QA, estás en el espectro: no escribes unit tests, pero puedes leer el código para entender qué testear y revisar los reportes de cobertura para encontrar vacíos.

Ventajas

  • Encuentra bugs que ningún requisito describe explícitamente: casos extremos en la lógica interna
  • Garantiza la cobertura de código: puedes ver qué rutas están realmente testeadas
  • Más eficiente para el testing de optimización y seguridad
  • Detecta código muerto, ramas no usadas y condiciones imposibles

Desventajas

  • Requiere conocimiento de la implementación: necesita habilidades de programación
  • Puede llevar a testear la implementación en lugar de los requisitos (sesgo de confirmación: testeas lo que el código hace, no lo que debería hacer)
  • No detecta una implementación correcta de un requisito incorrecto
  • Es costoso en tiempo alcanzar una alta cobertura

Testing de caja gris

En la práctica, la mayoría de los ingenieros de automatización QA operan en la zona gris: conocen algunos internos pero testean desde la perspectiva del usuario.

El testing de caja gris significa:

  • Conoces la arquitectura (API REST, base de datos, frontend) pero testeas el comportamiento externo
  • Puedes leer código básico para entender el setup de datos de test pero no escribes unit tests
  • Usas testing a nivel de API (conociendo la estructura del endpoint) para apoyar el testing a nivel de UI
  • Miras el código para entender los casos extremos pero diseñas los tests desde el punto de vista del usuario

Aquí es donde vive la mayoría de los ingenieros QA modernos. No son puramente caja negra (conocen el stack tecnológico) ni puramente caja blanca (no escriben unit tests para funciones internas).

Comparación lado a lado

| | Caja negra | Caja blanca | Caja gris |

|-|------------|-------------|-----------|

| Conocimiento requerido | Solo requisitos | Acceso completo al código | Arquitectura + algo de código |

| Tests basados en | Especificaciones, flujos del usuario | Lógica del código, cobertura | Ambos |

| Quién lo hace | Testers QA, usuarios | Desarrolladores, ingenieros QA | Ingenieros de automatización QA |

| Detecta | Discrepancias de requisitos, bugs de UI | Bugs de lógica, código sin cubrir | Ambas categorías |

| No detecta | Bugs de lógica interna | Requisitos incorrectos | (minimizado) |

| Ejemplo | Testing del formulario de login | Unit tests para lógica de auth | Testing de API + E2E |

Cómo se ve esto en un proyecto real

Día 1: llega la función. Recibes historias de usuario y criterios de aceptación. Escribes los escenarios de test basándote en ellos (caja negra: todavía no hay código). Fase de desarrollo. Los desarrolladores escriben unit tests que cubren las rutas del código (caja blanca). Fase de testing. Ejecutas tus escenarios de test contra la función construida (caja negra). También llamas a la API directamente para configurar los datos de test (caja gris: conoces la estructura del endpoint). Se encuentra un bug. Miras el código para entender por qué ocurre el caso extremo (conocimiento de caja blanca) pero reportás el bug contra el comportamiento, no la implementación (reporte de caja negra). Revisión de cobertura. Verificas qué áreas no tienen tests automatizados y las señalás al equipo (perspectiva de caja blanca aplicada a la planificación).

Los tres modos en la misma función, en el mismo sprint.

En las entrevistas de QA

Pregunta clásica: "Explicá el testing de caja negra vs. caja blanca."

La respuesta esperada: caja negra significa testear sin conocimiento de los internos, basándose en requisitos y comportamiento del usuario; caja blanca significa testear con conocimiento del código, basándose en la cobertura de las rutas lógicas; caja gris (opcional) combina ambas, típico de los ingenieros de automatización que conocen la arquitectura pero testean desde la perspectiva del usuario.

Pregunta de seguimiento: "¿Cuál haces tú?"

La respuesta honesta para la mayoría de los ingenieros de automatización QA: principalmente caja negra (testing E2E del comportamiento visible) con elementos de caja gris (conocimiento de la API, lectura de código para entender el setup de datos de test, revisión de reportes de cobertura).

Conclusión clave

La distinción no es sobre cuál es mejor: son complementarias. El testing de caja negra garantiza que el sistema hace lo que los usuarios y los requisitos esperan. El testing de caja blanca garantiza que la implementación es completa, bien estructurada y exhaustivamente testeada.

En un setup de QA maduro, ambas ocurren: los desarrolladores escriben unit tests de caja blanca, los ingenieros QA escriben tests E2E de caja negra, y la combinación da una cobertura mucho más sólida que cualquiera de las dos por separado.

→ See also: La Pirámide de Tests Explicada para Ingenieros QA | Verificación vs Validación en Testing de Software: ¿Cuál es la Diferencia? | Pruebas Exploratorias: La Habilidad que la IA No Puede Reemplazar