Las pruebas de caja blanca revisan el software desde dentro. En lugar de hacer clic como un cliente, el tester estudia el código fuente y confirma que cada una de las decisiones de sí o no del programa se pone a prueba de verdad. El método importa sobre todo donde los errores se esconden del uso normal, como en los controles de seguridad, las reglas de negocio complejas y el código escrito por IA.
El manejo de errores es un caso típico: el mensaje previsto para una caída del sistema de pagos solo se ejecuta cuando el proveedor falla, normalmente delante de clientes reales. En cambio, las pruebas de caja negra juzgan un producto por lo que ven los usuarios, así que un código así puede pasar meses sin probarse. Por eso, los equipos sólidos combinan ambos métodos. Esta guía explica en términos sencillos las principales técnicas de pruebas de caja blanca y cuándo las comprobaciones internas superan a las externas. También verás cómo un equipo de QA dedicado se encarga del trabajo junto a tus desarrolladores.
Preparación de las pruebas de caja blanca: qué aportas tú y qué aportan los testers
Tu parte de la preparación es dar acceso al código. Los testers trabajan en el repositorio, el almacenamiento compartido donde tus desarrolladores guardan los archivos fuente. En QAwerk configuramos ese acceso según tus requisitos de seguridad y cumplimiento normativo.
El equipo de pruebas aporta todo lo demás:
- Conocimientos de programación: leer código exige saber programar, por lo que las pruebas de caja blanca las realizan desarrolladores o ingenieros de automatización de QA, cuyo trabajo diario consiste en escribir scripts que comprueban el software.
- Herramientas de cobertura: estas herramientas miden qué parte de la aplicación se ejecutó durante las pruebas y expresan el resultado como un porcentaje, conocido como cobertura de código.
Con esa preparación lista, la mayor parte del trabajo se hace mediante pruebas unitarias, pequeños fragmentos de código que examinan una parte del programa cada vez. Un producto típico necesita miles de ellas, así que las pruebas de automatización vuelven a ejecutar el conjunto completo con cada cambio. Las pruebas unitarias son la capa base, por debajo de comprobaciones más amplias como las pruebas de extremo a extremo y de integración.
Cinco técnicas de pruebas de caja blanca: de la más ligera a la más estricta
Las cinco técnicas siguientes miden la cobertura con una profundidad creciente, y las más estrictas revisan el código a fondo. Todas usan el mismo ejemplo, la regla de reembolso de una tienda online. La tienda devuelve el dinero al cliente de forma automática cuando se cumplen dos cosas: la compra tiene menos de 30 días y el artículo sigue sin abrir.
Cobertura de sentencias: ejecutar cada línea al menos una vez
La cobertura de sentencias confirma que cada línea de código se ejecuta al menos una vez durante las pruebas. En nuestro ejemplo, una sola prueba con un pedido reciente y sin abrir recorre toda la regla de reembolso, porque la lógica solo contempla el pago. Sin embargo, nadie ha comprobado qué ocurre cuando una solicitud se rechaza, por ejemplo si el cliente llega a saber que la respuesta fue no. Por eso, la cobertura de sentencias sirve como primer paso antes de técnicas más estrictas.
Cobertura de ramas: recorrer cada bifurcación en ambos sentidos
La cobertura de ramas, también llamada cobertura de decisiones, hace que cada decisión de sí o no del código vaya en ambos sentidos. El ejemplo necesita ahora dos pruebas: un pedido que cumple los requisitos y una solicitud rechazada. La segunda prueba revela que los clientes rechazados nunca reciben respuesta, y por eso muchos equipos consideran la cobertura de ramas el mínimo práctico.
Cobertura de condiciones: que cada comprobación sea verdadera y falsa
Nuestra regla contiene dos condiciones separadas: la antigüedad del pedido y si el artículo sigue precintado. La cobertura de condiciones hace que cada condición resulte verdadera en una prueba y falsa en otra. Dos pruebas cumplen ese requisito: un pedido reciente con la caja abierta y un artículo precintado comprado hace meses. Sin embargo, ninguna de las dos provoca un reembolso, así que la cobertura de condiciones por sí sola puede pasar por alto justo el resultado para el que existe la regla.
MC/DC: demostrar que cada condición importa por sí sola
La cobertura de condición/decisión modificada, o MC/DC, corrige el punto ciego que deja la cobertura de condiciones. Las pruebas deben demostrar que cambiar una sola condición, manteniendo todo lo demás igual, altera el resultado final. Para la regla de reembolso hacen falta tres pruebas:
- Un artículo reciente y precintado: reembolso aprobado
- El mismo artículo precintado, comprado hace dos meses: sin reembolso
- Un artículo reciente que ya se ha abierto: sin reembolso
Las normas de seguridad exigen este nivel para los sistemas más críticos. Por ejemplo, la norma aeronáutica DO-178C exige MC/DC para el código cuyo fallo podría derribar un avión. Del mismo modo, la norma ISO 26262 de la industria del automóvil recomienda MC/DC para las funciones del vehículo de la categoría de riesgo más alta. Si desarrollas para coches, desde la asistencia a la conducción hasta las aplicaciones del salpicadero, descubre cómo funcionan nuestras pruebas de software para automoción.
Cobertura de caminos: seguir cada ruta a través del código
La cobertura de caminos prueba todas las rutas posibles a través de un fragmento de código, de la primera línea a la última. Para la regla de reembolso bastan unas pocas pruebas. Sin embargo, el software real rara vez es tan sencillo. Cada decisión adicional duplica el número de rutas, y un bucle, un bloque de código que se repite, puede elevar el total más allá de lo que nadie podría probar. Por eso, los equipos reservan la cobertura de caminos para funciones pequeñas y de alto riesgo, como los cálculos de pagos.
Así se comparan las cinco técnicas de pruebas de caja blanca:
Cobertura de sentencias
Cada línea se ejecuta al menos una vez
Qué pasa cuando la respuesta es «no»
Software aeronáutico con riesgo de fallo grave (DO-178C nivel C)
Cobertura de ramas
Cada decisión va en ambos sentidos
Una condición que nunca se prueba por separado
Aviación nivel B; el mínimo práctico para muchos equipos
Cobertura de condiciones
Cada condición es verdadera y falsa
El resultado para el que existe la regla
Rara vez se exige por sí sola
MC/DC
Cada condición cambia el resultado de forma independiente
Rutas creadas por bucles
Aviación nivel A; recomendada para el nivel de seguridad automotriz más alto
Cobertura de caminos
Cada ruta de principio a fin
Nada en teoría, pero la cobertura total suele ser imposible
Ninguna norma; se usa en funciones pequeñas y críticas
Por qué probar cada línea de código no significa software sin errores
La cobertura de código, la parte de un programa que se ejecuta durante las pruebas de caja blanca, es fácil de medir y fácil de malinterpretar. Sin embargo, ese porcentaje no indica si las pruebas comprobaron los resultados correctos. Una prueba que ejecuta una línea sin verificar la respuesta cuenta igualmente para la cobertura, así que un equipo puede alcanzar el 90% y aun así publicar un cálculo erróneo.
Las pruebas de mutación son la forma en que los equipos cuidadosos comprueban las propias pruebas. Una herramienta introduce en el código pequeños errores deliberados, como cambiar «mayor que» por «menor que», y vuelve a ejecutar todas las pruebas. Si nada falla, esas pruebas son demasiado débiles para detectar errores reales. Meta ya usa IA para introducir errores que las comprobaciones existentes no detectan y después escribir pruebas nuevas que los atrapan. En pruebas en Messenger y WhatsApp, los ingenieros revisaron las pruebas escritas por la IA y conservaron el 73% de las sugerencias para proteger esas aplicaciones de errores similares en el futuro.
Un segundo problema son las pruebas inestables, comprobaciones que pasan en una ejecución y fallan en la siguiente aunque nadie haya cambiado el código. La causa suele estar fuera del propio programa, como la sincronización, las respuestas lentas de la red o los datos que deja una prueba anterior. Cuando un equipo se acostumbra a ignorar esos fallos aleatorios, un error real puede pasar desapercibido. El porcentaje sigue pareciendo sano, pero nadie distingue los problemas reales de las falsas alarmas. Por esa razón, las pruebas inestables deben corregirse antes de que nadie se fíe de un informe de cobertura.
Pruebas de caja blanca vs caja negra: dos visiones de un mismo producto
Las pruebas de caja blanca vs caja negra son menos una elección que un reparto de tareas: las comprobaciones de caja negra cubren el producto terminado desde el lado del cliente, y las pruebas de caja blanca examinan el propio código, a menudo antes de que una función llegue a aparecer en pantalla.
Cada enfoque encuentra además errores que el otro rara vez alcanza. Las pruebas desde fuera detectan un proceso de pago confuso o una regla que falta en los requisitos. Por otro lado, las comprobaciones a nivel de código detectan una línea que nunca se ejecuta o un error que se ignora sin avisar. Las pruebas de caja negra se explican a fondo en otro artículo, incluido por qué muchas empresas externalizan ese trabajo sin compartir nada de código.
En la práctica, muchas empresas reparten el trabajo entre sus desarrolladores internos y un socio de QA. En Zazu, una aplicación de finanzas personales, los ingenieros de la propia empresa se encargaron de todas las pruebas unitarias. Nosotros asumimos las pruebas de aceptación, que confirman que la aplicación hace lo que pidió el negocio, y las pruebas de regresión, que vuelven a comprobar las funciones existentes tras cada actualización.
Cuándo importan más las pruebas de caja blanca
Las comprobaciones a través de las pantallas cubren lo que la gente hace normalmente, pero algunos riesgos están en código que los usuarios rara vez activan. Las pruebas de caja blanca aportan más valor en tres áreas:
- Código crítico para la seguridad: el código de inicio de sesión, pagos y permisos puede funcionar perfectamente en pantalla y aun así saltarse las comprobaciones de los datos que envían los usuarios. Un atacante puede aprovechar ese descuido, por ejemplo enviando una solicitud manipulada para abrir la cuenta de otra persona. El código que falla de forma grave cuando algo sale mal es igual de peligroso. En 2025, el OWASP Top 10, una clasificación muy utilizada de los mayores riesgos para las aplicaciones web, añadió una categoría para el código que gestiona mal los errores y las situaciones inesperadas. Las API, las conexiones que permiten a tus aplicaciones intercambiar datos, están expuestas a ambos problemas y merecen pruebas de seguridad de API específicas. Las herramientas de análisis estático, a menudo llamadas SAST, leen el código fuente y señalan debilidades como estas. Nuestras pruebas de seguridad combinan después esa revisión automatizada con ataques simulados contra el producto en funcionamiento.
- Lógica de decisión compleja: en julio de 2024, una actualización defectuosa de CrowdStrike bloqueó ordenadores con Windows en todo el mundo. Según el análisis de la causa raíz de la empresa, el software esperaba 21 datos de entrada pero recibió solo 20. El desajuste pasó desapercibido en parte porque las pruebas rellenaban la posición 21 con un valor comodín que coincidía con cualquier cosa. Como resultado, el código que falla cuando falta ese dato nunca se ejecutó antes del lanzamiento. Las pruebas de caja blanca están pensadas para detectar problemas así, porque los testers leen el código fuente y prueban cada valor del que depende el programa. Entre las correcciones de CrowdStrike se incluyeron comprobaciones automáticas para cada dato de entrada.
- Código escrito por IA: en Google, el 75% de todo el código nuevo ya lo genera la IA y lo aprueban ingenieros. Aun así, cuando Veracode probó más de 100 modelos de IA, el 45% de las muestras de código introdujo una vulnerabilidad de seguridad conocida. En el lado positivo, la IA también puede redactar pruebas unitarias para que los ingenieros las revisen, uno de los casos de uso de la IA generativa en las pruebas de software con un retorno real.
Cómo realiza QAwerk las pruebas de caja blanca junto a las comprobaciones externas
Los proyectos a nivel de código en QAwerk suelen seguir cuatro pasos:
- Acordar el acceso. Antes de abrir ningún archivo, confirmamos quién puede ver qué y en qué condiciones.
- Revisar el código. Repasamos el manejo de errores, la lógica de riesgo y las zonas difíciles de probar, y después explicamos en lenguaje claro qué hay que corregir.
- Cerrar las brechas. Los ingenieros de automatización añaden pruebas donde la cobertura es escasa, empezando por las partes que gestionan dinero, inicios de sesión y datos personales.
- Automatizar las repeticiones. Las comprobaciones añadidas se incorporan a tu pipeline de compilación, el proceso automatizado que monta cada nueva versión, para que los problemas salgan a la luz antes del lanzamiento.
Cada proyecto es un poco distinto:
- Una revisión de código antes de escalar: para Couple Up!, un desarrollador sénior de Python revisó el servidor del juego según cuatro criterios: calidad del código, manejo de errores, caché (reutilizar resultados guardados para ganar velocidad) y facilidad para probar el software. Las conclusiones también recomendaban pruebas unitarias y de integración.
- Pruebas en cada commit: para Kazidomi, 284 pruebas automatizadas se ejecutaban después de cada commit, una actualización guardada en el repositorio de GitLab de la empresa.
- Pruebas elegidas leyendo el cambio: junto con los ingenieros de Granola, creamos un flujo con IA que analiza cada pull request, una propuesta de cambio de código, y selecciona los casos de prueba más relevantes.
En cada uno de estos proyectos, el trabajo a nivel de código se hizo en paralelo a las pruebas habituales del software terminado. Las pruebas externas muestran si los clientes reciben lo prometido, mientras que la visión interna demuestra que no se ha saltado nada importante por el camino. Nuestros ingenieros de automatización se encargan de las pruebas de caja blanca, y las pruebas manuales cubren lo que tus usuarios notan primero. Solicita una revisión de tu código antes de que los errores ocultos lleguen a tus clientes.
Preguntas frecuentes
¿Qué son las pruebas de caja blanca?
Las pruebas de caja blanca son un método de pruebas de software en el que el tester puede ver el código fuente del programa y diseña las comprobaciones según cómo funciona la aplicación por dentro. En lugar de confirmar solo lo que aparece en pantalla, las pruebas de caja blanca se aseguran de que cada línea, cada decisión de sí o no y cada ruta de error se ejecuten de verdad. El método también se conoce como pruebas de caja transparente, de caja de cristal o pruebas estructurales.
¿Las pruebas unitarias son lo mismo que las pruebas de caja blanca?
Las pruebas unitarias y las pruebas de caja blanca se solapan, pero los términos describen cosas distintas. La palabra «unitaria» se refiere al tamaño: una pequeña parte del software, como una sola función, comprobada de forma aislada. Las pruebas de caja blanca nombran el enfoque de diseñar pruebas con el código fuente a la vista. La mayoría de las pruebas unitarias se escriben así, pero los métodos de caja blanca también abarcan revisiones de código, análisis de seguridad y componentes completos.
¿Quién realiza las pruebas de caja blanca?
Normalmente son los desarrolladores quienes se encargan de las pruebas de caja blanca, ya que el trabajo exige leer y entender el código fuente. Los equipos más grandes suman ingenieros de automatización de QA, a menudo con el título de SDET, que escriben código de prueba y revisan los resultados con independencia de los autores originales. Una empresa especializada en QA puede asumir el mismo papel una vez que el cliente da al equipo de pruebas acceso a la base de código, es decir, a todo el código fuente del producto.
¿Qué es la cobertura de código en las pruebas de caja blanca?
La cobertura de código en las pruebas de caja blanca es un porcentaje que muestra qué parte de una aplicación se ejecuta mientras se realizan las pruebas. Una herramienta de medición registra cada línea y cada decisión, y después informa de qué se alcanzó y qué se omitió. Una puntuación alta significa que la mayor parte del programa se ejecutó. Sin embargo, la cifra por sí sola no muestra si cada comprobación verificó el resultado correcto, así que los equipos también revisan la calidad de las propias pruebas.
¿Qué son las pruebas de caja gris?
Las pruebas de caja gris son un punto intermedio entre las pruebas de caja blanca y las de caja negra. El tester conoce parte del diseño interno, por ejemplo la estructura de la base de datos o cómo intercambian datos los servicios, pero trabaja a través de las pantallas y funciones normales del producto. Ese conocimiento parcial ayuda a centrarse en los puntos de conexión y en los puntos débiles de seguridad que alguien de fuera tendría que adivinar.
Mira una muestra de nuestra revisión de código de seguridad de una plataforma de comercio electrónico con sede en EE.UU.
