Qué es black box testing o pruebas de caja negra

Las pruebas de caja negra, también conocidas como pruebas funcionales, son un tipo de pruebas de software basadas en el grado de conocimiento de los procesos - en este caso nulo - que se dispone al momento de realizar un conjunto de pruebas.

Qué es black box

Para explicar el origen del término es útil realizar un Diagrama EPS (Entrada, Proceso y Salida) donde cada elemento corresponde a:

• Entrada: Datos que recibe un determinado proceso.
• Proceso: Operaciones que se realizan para dar solución a un problema.
• Salida: Solución al problema originalmente planteado.

Las operaciones que se realizan en el proceso, por ser de tipo caja negra no son visibles por el usuario, ya que desconoce su implementación. Sin embargo, a pesar de no conocer la forma en la que se le da solución al problema, conoce los datos de entrada y la salida que arroja el proceso.

Desconocimiento del proceso

El desconocimiento de un proceso no implica que el mismo no pueda ser probado. La técnica de caja negra permite ilustrar el siguiente ejemplo en el que es necesario obtener el menor de dos números:

• Entrada: Sean dos números enteros, n1 y n2, iguales a 5 y 9 respectivamente.
• Proceso: Se determina el menor número entre n1 y n2.
• Salida: El menor número es 5.

Por ser caja negra se desconoce la forma en la que se lleva a cabo el proceso, mientras que se conoce a 5 y 9 como los valores de los datos de entrada, y que el menor números de ambos es 5. ¿Por qué elegir este tipo de pruebas para ciertos procesos? ¿Cuándo es conveniente aplicar esta técnica?

Si bien el conocimiento del proceso descrito anteriormente puede resultar trivial, en la construcción de un elemento de software, existen múltiples factores que influyen en la toma de decisiones respecto a qué tipo de prueba es conveniente aplicar. Algunos ejemplos que justifican la elección de pruebas de caja negra pueden ser la experiencia de quien realiza las pruebas, el nivel de accesos y permisos para comprobar las operaciones que realiza internamente el proceso o incluso la etapa en la que se encuentre el desarrollo del producto de software.

Qué son las pruebas de caja negra

La generación de un caso de prueba puede realizarse a partir de la estructura de un Documento ERS (Especificaciones de Requisitos de Software) para cada una de las funcionalidades que un software deberá cumplir. Puesto que cada caso de prueba de caja negra estará relacionado con cada funcionalidad del software, también son conocidas como pruebas funcionales.

Esta tarea de creación de casos de prueba es parte de las actividades que realiza un tester o analista de calidad, para lo cual, deberá trabajar de forma coordinada junto al analista funcional que relevó cierta funcionalidad de forma tal que pueda lograrse un entendimiento mutuo en el funcionamiento esperado, así como la trazabilidad necesaria entre requerimiento funcional y caso de prueba.

Para el desarrollo de un requerimiento y su posterior caso de prueba estaremos abordando las implicancias del registro de cierto usuario en una aplicación web.

Registro de usuario

A partir del requerimiento funcional “El sistema deberá permitir el registro de un usuario” y analizando los datos de entrada, proceso y salida es que podremos elaborar y comprender el alcance de su prueba de caja negra.

El detalle del requerimiento funcional junto a la técnica de caja negra nos permite elaborar el siguiente caso de prueba para el registro de un usuario:

• Entrada: Nombre, apellidos, correo electrónico y contraseña.
• Proceso: Se desconoce el proceso por ser una prueba de caja negra.
• Salida: El usuario ha sido registrado.

Una vez elaborado el análisis previo, sólo resta definir cuáles serán los datos de entrada y realizar la prueba funcional en la aplicación web. Considerando que los datos de entrada a utilizar no se encuentran ya registrados, y con un mensaje de confirmación de registro una vez ingresados los datos, es posible concluir que la prueba de caja negra se ha realizado correctamente sin tener conocimiento de cuáles son las implicancias del proceso de registro del usuario y cómo se efectúa dicho proceso.

Esto no quiere decir que las pruebas de caja negra sean incompletas o no tengan la profundidad necesaria para considerarlas como pruebas sino que están asociadas al comportamiento de lo qué debe suceder y no del cómo. Las pruebas de caja negra se abstraen de los detalles del proceso y su foco está puesto en definir correctamente cuáles son los datos de entrada y qué salida debe obtenerse para el registro del usuario.

Los detalles de la implementación del proceso de registro de usuario podrán definirse en otro tipo de prueba conocida como caja blanca.

Cuándo aplicar las pruebas de caja negra

Las pruebas de caja negra suelen estar asociadas a los siguientes factores:

