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 (.Como los usuarios del sistema).
En este articulo, te presentamos información sobre que son las pruebas de caja negra, las pruebas funcionales y sus principales técnicas, como son las particiones de equivalencias, análisis de valores borde, tablas de decisión, transición entre estados, pruebas de casos de uso e historias de usuario.
También comentamos sobre las pruebas de caja negra en Agile Testing y los conocimientos que se necesitan para poderlas ejecutar.
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.
Las funciones del software son descritas en los documentos de especificación funcional. Se pueden utilizar técnicas basadas en especificación para identificar las condiciones y casos de prueba a partir de la funcionalidad del software.
Pruebas no funcionales
Las técnicas de caja negra también pueden ser utilizadas para diseñar pruebas de software no funcionales. Aquí te compartimos un artículo sobre el tema:
> 10 tipos de pruebas no funcionales de software
Técnicas de pruebas de caja negra
A continuación describimos las principales técnicas (o métodos) de pruebas de caja negra, tomando las definiciones del Syllabus del ISTQB:
Partición de equivalencias
 |
| Imagen de: LeaseWeb labs |
- 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.
Curso de Software Testing
¿Estás trabajando actualmente en Testing de Software pero sientes que te falta marco teórico?
¿Nunca has trabajado en Testing de Software pero te gustaría incursionar en este ámbito?
Este curso es para tí:
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.
En este enlace te presentamos algunos ejemplos de pruebas de caja negra:
> Pruebas de caja negra: Ejemplos
Tablas de decisión
 |
| Imagen de: LeaseWeb labs |
- 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
 |
| Imagen de: Microsoft Developer Network (MSDN) |
- 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
 |
| Imagen de: Presentación de Wakaleo Consulting en SlideShare |
- 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.
Las pruebas de caja negra en el Agile Testing
En Agile Testing, la mayoría de las pruebas son realizadas de forma concurrente con el desarrollo, donde ambos grupos trabajan simultáneamente a partir de las historias de usuario y criterios de aceptación. Sin embargo, algunas pruebas, como por ejemplo las pruebas exploratorias y las pruebas basadas en experiencia son creadas y ejecutadas después del desarrollo.
Pueden utilizarse las mismas técnicas de pruebas de caja negra, como por ejemplo partición de equivalencias, análisis de valores borde, tablas de decisión y transición entre estados.
Las técnicas de pruebas de caja negra también pueden usarse para evaluar los requerimientos no funcionales de sistemas (los cuales a su vez pueden describirse como historias de usuario).
En el siguiente artículo, te contamos más sobre en que se diferencia el Agile Testing:
8 diferencias de las pruebas ágiles de software
Conocimientos y habilidades necesarios para hacer pruebas de caja negra
Viendo la ejecución de pruebas de software desde un punto de vista de gerencia y construcción del equipo, un equipo de trabajo ideal tendrá una mezcla de habilidades y niveles de experiencia.
En distintos ambientes de trabajo, algunas de estas habilidades serán más importantes que otras. Por ejemplo, en donde se ejecutan mayormente pruebas de caja negra, los conocimientos más importantes que deben poseer los integrantes del equipo son los denominados “de dominio”, esto es, conocimiento de los procesos y reglas de negocio asociados al sistema que están evaluando. El entorno para hacer Testing y los proyectos pueden cambiar, pero las reglas de negocio cambian en menor grado.
Por otra parte, si el ambiente de trabajo es de pruebas de software técnicas, donde se requieren conocimientos en Testing de interfaces (API Testing), Testing de Webservices y de programación, las habilidades técnicas tienen mayor preponderancia que el conocimiento de dominio.
¿Estás interesado en recibir formación en Pruebas de caja negra? Envíanostus datos.
¿Y qué opinas tú?
¿Has implementado pruebas de caja negra en tu organización?, ¿Cuáles técnicas de pruebas de caja negra has aplicado y como te han resultado?
¿Buscas más información de desarrollo y pruebas de software?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías de desarrollo y pruebas de software?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencias del ISQTB consultadas para elaborar este artículo
Para ampliar la información de lo expuesto en este post, puedes consultar en detalle las siguientes referencias del ISTQB:
Estos documentos puedes descargarlos en la pagina de Syllabus del ISTQB.
ISTQB. Foundation Syllabus
- Tipos de pruebas. Pruebas funcionales (Página 28).
- Técnicas de diseño de pruebas (Página 39).
- Diseño de pruebas basado en especificaciones (Página 40).
ISTQB. Advanced Syllabus Test Analys
- Diseño de pruebas basado en especificaciones. (Páginas 27 a 35).
ISTQB. Advanced Syllabys Test Manager
- Habilidades individuales requeridas por el equipo (Página 72).
ISTQB. Agile Testing Syllabus
- Diseño de pruebas funcionales, no funcionales y exploratorias (Páginas 36 y 37).
Otros artículos sobre software testing
> Pruebas de aceptación de software según el ISTQB
> 10 tipos de pruebas no funcionales de software
> Tutorial de SoapUI en Español
> Desarrollo y pruebas con Cucumber - Un ejemplo
> La falla más frecuente en los sistemas de seguimiento de incidentes de software
No hay comentarios :
Publicar un comentario