TIC : Pruebas de caja negra y caja blanca

En el mundo de los sistemas, el término “caja negra/blanca” se emplea para referirse a un elemento del cual se quiere conocer sus resultados sin importar sus maneras o procesos. En ocasiones, a ciertos elementos de un sistema se le aplican unas denominadas pruebas de caja negra/blanca, en donde se introduce información al sistema y se esperan resultados acertados, sin importar como sean logrados.

Las cajas negras sirven para conocer cómo trabaja el conjunto de un sistema sin importar lo que hace (y como lo hace) cada uno de sus módulos. No obstante, también se le llama caja negra a un elemento que no puede ser penetrado ni manipulado desde afuera; lo cual lo hace inaccesible, haciendo visible solo sus resultados.

Caja negra y cajas blancas

Existe también un concepto antagónico, denominado “caja blanca”. Este es el estudio de un módulo (no de un sistema) y sus interacciones internas para lograr los resultados que arroja.

Es decir, sin importar la procedencia de los datos de entrada y salida, las técnicas de caja blanca solo se aplican a lo interno de un módulo.

Pruebas de cajas en sistemas

Las tecnicas de caja negra permiten intuir en base a experiencia y conocimientos, diversos problema que podría generar un software. Para hacer pruebas de caja negra se debe pensar como un usuario y ejecutar funciones comunes.

Al usuario poco le importan los métodos, él solo desea la ejecución de una acción, es decir, resultados.

Por otro lado, las pruebas de caja blanca son un tanto más específicas.

Tas haber detectado el error en un módulo con una prueba de caja negra, se debe conocer un error, ese modulo puede y debe revisarse con pruebas de caja blanca, ya sea manuales o automáticos, para determinar la falla específica y corregirla.

Recorrer los caminos de ejecución es la prueba de caja blanca más utilizada, ya que permite optimizar al máximo la rapidez de un sistema.

Los mejores ejemplos de caja negra y blanca ilustran como ambas son necesarias antes del lanzamiento de un software.

En la práctica y la teoría de sistemas, las pruebas de caja negra  / blanca son los exámenes funcionales más idóneos para encontrar anomalías.

Al estar basadas en los requerimientos de software y en las entradas y salidas de cada funcionalidad, al definir una prueba de caja negra lo principal es identificar los datos de prueba (entradas) y el resultado esperado del sistema al ingresar esos datos, bien sean los datos de salida o algún comportamiento específico.

Puedes descargar la plantilla para crear tu propio registro en el siguiente link

Contenido de la plantilla de casos de prueba:

• Id: Cada caso de prueba debe tener un identificador (código) único.

• Caso de Prueba: Título descriptivo del caso de prueba.

• Descripción: Descripción del caso de prueba, indicando sus elementos, funcionalidades y acciones a ser ejercidas en el caso de prueba.

• Fecha: Fecha en que fue creado el caso de prueba.

• Área Funcional / Subproceso: Describe el área funcional, subproceso o modulo al que está asociado el caso de prueba. La intención es poder dividir los casos de prueba según la estructura jerárquica y casos de uso del sistema que se está probando y los procesos que este soporta.

• Funcionalidad / Característica: Describe el título de la característica o funcionalidad que se está probando. Por ej. Suscripción al Servicio, Entrega de Orden, Selección de Producto, Consulta de Ordenes Pendientes.

• Datos y acciones de entradas: Se especifica cada entrada que se requiere para ejecutar el caso de prueba. Etas entradas pueden ser valores o datos de entrada, y también acciones (por ejemplo presionar un botón). Deben identificarse los archivos o bases de datos involucrados.

• Resultado esperado (Datos de Salida): Se especifica la salida que se espera de la ejecución de los casos de prueba con las entradas indicadas.

Requerimientos de ambiente de pruebas: Cualquier especificación del hardware y software especial requerido para ejecutar el caso de prueba, que no sea común a todos los casos.

Ejemplos de pruebas de caja negra
A continuación enumeramos los ejemplos, presentando para cada uno los datos de entrada y resultado esperado.

Ejemplo 1: Envió de correo electrónico al registrarse una transacción.

Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de cobro al cliente.
Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso
Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que su pedido se ha recibido.
Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que se ha realizado el despacho.
Caso 1.3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema envía un correo electrónico al departamento de facturación y al cliente.
Caso 1.4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema envía un correo electrónico al departamento de cuentas por cobrar y al agente comercial (vendedor) que lleva la cuenta del cliente.
  

Ejemplo 2: Ingreso de pedidos de compra por debajo y por encima de límites de aprobación.

