5 Tipos de Técnicas de Pruebas de Caja Negra + Ejemplos
Uno de mis dichos favoritos es: “trabaja de forma más inteligente, no más duro.” Esto, por supuesto, también se aplica a las pruebas de software. Esto significa que quiero una forma de hacer la menor cantidad de trabajo y aportar el mayor valor posible.
Así que hablemos de las técnicas de pruebas de caja negra y cómo se pueden aplicar para crear casos de prueba y encontrar los errores más importantes en la aplicación bajo prueba.
¿Qué es la prueba de caja negra?
Comencemos por entender qué es la prueba de caja negra—en contraste con la prueba de caja blanca. Es un tipo de prueba de software en el que el evaluador no tiene acceso a la estructura interna de la aplicación que está probando. En su lugar, solo puede acceder a las entradas y salidas del sistema y puede comprobar la funcionalidad del software basado en las especificaciones de los requisitos.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ten en cuenta que la prueba de caja negra solo cubre la funcionalidad externa del software y no verifica el funcionamiento interno del código fuente. Por eso a veces se le llama “prueba de comportamiento.” Por tanto, debe utilizarse junto con la prueba de caja blanca, que se centra en comprobar el código interno. De esta manera, puedes sentirte más seguro de que el software está completamente probado y lo más libre de defectos posible.
5 tipos de técnicas de prueba de caja negra
Utilizamos estas técnicas de prueba de caja negra para aumentar la cobertura de las pruebas mientras, al mismo tiempo, reducimos la cantidad de casos de prueba. Identificando los datos de prueba correctos, podemos crear el menor número de pruebas posibles con la mayor cobertura.
Las técnicas de las que hablaré pueden aplicarse a todos los niveles de pruebas—incluyendo pruebas unitarias, pruebas de integración y pruebas de sistema, así como a pruebas funcionales y no funcionales.
1. Particionamiento por equivalencias
El particionamiento por clases de equivalencia es una técnica utilizada en pruebas de software para dividir las entradas posibles en un conjunto de clases de equivalencia, o particiones, con el objetivo de buscar y probar un conjunto representativo de entradas de cada clase. Se espera que todos los elementos que pertenecen a una clase de equivalencia den el mismo resultado, por lo que probar un solo valor del conjunto debería ser suficiente.
Esto ayuda a reducir el número de casos de prueba que se deben crear y ejecutar, manteniendo una buena cobertura. Las clases se definen tomando en cuenta los requisitos funcionales o no funcionales y pueden considerar factores como tipos de datos, rangos y relaciones entre los valores de entrada.
Al definir las clases de equivalencia, siempre debes asegurarte de incluir también las clases no válidas, para cubrir los escenarios de prueba negativos. Por experiencia, he comprobado que la mayoría de los defectos se encuentran cuando se emplean entradas no válidas en lugar de positivas.
Veamos un ejemplo:
Tienes un campo opcional que solo permite valores enteros entre 1 y 10. Tendrías las siguientes clases de equivalencia:
- sin valor (partición válida)
- valores entre 1 y 10 (partición válida)
- valores menores que 1 (partición no válida)
- valores mayores que 10 (partición no válida)
Así que solo necesitarías 4 casos de prueba: uno por cada partición. No aporta beneficio volver a probar la misma partición con múltiples valores—si probaste el valor 5, obtendrás el mismo resultado para los valores 4, 8, etc.
2. Análisis de valores límite
El análisis de límites es una técnica utilizada en pruebas de software para identificar y probar los valores de entrada en o cerca de los extremos o “límites” del dominio de entrada del programa. La idea es que estos valores son más propensos a causar errores o comportamientos inesperados porque a menudo implican casos especiales o extremos que, posiblemente, el programa no haya sido diseñado para manejar correctamente.
Por ejemplo, al probar un programa que acepta un rango de enteros entre 1 y 100, los valores límite serían 1, 100 y todos los valores justo fuera del rango, como 0 y 101.
Los dos tipos de pruebas de límites son:
- Prueba de límite interna: se centra en los valores de entrada que están justo dentro del borde del dominio de entrada, como los valores mínimos y máximos permitidos.
- Prueba de límite externa: se centra en los valores de entrada que están justo fuera del borde del dominio de entrada, como los valores que están ligeramente por encima o por debajo de los valores mínimo y máximo permitidos.
El análisis de límites es una técnica importante para encontrar errores y garantizar que un programa se comporte correctamente para todas las entradas, no solo para aquellas que se encuentran en el medio del dominio de entrada. Esto puede ayudar a identificar y corregir errores que de otro modo podrían pasar desapercibidos.
3. Pruebas de Tabla de Decisión
En las pruebas de tabla de decisión, probamos la lógica y el comportamiento del software cuando hay múltiples condiciones disponibles. Es una forma de representar las relaciones entre las entradas y las salidas en un formato tabular. La tabla normalmente tiene columnas para las condiciones y filas para las diferentes combinaciones. Para cada fila, se debe crear un caso de prueba específico. El resultado esperado para el caso de prueba también debe incluirse en la tabla.
Imaginemos un ejemplo de requerimiento de software donde se puede aplicar esta técnica: una aplicación que calcula el costo de una compra en función del artículo, la cantidad y el método de envío:
En este ejemplo, el Artículo, la Cantidad y el Método de Envío son las entradas, y el Costo es la salida. La tabla muestra todas las combinaciones posibles de entradas y la salida correspondiente en cada caso. Al usar esta tabla, se pueden identificar rápidamente los casos de prueba y sus resultados esperados, lo que facilita probar y verificar las combinaciones disponibles.
La prueba de tabla de decisión es útil cuando un programa tiene múltiples entradas y condiciones que interactúan entre sí de manera compleja. Al desglosar las entradas y condiciones en una tabla, se vuelve más fácil identificar y probar todas las combinaciones y variaciones posibles.
4. Pruebas de Transición de Estados
La prueba de transición de estados es una técnica de caja negra en la que se prueba el comportamiento de un programa a medida que transita entre diferentes estados o modos. Un estado es una condición o conjunto de condiciones en las que puede existir el programa, y una transición es un cambio de un estado a otro. La idea detrás de las pruebas de transición de estados es identificar todos los estados y transiciones posibles que puede experimentar un programa, y luego crear casos de prueba para verificar que el programa se comporta correctamente en cada estado y realiza transiciones válidas entre ellos.
Un ejemplo de prueba de transición de estados podría ser para un sitio web de comercio electrónico en el que los clientes pueden añadir artículos al carrito, proceder al pago, introducir su información de pago y detalles de envío, y finalmente realizar un pedido. Los estados en este ejemplo serían:
- Navegando productos
- Añadiendo artículos al carrito
- Realizando el pago
- Introduciendo información de pago y envío
- Confirmación del pedido
Las transiciones entre estos estados serían:
- Navegando productos -> Añadiendo artículos al carrito
- Añadiendo artículos al carrito -> Realizando el pago
- Realizando el pago -> Introduciendo información de pago y envío
- Introduciendo información de pago y envío -> Confirmación del pedido
Esta técnica ayuda a identificar y probar todos los caminos posibles que un usuario puede tomar a través del sistema, y puede ayudar a encontrar y corregir errores relacionados con flujos específicos. Las pruebas de transición de estados son particularmente útiles para probar sistemas con interacciones complejas, como sistemas financieros, sistemas de comercio electrónico o sistemas que controlan dispositivos físicos.
5. Pruebas por Pares
Las pruebas por pares son una técnica de caja negra utilizada para crear casos de prueba que cubran todos los posibles pares de combinaciones de valores de entrada para un conjunto dado de parámetros. Se utiliza cuando el número de entradas disponible es alto, lo que haría extremadamente difícil probar todas las combinaciones posibles entre ellas.
Supongamos que tenemos una aplicación con 3 campos: A, B y C. Cada campo puede aceptar 3 valores posibles: 1, 2 o 3.
Con métodos tradicionales de prueba, tendríamos que probar 27 (3^3) combinaciones posibles de entradas individualmente para validar todas las combinaciones posibles. Esto sería extremadamente laborioso e ineficiente.
Con las pruebas por pares, puedes identificar casos de uso que cubran todas las combinaciones únicas posibles de entradas. Esto se vería así:
Como puedes ver, la cantidad de pruebas se ha reducido drásticamente, de 27 a 9. La cobertura de las pruebas no ha cambiado, seguimos asegurando que todas las combinaciones posibles de valores se tienen en cuenta.
Existen varias herramientas de pruebas por pares disponibles para utilizar. A continuación, te listo algunos ejemplos:
- AllPairs: Una herramienta para crear casos de prueba por pares basada en listas de parámetros y restricciones especificadas por el usuario. Está disponible tanto en versión de código abierto como comercial.
- PICT (Pruebas Combinatorias Independientes por Pares): Una herramienta que utiliza un algoritmo genético para generar casos de prueba por pares. Está disponible como herramienta de código abierto.
- SmartBear TestComplete: Una herramienta comercial de automatización de pruebas que incluye soporte integrado para pruebas por pares.
- Generador de Casos de Prueba por Pares: Una herramienta de código abierto disponible en GitHub que se puede utilizar para generar casos de prueba por pares.
- Las pruebas por pares también pueden generarse utilizando Excel u OpenOffice Calc mediante macros o complementos para generar tus casos de prueba.
Estos son solo algunos ejemplos, y puede que haya otras herramientas disponibles también. Te recomiendo investigar y evaluar las diferentes opciones disponibles para ver cuál funciona mejor según tus necesidades y requisitos específicos.
Reflexiones finales
Utilizar estas técnicas es una excelente manera de lograr una buena cobertura en cualquier etapa del ciclo de vida del desarrollo de software. Puede ser aún mejor si agregas otros tipos en tu proceso de pruebas, como pruebas exploratorias o de adivinanza de errores, pruebas de compatibilidad, pruebas de usabilidad, entre otras.
Además, si los casos de prueba resultantes terminan en la suite de pruebas de regresión, deberías considerar automatizarlos—para pruebas de interfaz de usuario puedes usar herramientas como Selenium, Cypress y Appium; para pruebas de API puedes tener pruebas de integración escritas por el equipo de desarrollo, o puedes usar herramientas como Postman.
Si encontraste útil este artículo, te sugiero que te suscribas al boletín de QA Lead, donde podrás enterarte de todo el contenido y tutoriales nuevos sobre aseguramiento de la calidad y pruebas.
