Las pruebas de caja negra en la ingeniería de software examinan un producto desde fuera, sin ver el código fuente, exactamente igual que lo usan sus clientes. Esa limitación es deliberada, porque quienes pagan por el producto tampoco ven lo que hay dentro. Aun así encuentran las partes rotas a los pocos días de un lanzamiento.
También hay una razón comercial para tenerlo en cuenta. Los evaluadores que nunca reciben su código no pueden filtrarlo, y por eso muchas empresas contratan a un socio externo para las pruebas manuales en lugar de abrir sus sistemas.
En esta guía le explicaremos en detalle las pruebas de caja negra y sus cuatro técnicas principales. También hablaremos de cuándo conviene usar pruebas de caja negra o de caja blanca en proyectos reales.
Qué son realmente las pruebas de caja negra en la ingeniería de software
El nombre está tomado de la ingeniería, donde una caja negra es cualquier sistema que se juzga únicamente por lo que entra y lo que sale. Los evaluadores trabajan del mismo modo. Algunos no tienen acceso al código y el resto elige no mirarlo.
La profesión tiene una segunda etiqueta para esto, pruebas basadas en especificaciones, y esa describe el trabajo con más honestidad. ISTQB, el organismo que mantiene la terminología estándar para evaluadores de todo el mundo, lo define como un enfoque de pruebas basado en la especificación de un componente o un sistema. Dicho claramente, alguien escribe lo que se supone que debe hacer el producto y un evaluador comprueba si lo hace exactamente.
Un evaluador no necesita saber cómo se construyó el software. Trabaja a partir de los requisitos, las descripciones de funcionalidades y las pantallas que tiene delante, y luego compara lo que ocurre con lo que se prometió.
En cambio, las pruebas de caja blanca parten del extremo opuesto. El ingeniero lee el código fuente y traza cada decisión que toma, como enviar a los clientes de pago por un camino y a los usuarios gratuitos por otro. Cada una de esas decisiones recibe entonces su propia prueba, de modo que nada quede sin comprobar por dentro.
Qué ve el evaluador
El producto tal como lo ve un cliente
El código fuente y cada decisión que contiene
En qué se basan las pruebas
Requisitos y especificaciones
Estructura y lógica del código
Quién suele ejecutarlas
Ingenieros de control de calidad, socios externos, usuarios reales
Desarrolladores y cualquiera con acceso al código
Qué detectan mejor
Funcionalidades rotas, flujos confusos, reglas ausentes
Ramas sin probar, código muerto, lógica defectuosa
Qué habilidades exigen
Conocimiento del producto y del dominio
Conocimientos de programación
Acceso al código fuente
No es necesario
Imprescindible
Ninguno de los dos enfoques gana de forma absoluta, porque responden a preguntas distintas. Uno le dice si el producto cumple su función. El otro muestra si el código que hay debajo es sólido. La mayoría de los equipos sanos aplican ambos, en momentos diferentes y normalmente con personas distintas.
Las cuatro técnicas principales de pruebas de caja negra
No se puede probar todo. Por ejemplo, un formulario de reserva con solo cinco preguntas, cada una con diez respuestas posibles, ya produce 100.000 combinaciones. Como nadie tiene tiempo de recorrerlas una por una, los especialistas usan cuatro técnicas de pruebas de caja negra que reducen la lista a las comprobaciones con más probabilidades de encontrar errores reales.
Particiones de equivalencia: probar un valor de cada grupo
El software rara vez trata cada entrada como única. Las clasifica en grupos y aplica la misma regla a cada uno.
Imagine un formulario de registro que acepta solicitantes de 18 a 65 años. Todos los que están dentro de ese rango reciben el mismo trato, así que probar 34 y después 47 no le enseña nada nuevo. Aquí existen en realidad tres resultados: demasiado joven, aceptado y demasiado mayor. Las particiones de equivalencia consisten en elegir un valor de cada grupo y confiar en que represente al resto.
Esas 48 edades aceptadas necesitan una sola prueba entre todas, mientras que los dos grupos rechazados requieren una cada uno. Esta técnica también cubre entradas que deberían fallar, como letras escritas en un campo numérico o una casilla dejada vacía, y sondear eso de forma deliberada se llama pruebas negativas.
Análisis de valores límite: probar los bordes de cada grupo
Los errores se acumulan en los bordes de cada grupo, es decir, en los puntos exactos donde la respuesta pasa de aceptado a rechazado. El formulario de registro de nuestro ejemplo tiene dos: el paso de 17 a 18 y el paso de 65 a 66.
Aquí es donde se tuerce. La regla dice que los solicitantes deben tener 18 años o más, pero quien construye el formulario lo escribe como «mayores de 18». Esas dos frases parecen idénticas hasta que alguien de 18 años intenta registrarse y es rechazado.
Por eso se prueban los valores a ambos lados de cada borde: 17 y 18 abajo, 65 y 66 arriba. Son cuatro comprobaciones, y detectan un fallo que se cuela en el software constantemente. Nuestra guía sobre el análisis de valores límite va más allá e incluye cómo se aplica la misma idea a fechas, tamaños de archivo y la cantidad de registros que un sistema acepta a la vez.
Pruebas con tablas de decisión: mapear cada combinación de reglas
Algunos comportamientos dependen de varias condiciones a la vez, y ahí es donde los equipos pierden el hilo. Una tabla de decisión enumera cada condición y luego detalla qué debe ocurrir en cada combinación.
Supongamos que su proceso de compra ofrece envío gratuito en pedidos superiores a 50 dólares, y que los miembros del programa de fidelización acumulan puntos con todo lo que compran. Dos condiciones producen cuatro resultados:
No
No
Gastos de envío de 5 dólares
No
Sí
Gastos de envío de 5 dólares, puntos añadidos
Sí
No
Envío gratuito
Sí
Sí
Envío gratuito, puntos añadidos
Escrito así, las lagunas se vuelven evidentes. Los equipos revisan de forma rutinaria la primera fila y la última, y luego lanzan sin probar las dos intermedias. Ahí es exactamente donde un miembro que gasta 40 dólares paga la tarifa correcta y nunca recibe sus puntos.
Añada una tercera condición, como un código de descuento, y la tabla se duplica hasta ocho filas. Ese crecimiento es precisamente el objetivo, porque cada línea nueva es una combinación con la que sus clientes acabarán topándose, la haya probado alguien antes o no.
Pruebas de transición de estados: seguir el camino que recorre el usuario
Ciertas funcionalidades se comportan de forma distinta según lo que haya pasado antes, y ese historial es lo que examina esta técnica. El software está en un estado, un evento lo mueve a otro y el evaluador sigue el recorrido.
El bloqueo de cuentas es el ejemplo más claro. Al principio, todos están en regla. Después, una contraseña incorrecta suma un aviso, una segunda añade otro y una tercera bloquea el acceso durante 15 minutos. Sin embargo, acertar en cualquier momento debería borrar ese recuento y dejar entrar a la persona.
Recorrer ese camino revela las comprobaciones que merece la pena hacer:
- El recuento de intentos debería reiniciarse por completo, sin dejar nada del martes que se combine con dos más el viernes.
- El bloqueo debería liberarse solo al cabo de 15 minutos, en lugar de mantenerse hasta que intervenga el soporte.
- Una cuenta bloqueada debería rechazar nuevos intentos mientras espera.
Ninguna de estas comprobaciones requiere acceso al código fuente. Solo necesitan a alguien dispuesto a seguir la secuencia completa en lugar de probar cada pantalla por separado.
Dónde encajan las pruebas de caja negra en su proceso de desarrollo
El trabajo de caja negra puede empezar en cuanto existen requisitos escritos, lo que es antes de lo que la mayoría de los equipos supone. Los evaluadores diseñan los casos a partir de la propia especificación, así que la preparación comienza mientras los desarrolladores todavía están construyendo.
Se convierte en el método principal en dos etapas posteriores:
- Las pruebas de sistema examinan el producto ensamblado frente a lo que se especificó, cubriendo el conjunto y no sus partes.
- Las pruebas de aceptación del usuario preguntan a las personas que solicitaron el software si resuelve su problema. Esos revisores nunca han visto el código y no lo necesitan. Eso son pruebas de caja negra en su forma más pura.
Las pruebas alfa y beta pertenecen a la misma familia. Ambas ponen una versión en manos de usuarios reales y observan qué se rompe, un grupo dentro de la empresa y otro fuera. Nuestra comparación de pruebas alfa y beta explica en qué se diferencian en la práctica.
Sin embargo, este método no puede demostrar que se haya ejecutado cada línea de su código. Una funcionalidad puede superar todas sus comprobaciones externas mientras una rama entera de la lógica permanece intacta detrás, esperando una entrada poco habitual. Los desarrolladores cierran esa brecha con pruebas unitarias, pequeños programas escritos para inspeccionar el código directamente. Las pruebas de automatización vuelven a ejecutar entonces los escenarios de cara al usuario en cada compilación, de modo que se entera al instante si algo que funcionaba deja de hacerlo. Estos esfuerzos se complementan en lugar de competir.
Por qué las pruebas de caja negra importan cuando externaliza el control de calidad
Entregar su código fuente a una empresa externa es una decisión con peso legal. Los contratos se alargan, las revisiones de seguridad entran en juego y algunas organizaciones sencillamente se niegan.
Las pruebas de caja negra evitan esa decisión por completo. Un socio que aplique estas técnicas solo necesita sus requisitos, una versión funcional y unas cuantas cuentas con las que iniciar sesión. Como su código nunca sale de su empresa, sus abogados tienen mucho menos que revisar. Las pruebas pueden empezar en días en lugar de esperar a una aprobación.
Eso también significa que un socio externo puede incorporarse a un proyecto en cualquier etapa, sin necesidad de una versión terminada ni de una entrega de código. Un equipo de control de calidad especializado puede empezar por la mitad del producto que ya funciona mientras sus ingenieros completan el resto.
Así se ve en la práctica: Escuela Coaching, con sede en Madrid, pidió una revisión independiente de su plataforma en línea antes del lanzamiento. Nuestros ingenieros probaron los portales del coach y del cliente en 7 dispositivos en aproximadamente un mes y reportaron más de 100 defectos. Hoy la plataforma da servicio a más de 300 organizaciones.
El mismo razonamiento se aplica a la seguridad. Las pruebas dinámicas de seguridad de aplicaciones sondean un sistema en funcionamiento desde fuera, buscando debilidades sin leer una sola línea de código fuente. Eso sitúa a las pruebas de seguridad de aplicaciones web en la misma familia y las convierte en otro trabajo que un especialista externo puede asumir sin su código.
Las pruebas de caja negra son una elección, no un compromiso
Trabajar sin el código fuente parece una carencia del método hasta que se ve lo que aporta. Las comprobaciones reflejan cómo usan el producto los clientes reales, y quienes las ejecutan nunca necesitan acceder a su código. Juntos, esos dos hechos explican por qué tantas pruebas se encargan a un equipo externo.
QAwerk aplica estas técnicas en nuestras pruebas manuales, de sistema y de aceptación. Para averiguar cuáles necesita realmente su próxima versión, hable con nuestros ingenieros de control de calidad.
¿Qué son las pruebas de caja negra en la ingeniería de software?
Las pruebas de caja negra en la ingeniería de software consisten en juzgar un producto por lo que hace, no por cómo se construyó. Un evaluador trabaja a partir de los requisitos y de las pantallas, nunca del código fuente. También se conocen como pruebas basadas en especificaciones, el enfoque estándar para las pruebas de sistema, las pruebas de aceptación y la mayor parte del control de calidad manual.
¿Cuáles son las principales técnicas de pruebas de caja negra?
Cuatro técnicas cubren la mayoría de las situaciones. Las particiones de equivalencia dividen las entradas en grupos que se comportan igual y después prueban un miembro de cada uno. El análisis de valores límite apunta a los valores justo donde una regla empieza o deja de aplicarse. Las pruebas con tablas de decisión recorren cada combinación de condiciones. Las pruebas de transición de estados comprueban cómo responde una funcionalidad a medida que cambia su estado.
¿Se pueden automatizar las pruebas de caja negra?
Sí, y la mayoría de los equipos automatiza las partes repetitivas. Un script puede rellenar un formulario, enviarlo y confirmar la respuesta sin que nadie mire, lo que encaja con todo lo que se repite en cada compilación. El trabajo exploratorio y los juicios sobre si una pantalla tiene sentido de verdad se siguen haciendo a mano. La mayoría de los productos acaban con una mezcla de ambos.
¿Los evaluadores de caja negra necesitan saber programar?
No. Estas técnicas dependen de entender el producto, a sus usuarios y los requisitos escritos, no de leer código. Muchos ingenieros de control de calidad aprenden scripting con el tiempo, y eso amplía lo que pueden asumir. Sin embargo, diseñar casos de prueba a partir de una especificación no requiere ninguna formación en desarrollo.
¿Cuándo conviene usar pruebas de caja negra?
Recurra a ellas siempre que la pregunta sea si el producto funciona para sus usuarios. Encajan en las pruebas de sistema y de aceptación, en lanzamientos con presión de plazos y en cualquier acuerdo en el que no convenga entregar el código fuente a un proveedor. Combínelas con las pruebas unitarias de los desarrolladores, porque ninguno de los dos enfoques cuenta por sí solo la historia completa.
Vea cómo Escuela Coaching lanzó su plataforma de coaching en línea a tiempo después de que probáramos ambos portales en 7 dispositivos y reportáramos más de 100 defectos.