Descripción del caso: Los pedidos de compra que excedan el monto establecido en el flujo de liberaciones de pedidos configurados, deberán pasar por las aprobaciones establecidas en dicho flujo de aprobación.
Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso
Caso 2.1: Datos de entrada: Pedido de compra con un monto inferior al primer límite de aprobación configurado. Resultado esperado (Salida): El sistema registra el pedido con estatus “aprobado”.
Caso 2.2: Datos de entrada: Pedido de compra con un monto superior al primer límite de aprobación configurado. Resultado esperado (Salida): El sistema coloca el pedido con estado “pendiente de aprobación” y lo clasifica en la bandeja de entrada del aprobador. El aprobador puede configurarse en el sistema (usando el nombre de usuario).
Caso 2.3: Datos de entrada: Modificar el límite de aprobación y registrar un pedido de compra con un monto inferior al nuevo límite. Resultado esperado (Salida): El sistema registra el pedido con estatus “aprobado”.
Caso 2.4: Datos de entrada: Modificar el límite de aprobación y registrar un pedido de compra con un monto superior al nuevo límite. Resultado esperado (Salida): El sistema coloca el pedido con estado “pendiente de aprobación” y lo clasifica en la bandeja de entrada del aprobador. El aprobador puede configurarse en el sistema (usando el nombre de usuario).

Ejemplo 3: Campo de texto que solo acepta caracteres alfabéticos.

Descripción del caso: Se tiene un campo de texto que solo acepta caracteres alfabéticos. La longitud del valor ingresado debe estar entre 6 y 10 caracteres.
Técnica de pruebas de caja negra: Partición de equivalencias.
Usando partición de equivalencias, se pueden establecer tres particiones, longitudes entre 0 y 5 caracteres (partición inválida), longitudes entre 6 y 10 caracteres (partición válida), y longitudes mayores a 10 caracteres (partición inválida). Además, el ingreso de caracteres no alfabéticos (por ejemplo un número), se considera también dato inválido.
Caso 3.1: Datos de entrada: cadena de 5 caracteres. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.
Caso 3.2: Datos de entrada: cadena de 7 caracteres, incluyendo uno o más caracteres no alfabéticos. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.
Caso 3.3: Datos de entrada: cadena de 7 caracteres, solo de caracteres alfabéticos. Resultado esperado (Salida): La aplicación permite el ingreso del dato.
Caso 3.4: Datos de entrada: cadena de 11 caracteres. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.  

Ejemplo 4: Campo de texto que solo acepta caracteres alfabéticos (Análisis de valores borde).

Descripción del caso: Se tiene un campo de texto que solo acepta caracteres alfabéticos. La longitud del valor ingresado debe estar entre 6 y 10 caracteres.
Técnica de pruebas de caja negra: Análisis de valores borde.
Tomando el ejemplo 1, podemos definir casos de prueba adicionales si tomamos los valores borde, es decir dado que la aplicación acepta entre 6 y 10 caracteres, los valores borde consistirían en ingresar cadenas de caracteres con estas longitudes. Usualmente las condiciones de error se suelen presentar en estos valores borde, muchas veces relacionado con el manejo inadecuado en programación de restricciones de tipo mayor o menor estricto.
Caso 4.1: Datos de entrada: cadena de 6 caracteres, sólo caracteres alfabéticos. Resultado esperado (Salida): La aplicación permite el ingreso del dato.
Caso 4.2: Datos de entrada: cadena de 10 caracteres, sólo caracteres alfabéticos. Resultado esperado (Salida): La aplicación permite el ingreso del dato.
Caso 4.3: Datos de entrada: cadena de 6 caracteres, con caracteres no alfabéticos. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.
Caso 4.3: Datos de entrada: cadena de 10 caracteres, con caracteres no alfabéticos. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error. 

Ejemplo 5: Ingreso de datos en un campo numérico.


Descripción de la situación: Supongamos que tenemos una aplicación que posee una pantalla para el ingreso de un valor numérico, como por ejemplo un monto (en alguna moneda), cuyo valor debe estar entre 1 y 1.000. Por lo tanto, todo valor menor que 1 y mayor a 1.000 es invalido.

Técnica de pruebas de caja negra: Partición de equivalencias y análisis de valores borde.

Caso 5.1: Datos de entrada: 450. Resultado esperado (Salida): La aplicación permite el ingreso del dato.

Caso 5.2: Datos de entrada: 1 (Valor borde). Resultado esperado (Salida): La aplicación permite el ingreso del dato.

Caso 5.3: Datos de entrada: 1.000 (Valor borde). Resultado esperado (Salida): La aplicación permite el ingreso del dato.

Caso 5.4: Datos de entrada: 0. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.

Caso 5.5: Datos de entrada: 1.001. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.