Pruebas de Caja Negra: Fase de Pruebas Software

La técnica de pruebas de caja negra no presupone conocimiento de cómo está elaborado internamente el producto, sino que simplemente busca errores interactuando con la interfaz del elemento software probado, teniendo solo en cuenta sus entradas y salidas.

Pruebas de Caja Negra (Krauss, CC BY-SA 4.0, via Wikimedia Commons)

Para preparar bien cuáles deben ser las entradas y las consecuentes salidas debemos basarnos en los requerimientos software, sobre todo en las especificaciones funcionales. Es por esto que a este tipo de pruebas se las llama también pruebas funcionales.

Existen diversas técnicas para realizar pruebas de Caja Negra.

Particiones de equivalencia

En éstas clasificamos las entradas en grupos que pueden presentar un comportamiento similar y por tanto procesaremos del mismo modo. Habrá clases tanto para datos de entrada válidos como no válidos (que deben ser rechazados por el sistema).

Análisis de los valores límite

Dado que las probabilidades de encontrar bugs (errores) son mayores en los límites posibles para las entradas de datos, como los valores máximo y mínimos admitidos, suelen crearse casos de prueba específico para ellos. También se utilizan tanto datos válidos como no válidos.

Los valores límite mantienen relación con las clases de equivalencia, puesto que los límites de estas suelen ser buenos casos de prueba dentro del análisis de valores límite.

En la siguiente figura puedes comprobar las distintas clases de equivalencia marcadas como válidas e inválidas, y además los valores límite definidos en color verde, a los que habría que añadir el 0 tanto para x como para y, ya que buscamos tanto los máximos como los mínimos.

Clases de Equivalencia y Valores Límite
Clases de Equivalencia y Valores Límite
(Nmondal, CC BY-SA 3.0, via Wikimedia Commons)

Tablas de decisión

Se diseñan en base a entradas que contienen condiciones lógicas con sus posibles valores Verdadero/Falso y las acciones relacionadas en función de si se activan o no.

Tablas de Decisión
Tabla de decisiones: LeaseWeb labs

Transición entre estados

Esta técnica de pruebas de caja negra está indicadas cuando el sistema puede presentar diferentes comportamientos según su estado actual o eventos previos. En este caso se requerirá un diagrama de transición entre estados para poder analizar bien el desarrollo de las pruebas.

Transición entre estados
Ejemplo de tabla de Transición entre Estados (tutorialspoint.com)

Técnicas combinatorias

Útiles cuando las combinaciones de datos de entrada son demasiadas para poder abarcarlas todas en el tiempo disponible. Pueden utilizarse herramientas específicas como árboles de clasificación para poder capturar combinaciones que son incompatibles entre sí, de modo que podríamos no contemplarlas dentro de nuestras pruebas.

Árbol de clasificación
Árbol de clasificación (solver.com)

Pruebas de historias de usuario

Usadas sobre todo en metodologías ágiles (consulta qué son en WikiPedia o en OpenWebinars), como por ejemplo Scrum, en las que los requerimientos de usuario son preparados en forma de ‘historias de usuario’, describiendo una funcionalidad que puede ser desarrollada y probada en una única iteración.

La historia de usuario describe la funcionalidad a implementar, los requerimientos no funcionales y los criterios de aceptación. Dado que la cobertura mínima de pruebas para una historia de usuario está formada por estos criterios de aceptación, los casos de prueba se derivarán de ellos.

Historia de Usuario
Historia de Usuario