¿Qué Son las Pruebas de Caja Negra?
Las pruebas de caja negra (black-box testing) — también llamadas pruebas de comportamiento, basadas en especificación o pruebas funcionales — diseñan tests basándose completamente en lo que el software debería hacer según sus requisitos y especificaciones. El tester no tiene conocimiento del código interno, la arquitectura ni los detalles de implementación.
Piensa en ello como usar una máquina expendedora. Insertas dinero, presionas un botón y esperas un producto específico. No conoces ni te importa la maquinaria interna — solo verificas que la salida correcta aparece para la entrada dada.
El black-box testing responde la pregunta: “¿Se comporta el sistema según lo especificado?”
¿Quién Realiza las Pruebas de Caja Negra?
Las pruebas de caja negra pueden ser realizadas por:
- QA engineers — los practicantes más comunes, probando contra requisitos
- Analistas de negocio — verificando que las funcionalidades coincidan con las expectativas del negocio
- Usuarios finales — durante las pruebas de aceptación (UAT)
- Desarrolladores — al escribir pruebas de integración o sistema
No se requieren habilidades de programación, lo que lo hace accesible a un rango más amplio de miembros del equipo.
Técnicas Principales de Caja Negra
Las técnicas de caja negra proporcionan métodos sistemáticos para seleccionar entradas de prueba. Estas técnicas se cubren en profundidad en el Módulo 3 (Técnicas de Diseño de Pruebas), pero entender la vista general es esencial en esta etapa.
Partición de Equivalencia (EP)
La partición de equivalencia divide el dominio de entrada en clases (particiones) donde todos los valores dentro de una clase se espera que produzcan el mismo comportamiento. Luego pruebas un valor representativo de cada clase.
Ejemplo: Un campo de edad acepta valores de 18-65.
| Partición | Rango | Valor Representativo | Resultado Esperado |
|---|---|---|---|
| Inválida (debajo) | < 18 | 10 | Error |
| Válida | 18-65 | 30 | Aceptado |
| Inválida (arriba) | > 65 | 80 | Error |
En lugar de probar todos los valores del 0 al 100, pruebas solo tres. La suposición es que si el sistema maneja 30 correctamente, manejará 25, 40 y 55 de la misma manera.
Análisis de Valores Límite (BVA)
El análisis de valores límite (boundary value analysis) se enfoca en los bordes de las particiones de equivalencia, donde es más probable que ocurran bugs. Los errores off-by-one están entre los errores de programación más comunes.
Usando el mismo ejemplo de edad (rango válido 18-65):
| Límite | Valores a Probar | Por Qué |
|---|---|---|
| Límite inferior | 17, 18, 19 | Prueba la transición exacta de inválido a válido |
| Límite superior | 64, 65, 66 | Prueba la transición exacta de válido a inválido |
BVA típicamente prueba el valor límite, uno debajo y uno arriba. Para dos límites, esto produce 6 valores de prueba en lugar de 48 al probar todo el rango.
Tablas de Decisión
Las tablas de decisión se usan cuando el comportamiento del sistema depende de combinaciones de condiciones. Listan sistemáticamente todas las combinaciones posibles y los resultados esperados.
Ejemplo: Un descuento de seguro depende de la edad y el historial de manejo:
| Condición | Regla 1 | Regla 2 | Regla 3 | Regla 4 |
|---|---|---|---|---|
| Edad > 25 | Sí | Sí | No | No |
| Historial limpio | Sí | No | Sí | No |
| Descuento | 15% | 5% | 5% | 0% |
Cada columna representa una combinación única que debe probarse. Con 2 condiciones teniendo 2 valores cada una, hay 2² = 4 reglas.
Pruebas de Transición de Estado
Las pruebas de transición de estado modelan el sistema como una máquina de estados finitos con estados, transiciones y eventos definidos. Las pruebas se diseñan para ejercitar cada estado y transición.
Ejemplo: Una cuenta de usuario puede estar en los estados: Activa, Bloqueada, Suspendida, Eliminada.
Las pruebas verificarían cada transición: ¿Puede reactivarse una cuenta bloqueada después del reset de contraseña? ¿Se elimina la cuenta después de 30 días de estar bloqueada?
Cuándo Usar Black-Box Testing
El black-box testing es más efectivo para:
- Pruebas funcionales — verificar que las funcionalidades operan según lo especificado
- Pruebas de aceptación — usuarios de negocio validando requisitos
- Pruebas de sistema — probar la aplicación completa integrada
- Pruebas de regresión — verificar funcionalidad existente después de cambios
- Pruebas de usabilidad — evaluar la experiencia del usuario
Black-Box vs. White-Box: Comparación
| Aspecto | Caja Negra | Caja Blanca |
|---|---|---|
| Base del test | Requisitos, especificaciones | Código fuente, arquitectura |
| Conocimiento necesario | Dominio, requisitos | Programación, acceso al código |
| Qué encuentra | Requisitos faltantes, errores de comportamiento | Errores de lógica, código muerto |
| Qué no detecta | Errores de lógica interna | Funcionalidades faltantes, usabilidad |
| Quién lo realiza | QA, BA, usuarios | Desarrolladores, SDETs |
| Nivel de testing | Sistema, aceptación, E2E | Unitario, integración |
| Cuándo se diseña | Temprano (desde requisitos) | Requiere código completado |
| Mantenimiento | Bajo (tests sobreviven refactoring) | Alto (tests se rompen con cambios) |
Ningún enfoque es superior. Se complementan mutuamente. Una estrategia madura usa ambos.
Ventajas y Limitaciones
Ventajas:
- Las pruebas se pueden diseñar desde que los requisitos están escritos
- No requiere conocimiento del código — participación más amplia del equipo
- Las pruebas son independientes de la implementación — sobreviven al refactoring
- Detecta vacíos en requisitos y errores de especificación
- Simula la perspectiva del usuario
Limitaciones:
- No puede garantizar cobertura de código — caminos no probados quedan ocultos
- Son posibles tests redundantes (probando el mismo camino interno sin saberlo)
- Difícil diseñar tests para lógica interna compleja sin ver el código
- Puede perder casos borde que son obvios al leer el código
- Requiere especificaciones claras y completas (que son raras en la práctica)
Ejercicio: Diseña Casos de Prueba de Caja Negra desde una Especificación
Estás probando una calculadora de elegibilidad para préstamos con estos requisitos:
Requisitos:
- El solicitante debe tener entre 21 y 65 años (inclusive)
- Ingreso anual mínimo: $25,000
- El puntaje crediticio debe ser 600 o mayor
- El monto del préstamo solicitado debe estar entre $1,000 y $500,000
- Si el puntaje crediticio es 750+ Y el ingreso es $75,000+, la tasa de interés es 3.5% (tasa premium)
- Si el puntaje crediticio es 600-749 O el ingreso es $25,000-$74,999, la tasa de interés es 7.0% (tasa estándar)
- Si algún criterio de elegibilidad falla, la solicitud se rechaza
Parte 1: Partición de Equivalencia. Identifica las particiones de equivalencia para cada campo de entrada.
Parte 2: Análisis de Valores Límite. Identifica los valores límite para cada campo y diseña casos de prueba.
Parte 3: Tabla de Decisión. Crea una tabla de decisión para la determinación de la tasa de interés (requisitos 5 y 6).
Parte 4: Diseña 8-10 casos de prueba completos que proporcionen buena cobertura.
Pista
Para la Parte 1, cada campo de entrada tiene al menos 3 particiones: debajo del rango válido, rango válido y arriba del rango válido. Algunos pueden tener sub-particiones dentro del rango válido (ej. puntaje crediticio tiene niveles estándar y premium).Para la Parte 3, enfócate en las dos condiciones que determinan la tasa: umbral de puntaje crediticio (750) y umbral de ingreso ($75,000). Hay 4 combinaciones.
Solución
Parte 1: Particiones de Equivalencia
Edad:
| Partición | Rango | Representativo | Esperado |
|---|---|---|---|
| Inválida (joven) | < 21 | 18 | Rechazado |
| Válida | 21-65 | 40 | Elegible |
| Inválida (mayor) | > 65 | 70 | Rechazado |
Ingreso:
| Partición | Rango | Representativo | Esperado |
|---|---|---|---|
| Inválida (bajo) | < $25,000 | $15,000 | Rechazado |
| Válida (estándar) | $25,000-$74,999 | $50,000 | Tasa estándar |
| Válida (premium) | $75,000+ | $100,000 | Elegible premium |
Puntaje Crediticio:
| Partición | Rango | Representativo | Esperado |
|---|---|---|---|
| Inválida (bajo) | < 600 | 500 | Rechazado |
| Válida (estándar) | 600-749 | 650 | Tasa estándar |
| Válida (premium) | 750+ | 800 | Elegible premium |
Monto del Préstamo:
| Partición | Rango | Representativo | Esperado |
|---|---|---|---|
| Inválida (bajo) | < $1,000 | $500 | Rechazado |
| Válida | $1,000-$500,000 | $100,000 | Aceptado |
| Inválida (alto) | > $500,000 | $600,000 | Rechazado |
Parte 2: Valores Límite
| Campo | Límites a Probar |
|---|---|
| Edad | 20, 21, 22, 64, 65, 66 |
| Ingreso | $24,999, $25,000, $25,001, $74,999, $75,000, $75,001 |
| Puntaje Crediticio | 599, 600, 601, 749, 750, 751 |
| Monto Préstamo | $999, $1,000, $1,001, $499,999, $500,000, $500,001 |
Parte 3: Tabla de Decisión
| Condición | Regla 1 | Regla 2 | Regla 3 | Regla 4 |
|---|---|---|---|---|
| Crédito ≥ 750 | Sí | Sí | No | No |
| Ingreso ≥ $75,000 | Sí | No | Sí | No |
| Tasa | 3.5% | 7.0% | 7.0% | 7.0% |
Solo la Regla 1 (ambas condiciones cumplidas) califica para la tasa premium de 3.5%.
Parte 4: Casos de Prueba Completos
| # | Edad | Ingreso | Crédito | Préstamo | Resultado Esperado |
|---|---|---|---|---|---|
| 1 | 40 | $100,000 | 800 | $200,000 | Aprobado, 3.5% |
| 2 | 35 | $50,000 | 650 | $100,000 | Aprobado, 7.0% |
| 3 | 18 | $80,000 | 780 | $50,000 | Rechazado (edad < 21) |
| 4 | 30 | $15,000 | 700 | $50,000 | Rechazado (ingreso < $25K) |
| 5 | 30 | $60,000 | 500 | $50,000 | Rechazado (crédito < 600) |
| 6 | 30 | $60,000 | 700 | $600,000 | Rechazado (préstamo > $500K) |
| 7 | 21 | $25,000 | 600 | $1,000 | Aprobado, 7.0% (todos mínimos) |
| 8 | 65 | $500,000 | 850 | $500,000 | Aprobado, 3.5% (todos máximos) |
| 9 | 45 | $100,000 | 700 | $150,000 | Aprobado, 7.0% (ingreso alto, crédito estándar) |
| 10 | 45 | $50,000 | 780 | $150,000 | Aprobado, 7.0% (ingreso estándar, crédito alto) |
Combinando Técnicas de Caja Negra
En la práctica, los testers experimentados combinan múltiples técnicas:
- Comienza con partición de equivalencia para identificar las categorías principales
- Aplica análisis de valores límite a los bordes de cada partición
- Usa tablas de decisión cuando múltiples condiciones interactúan
- Usa pruebas de transición de estado para comportamiento con estados
Esta combinación proporciona cobertura eficiente sin testing exhaustivo. Las técnicas de esta lección se exploran con mayor profundidad en el Módulo 3.
Puntos Clave
- El black-box testing diseña pruebas desde requisitos y especificaciones sin conocimiento del código
- La partición de equivalencia reduce casos de prueba agrupando entradas similares
- El análisis de valores límite apunta a los bordes donde se esconden más bugs
- Las tablas de decisión cubren sistemáticamente combinaciones de condiciones
- Las pruebas de transición de estado verifican el comportamiento entre estados del sistema
- Black-box y white-box se complementan — los equipos maduros usan ambos
- Las pruebas de caja negra son resistentes a cambios de código ya que se basan en comportamiento, no implementación