Las Pruebas de Caja Negra, es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.
En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos en tener conocimiento de la estructura interna del programa de software. Para obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos en los requerimientos de software y especificaciones funcionales.
¿Estamos hablando de Pruebas Funcionales entonces? en principio digamos que sí.
A ver, pongámoslo de esta manera, las actividades que conlleva (nota de color: ¿no te vino a la mente cuando leiste ésta palabra la frase que dijo el tío Ben: Un gran poder conlleva una gran responsabilidad? ;)) esta técnica de prueba se podría decir que es la primera que se espera que tenga un Probador de Software (Software Tester), ya que comprueba la funcionalidad del sistema de software (u otro componente) y no requiere demasiado conocimiento técnico. Entendamos por «conocimiento técnico» a conocer acerca de lenguajes de programación, herramientas para gestionar los mismos, entendimiento del código y sus implicancias, manejo de consultas a base de datos y herramientas para gestionar las mismas, conocimiento técnico vinculado con servicios y/o tareas programadas, y manejo de otras herramientas para la gestión de todo componente técnico asociado con este tipo de pruebas.
Entonces, ¿un desarrollador no realiza pruebas funcionales sobre el código que está o ha desarrollado? dejemos este tema para otro artículo.
OK, te ayudo a que recuerdes (ó te enteres) que en el ISTQB puedes encontrar contenido al respecto.
La distinción entre técnicas de pruebas de caja negra y pruebas de caja blanca es la clasificación clásica de las pruebas de software.
Las pruebas de caja negra, también denominadas por el ISTQB como técnicas basadas en especificación, son una forma de derivar y seleccionar condiciones, datos y casos de prueba a partir de la documentación de requerimientos del sistema.
Las pruebas de caja negra no utilizan ninguna información interna de los componentes de software o sistemas que se van a probar, sino que consideran el comportamiento del software desde el punto de vista de un observador externo, es decir, tal y como lo «viven» los usuarios del sistema.
Puedes encontrar todo el detalle que se requiere para entender este tema en el Syllabus Foundation Level:
4.Test Design Techniques (K4)
4.3. Specification-based or Black-box Techniques (K3)
Equivalence Partitioning (K3)
Boundary Value Analysis (K3)
Decision Table Testing (K3)
State Transition Testing (K3)
Use Case Testing (K2)
En caso que quieras profundizar sobre estos puntos, te recomiendo que vayas al HASTQB [ enlace ], sitio oficial para la comunidad hispana.
Pruebas de caja negra y pruebas funcionales
En los estándares para Software Testing definidos por ISTQB, las técnicas de pruebas de caja negra son utilizadas para realizar pruebas funcionales, basadas en las funciones o características del sistema y su interacción con otros sistemas o componentes.
Se pueden utilizar técnicas basadas en especificación para identificar las condiciones y casos de prueba a partir de la funcionalidad del software, como es el caso de la Derivación o Extracción de Casos de Prueba a partir del Caso de Uso (ó Historia de Usuario).
Las técnicas de caja negra también pueden ser utilizadas para diseñar pruebas de software no funcionales, [ leer más ].
Técnicas de Pruebas de Caja Negra
- Partición de equivalencias
- Análisis de valores borde
- Tablas de decisión
- Transición entre estados
- Pruebas de casos de uso
Técnicas combinatorias
Pruebas de historias de usuario
Las pruebas de caja negra en el Agile Testing
CURSO ONLINE
INTENSIVO MANUAL TESTING
¿Quieres conocer su alcance y contenido, y para que puede servirte?
clic AQUI
Me pareció muy interesante la siguiente imagen que corresponde a un mapa mental
Partición de equivalencias
- Consiste en clasificar las entradas de datos del sistema en grupos que presentan un comportamiento similar, por lo cual serán procesados de la misma forma.
- Se pueden definir particiones tanto para datos válidos como no válidos (datos que deben ser rechazados por el sistema).
- Las particiones también pueden definirse en función de las salidas de datos, valores internos, valores relacionados antes o después de ciertos eventos, y también para los valores que reciben las interfaces.
- A partir de allí se definen pruebas para cubrir todos o parte de las particiones de datos válidos y datos inválidos.
- Es aplicable a entradas de datos realizadas por personas o vía interfaces con otros sistemas.
Análisis de valores borde
- Parte del principio que el comportamiento al borde de una partición de datos tiene mayores probabilidades de presentar errores (bugs).
- Los valores máximos y mínimos de una partición son sus valores borde.
- Aplican tanto para datos inválidos como inválidos.
- Al incluirlas en el diseño de casos de prueba, se define una prueba por cada valor borde.
- La capacidad de identificar defectos de esta técnica es alta, ser pueden revisar las especificaciones funcionales para identificar datos interesantes.
Tablas de decisión
- Las tablas de decisión son una herramienta útil para documentar reglas de negocio de alta complejidad que el sistema debe cumplir.
- Las tablas de decisión se crean a partir del análisis de la especificación funcional y la identificación de estas reglas de negocio.
- Las condiciones de entrada y acciones se expresan a menudo en términos de verdadero o falso.
- La tabla de decisión contienen las condiciones desencadenantes, que son la combinación de valores de verdadero o falso para cada entrada de datos, así como la acción que resulta de cada combinación.
- Cada columna de la tabla corresponde con una regla de negocio que representan la combinación de condiciones, y las acciones que resultan.
Transición entre estados
- Un sistema puede presentar diferentes comportamientos según su estado actual o eventos previos.
- Este aspecto del sistema se puede representar en un diagrama de transición entre estados.
- El diagrama de estados, permite al Tester visualizar los estados, transiciones, entradas de datos o eventos que las desencadenan y las acciones que pueden resultar.
- Una tabla de estados, muestra las relaciones entre los estados y las entradas de datos. Puede ayudar a identificar posibles transacciones inválidas.
Pruebas de casos de uso
- Los casos de uso describen las interacciones entre actores (que pueden ser usuarios o sistemas) que producen un resultado que agrega algún valor. A partir de estos se pueden derivar casos de prueba.
- Tienen precondiciones que deben cumplirse para que estos funcionen de forma exitosa.
- Los casos de uso terminan con post-condiciones, que son resultados observables y estado del sistema después de la ejecución.
- Son útiles para definir las pruebas de aceptación, en las que participa el usuario o cliente.
Técnicas combinatorias
- El testing combinatorio es muy útil cuando las combinaciones de datos de entrada y parámetros a partir de los cuales puede ejecutarse un sistema, son demasiados para poder abarcarlos todos en el tiempo disponible.
- Se pueden usar herramientas como los arboles de clasificación para identificar combinaciones incompatibles entre sí que pueden excluirse.
- Proporciona los medios para identificar un subconjunto de estas combinaciones que pueda ayudar a alcanzar un nivel determinado de cobertura.
Pruebas de historias de usuario
- En metodologías ágiles como por ejemplo Scrum, los requerimientos de usuario son preparados en la forma de historias de usuario.
- La historia de usuario describe una funcionalidad (o parte de ella) que puede ser desarrollara y probada en una sola iteración.
- La historia de usuario describe la funcionalidad a implementar, requerimientos no funcionales y los criterios de aceptación.
- La cobertura mínima de pruebas para una historia de usuario está compuesta por los criterios de aceptación.
- Por ende los casos de prueba se derivan de estos criterios de aceptación.
Fuente de Inspiración: PMOInformatica