• Perfiles junior: Quién esté realizando sus primeras pruebas, a fin de comenzar desde lo general a lo particular, empezará con pruebas de caja negra para comprender el funcionamiento general de un determinado software. Posteriormente, una vez adquirido el conocimiento previo, podrá realizar pruebas de caja blanca donde deberá conocer sobre el comportamiento interno de cada uno de los procesos vinculados al software.
• Pruebas exploratorias: Un perfil experimentado puede ser requerido para la realización de pruebas exploratorias de un software a fin de realizar un informe de alto nivel o auditoria de la calidad del mismo.
• Falta de recursos técnicos: Los detalles de la implementación de cierto proceso que impacte en una base de datos en la que se almacene información, o bien, una API a partir de la cual se obtenga información pueden ser herramientas que no estén disponibles para el equipo de testing.
• Pruebas de regresión: Las funcionalidades de un software que no sufren alteraciones entre cada lanzamiento de una nueva versión son parte de las pruebas de regresión. En este caso, dado que su comportamiento no ha variado, una prueba funcional de alto nivel puede ser una estrategia válida mientras que las pruebas de caja blanca sean destinadas al estudio minucioso de los procesos vinculados a las nuevas funcionalidades del software.
• Confidencialidad: El acceso a la información puede no estar disponible por restricciones de la empresa o acuerdos de confidencialidad con un cliente. En estas situaciones en las que no se cuenta con la posibilidad de visualizar, modificar o eliminar datos las pruebas de caja negra son una técnica de prueba útil a implementar.
• Beta testers: Las versiones de un software previas a un lanzamiento oficial se caracterizan por analizar aspectos superficiales, de usabilidad en general o rendimiento que encuadran con la detección de errores para este tipo de pruebas.

Técnicas de pruebas de caja negra

Las pruebas de caja negra tienen por objetivo poder reproducir, verificar y asegurar el correcto funcionamiento de las acciones que realiza un usuario promedio de un software. En el caso de una aplicación web, es posible distinguir aquellas funcionalidades que son inherentes a cada lanzamiento de una nueva versión, así como las que han sido incluidas por primera vez.

Existen diferentes estrategias para definir un plan de pruebas junto a sus casos y tipos de prueba asociados. Una estrategia a considerar puede ser la de analizar cuáles son las funcionalidades que no sufrirán modificaciones entre cada lanzamiento, siendo éstas candidatas a ser automatizadas, simulando el comportamiento del usuario por un software que genere el código que reproduzca los pasos para completar cada una de sus acciones.

El desarrollo de esta tarea no pretende ser resuelta por una sola persona en un sólo lanzamiento, sino que a lo largo del surgimiento de una nueva versión, se irá completando el grado de avance hasta llegar - en el mejor de los casos - al 100% de automatización de las pruebas de caja negra. Puede realizarse con el conjunto de pruebas de caja negra automatizadas, una primera ejecución de pruebas de regresión, que reducirá los esfuerzos destinados a pruebas manuales posteriores del equipo de testing.

Estrategia para automatizar pruebas de caja negra

Los siguientes pasos tienen como objetivo ilustrar una serie de recomendaciones para identificar oportunidades en la automatización pruebas funcionales:

• Preparar un set de datos para las pruebas: Como las pruebas de caja negra serán ejecutadas en cada lanzamiento de una nueva versión de software, es conveniente definir un set de datos referidos al usuario que respete cierta nomenclatura y combinación de atributos en su definición para mantener la integridad y limpieza de las bases de datos utilizadas en los ambientes de prueba, así como los productivos.
• Identificar las funcionalidades de regresión: Estas funcionalidades serán las candidatas a ser automatizadas con las pruebas de caja negra. En el caso de una aplicación web, pueden ser consideradas las referidas al acceso, registro, visualización del perfil de usuario y navegación general de la aplicación web como candidatas a ser automatizadas por un software de automatización de pruebas.
• Definir la periodicidad de la ejecución automatizada: La utilización de un ambiente de pruebas puede no ser exclusividad del equipo de testing, y debido a que otros equipos pueden estar haciendo uso del mismo, es recomendable definir y comunicar cuándo y por cuánto tiempo estarán siendo ejecutadas estas pruebas a fin de reservar un espacio de tiempo en el que el ambiente de pruebas se encuentre liberado y pueda utilizarse para ejecutar las pruebas automatizadas y verificar sus resultados.
• Aumentar los casos de prueba automatizados: La programación de una mayor cantidad de casos de prueba de caja negra automatizados generarán una mayor combinación de acciones que reproducirán comportamientos del usuario, y por ende, aumentará la posibilidad de encontrar fallos en ambientes de pruebas de forma previa a que sucedan en ambientes productivos.
• Procurar la limpieza del ambiente de pruebas: La ejecución de casos de prueba automatizados podrá grabar registros en una base de datos que serán necesarios eliminar entre la ejecución de cada prueba de regresión a fin de no generar conflicto o duplicidad entre cada lote de pruebas ejecutado. En caso de que el equipo de testing no tenga la autonomía suficiente para realizar esta tarea deberá solicitar asistencia a otros equipos.

Conclusiones

Las técnicas de pruebas de caja negra son parte de una estrategia de pruebas que depende de múltiples factores como se han analizado anteriormente. El desconocimiento del proceso, ya sea por limitaciones propias o parte del contexto en el que se ejecutan las pruebas, es el factor principal que determinará la utilización de esta técnica.

El grado de conocimiento de un proceso determina la utilización de:

• Pruebas de caja negra: Cuando el conocimiento de un proceso es nulo.
• Pruebas de caja blanca: Cuando el conocimiento de un proceso es total.
• Pruebas de caja gris: Cuando el conocimiento de un proceso es parcial.

De forma complementaria, será necesario evaluar, si se cuenta en el proyecto con el acceso a los recursos involucrados en dicho proceso para poder formular las pruebas que correspondan en cada caso. Esta combinación de conocimiento y acceso determinará qué tipos de prueba utilizar, siendo la correcta elección según sea el caso, la estrategia de pruebas adecuada.

Si este artículo te resultó interesante, no te pierdas la oportunidad de conocer los siguientes cursos:

• Curso de introducción al testing
• Curso de testing con BDD
• Cursos de Testing en OpenWebinars