Pruebas de Caja Blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran porciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.

Técnica de Camino básico

La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por Tom McCabe.

Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar esta medida como guía para la definición de un conjunto básico.

La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática. Los pasos que se siguen para aplicar esta técnica son:

1. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
2. Se calcula la complejidad ciclomática del grafo.
3. Se determina un conjunto básico de caminos independientes.
4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.

Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Técnica de Notación de Grafo de Flujo

Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la representación del flujo de control, el cual puede representarse por un Grafo de Flujo. Cada nodo del grafo corresponde a una o más sentencias de código fuente. Todo segmento de código de cualquier programa se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3 componentes fundamentales que ayudan a su elaboración, comprensión y nos brinda información para confirmar que el trabajo se está haciendo adecuadamente.

Los componentes son:

Nodo

Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no se asocien, se utilizan principalmente al inicio y final del grafo.

Aristas

Las flechas del grafo se denominan aristas y representan el flujo de control, son análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el nodo no represente ninguna sentencia procedimental.

Regiones

Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el área exterior del grafo, contando como una región más. Las regiones se enumeran. La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo. Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND, NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace un poco más complicada.

Técnica Complejidad Ciclomática

La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente.

Pruebas del Software

Las pruebas funcionales - (Functional Software Testing) y las pruebas unitarias (Unit Software Testing) deben ser consideradas como temas cien por ciento técnicos, en mi experiencia como analista de pruebas o también llamado tester, he llegado a probar una buena cantidad de sistemas en varias empresas, enfocadas principalmente al sector financiero.

Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar el plan de pruebas, el cronograma de pruebas y los casos de prueba.

Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado, cada error que yo pudiera encontrar significa un éxito para la calidad del sistema. Evidentemente el analista de pruebas o tester debe ser un profesional en Ing. De Sistemas o Ing. de Software, los conocimientos técnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos del negocio, en la actualidad los sistemas más importantes son realizados para dar solución a los problemas de negocios. 

El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que utilizará el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento  de diversos negocios y le resultará sencillo adaptarse a cualquier tipo de aplicación y a cualquier tipo de plataforma: Web, C/S o Host, siendo esta última a mí parecer la más complicada.

Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba.

En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores, los casos de prueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y el resultado esperado.

Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una primera barrida de pruebas y con esto también podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es importante tener buen criterio a la hora de desarrollarlos.  Las combinaciones de casos de prueba podrían ser prácticamente infinitas, propongo el siguiente ejemplo:

Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran combinación de variables:

Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos con las siguientes variables:

¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos
Esto nos daría al menos 3 variables o casos de prueba.

¿La cuanta tendrá saldo? Saldo = 0,  Saldo > 0, Saldo < 0
3 variables

¿Es una cuenta en Moneda Nacional MN o Moneda extranjera?
2 variables

¿Pertenece a una Persona natural PN o Persona Jurídica PJ?
2 variables

¿La cuenta es mancomunada? Si o No
2 variables

¿En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3 estados).
3 variables

¿La cuenta tendrá alguna facilidad crediticia? Es decir ¿Permite sobregiros?
Si o No
2 variables

¿De que tipo será el cargo a la cuenta?

1. Transferencia entre cuenta propia
2. Transferencia a un tercero
3. Transferencia interbancaria
4. Retiro en efectivo
5. Pago de un cheque

5 variables

¿En que canal de atención se realizará esta operación?

1. En ventanilla
2. Cajero Automático – ATM
3. POS – Pago de servicio o consumo
4. Home Bankin

4 variables

Para este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera estamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botones etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar diseñando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema.

Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más allá. Muchos de los errores que he podido encontrar no estaban escritos en mis casos de prueba. 

Si en mi caso defino hacer un cargo de 1000 dólares, luego de eso podría hacer una prueba con un cargo de 1000.01 y otro de 9999.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Es interesante notar que la gran mayoría de los errores se encuentran en los valores límite. Si una pantalla se define para que no soporte un número mayor de 99999999.99 pues entonces probemos con 100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado esta fuera del rango permitido o algo por el estilo. 

Es increíble como algunos programadores creen que no se deben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrario un buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a un sistema de alta calidad, se debe probar que el sistema haga lo que debe de hacer y por supuesto que no haga lo que no debe de hacer, la labor del analista de pruebas es totalmente destructiva para con el sistema, un analista tester jamás debería estar bajo las ordenes de un programador y tampoco es recomendable dejar que el programador pruebe sus propios programas, es gracioso cuando me pongo a pensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en la robustez de sus sistemas, simplemente en el fondo no quieren maltratarlos, los aman…

Otro nicho en el que se ocultan errores podrían ser los campos de ingreso de datos, aún no entiendo porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto, sobre todo en los campos de párrafos o multilíneas, disfruto de esas pruebas haciendo un solo Copy de un texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan los huesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez en un sistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar de ser una definición tan simple muchos la olvidan.

Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían calcular diversos campos calculados, cada uno de ellos mostrado en un campo o grilla, el caso debe especificar que valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que se presenten sean correctos, tanto en las pantallas como en los reportes, jamás he tenido la experiencia de encontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien la primera vez”. ¡Ese es mi lema!

Por último una muy buena recomendación de pruebas es el manejo del valor cero 0 muchas veces por la complejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otro valor y entonces: “Error Exception Faillure #afg99d7 - no valido” o algún otro mensaje horrible.

Pruebas Software

Las pruebas de software consisten en la dinámica de la verificación del comportamiento de un programa en un conjunto finito de casos de prueba, debidamente seleccionados de por lo general infinitas ejecuciones de dominio, contra la del comportamiento esperado. Son una serie de actividades que se realizan con el propósito de encontrar los posibles fallos de implementación, calidad o usabilidad de un programa u ordenador; probando el comportamiento del mismo.

La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están:

1. Detectar defectos en el software.
2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
5. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.

Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación se citan:

• La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia.
• La principal dificultad del proceso de prueba es decidir cuándo parar.
• Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.
• Una parte necesaria de un caso de prueba es la definición del resultado esperado.
• Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.
• El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a refinar el producto de software a través de las etapas involucradas.

1. Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.
2. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.
3. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo.
4. Determinar cuáles deberían ser los resultados esperados de los casos de prueba y crear el documento que los contenga.
5. Ejecutar los casos de prueba.