Características de las Pruebas

Las pruebas que se deben llevar a cabo a lo largo del desarrollo de un software, además de tener una clasificación en base a su función y un orden en el que deben llevarse a cabo, también poseen ciertas características generales que se aplican a todas, las cuales si se cumplen satisfactoriamente facilitan la aplicación de esas pruebas, e incrementan su efectividad.

Esas características son:

1. Ser fácil: Como su nombre lo dice, simplemente indica que la prueba debe de ser fácil de llevarse a cabo, o aplicarse.
2. Tener operatividad: Este aspecto quiere decir que mientras mejor hecha y más compleja sea la prueba en sí, va  a ser más fácil poder aplicarla para que encuentre los errores rápidamente.
3. Ser observable: Se refiere a que mientras se esté llevando a cabo una prueba, ésta va a tener entradas, salidas y uno o varios procesos, el ser observable quiere decir que todos estos elemento se saben y pueden analizarse.
4. Controlable: El que la prueba sea controlable indica que se tiene acceso y por lo tanto se pueden modificar las variables con las que ésta esté trabajando según vaya siendo necesario.
5. Capacidad de Descomposición: De la misma forma que un sistema está formado por módulos, la capacidad de descomposición de las pruebas quieren decir que sea capaz de probar módulos independientes de manera independiente, es decir que el resultado de la prueba de un módulo no afecte al de los demás.
6. Simple: Se refiere a que esté hecha de manera tal que hacer el set de pruebas y aplicarlo para ponerla en funcionamiento no sea complicado y se pueda llevar a cabo con rapidez.
7. Estable: Quiere decir que aunque se tengan que llevar a cabo ajustes o cambios ya sea en el sistema que se está probando o en la prueba en sí, ésta siga funcionando adecuadamente o que no sea necesario rehacerla completamente desde cero.
8. Facilidad de Comprensión: De manera sencilla, esta característica quiere decir que la prueba debe de ser fácil de entender en el sentido de entender qué es lo que está probando y de qué forma lo está haciendo.

Si una prueba cumple con todas estas características, será mucho más probable que su efectividad esté garantizada y cumpla correctamente con su función.

Ahora hablaremos un poco de dos pruebas en específico que están enfocadas a un aspecto que se menciona en la tercer característica, las entradas, salidas y procesos. Estas son las llamadas "Pruebas de Caja Blanca" y "Pruebas de Caja Negra":

Prueba de Caja Blanca.

La prueba de caja blanca se basa en el diseño y uso de casos de prueba que estén hechos en base al software o sistema a probar, es debido a esto que la prueba de caja blanca ofrece las siguientes características:

1. Garantizar que se ejecuten por lo menos una vez todos los caminos independientes de cada módulo.
2. Llevar a cabo todas las ramificaciones lógicas de verdadero o falso.
3. Ejecutar todos los bucles en sus límites operacionales.
4. Ejecutar estructuras internas de datos para garantizar su validez.

Estas características de la prueba de caja blanca nos dan a entender que al diseñar los casos de prueba en base al propio diseño de lo que se va a probar, se puedan recorrer todos los caminos que de los que disponga para asegurar que funcionen correctamente. Existe una técnica para llevar a cabo esta prueba, conocido como "Prueba del camino básico".

Prueba de camino básico.

Esta prueba en una técnica desarrollada por Tom McCabe para llevar a cabo pruebas de caja blanca, la idea del camino básico es primero comprender el diseño del sistema y representarlo a manera de grafo, para que ya con éste se puedan diseñar los casos de prueba que fuercen cada camino. Los pasos a seguir son los siguientes:

1. A partir del diseño o código fuente, hacer la representación gráfica del flujo en cuestión a manera de grafo.
2. Calcular la complejidad ciclomática del grafo.
3. Determinar conjunto básico de caminos independientes.
4. Preparar los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.

Ejecutando cada uno de los pasos, se logra hacer una prueba que ejecute cada camino que puede seguir el programa, es decir una prueba de caja blanca.

En el primer paso se necesita crear un grafo del flujo del programa utilizando su diseño o código fuente, este grafo tiene 3 elementos fundamentales para su construcción:

• Nodo: Básicamente representa una o más secuencias procedimentales, una sentencia de decisión o una secuencia de procesos.
• Aristas: Son las flechas que se utilizan para unir cada nodo y representan el flujo de control del programa.
• Regiones: Son las áreas delimitadas por las aristas y nodos, contando también el área del exterior del grafo, cada una de estas regiones se enumeran y el numero de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.

Otro aspecto que se debe conocer es la denominada "Complejidad Ciclomática", ésta es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa, en esencia el valor que nos dé indica el límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia por lo menos una vez.

Prueba de Caja Negra.

La prueba de caja negra permite obtener un conjunto de condiciones de entrada que lleven a cabo completamente todos los requisitos funcionales de un programa, en ellas se ignora la estructura de control, sino que se concentra en los requisitos funcionales del sistema y los ejecuta.

Se considera como un complemento a la prueba de caja blanca, y dentro de las características que ofrece se encuentra el permitir encontrar:

1. Funciones incorrectas o ausentes.
2. Errores de Interfaz.
3. Errores en estructuras de datos o en accesos a las bases de datos externas.
4. Errores de rendimiento.
5. Errores de inicialización y terminación.

Para preparar los casos de prueba necesarios, se necesitan un número de datos que ayuden a la ejecución de los casos y que le permitan al sistema correr en todas sus variantes, estos datos pueden ser válidos o inválidos dependiendo de si se quiere encontrar un error o probar una funcionalidad.

Para desarrollar una prueba de caja negra existen diversas técnicas, algunas de ellas son:

• Técnica de la Partición de Equivalencia: Divide el campo de entrada en clases de datos que ejecutan determinadas funciones del software.
• Técnica del Análisis de Valores Límite: Prueba la habilidad del programa de manejar datos que se encuentren dentro de los límites aceptables.
• Técnica de Grafos de Causa-Efecto: Permite validar complejos conjuntos de acciones y condiciones.

La técnica más utilizada en las prueba de caja negra es la de partición de equivalencia, dado que permite examinar los valores válidos e inválidos de las entradas existentes en el software y así descubrir más rápidamente errores que podrían tomar más tiempo de encontrar utilizando otro método.

Con esto se puede concluir que las pruebas de caja negra y blanca son complementarias entre si, mientras que la primera se enfoca en las entradas y las salidas, la segunda se enfoca en los caminos que sigue el programa en cada caso, así en conjunto son una prueba muy completa del diseño y funcionalidad de un programa.

http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node27.html

http://testingfuncional.wordpress.com/2011/03/12/%C2%BFtesting-funcional-o-pruebas-de-caja-negra/

http://www.ecured.cu/index.php/Pruebas_de_caja_blanca

PRESSMAN, ROGER S. Ingenieria de Software Un Enfoque Práctico

Prueba de resistencia a una bicicleta

Dentro de las pruebas que se llevan a cabo en un software, se encuentra una llamada "Prueba de Resistencia", esta prueba como su nombre dice, se refiere a probar la capacidad de resistencia del software, principalmente frente a la sobrecarga de información y solicitudes para poder lidiar con ello sin colapsar, sin embargo para ilustrar de manera más sencilla este tipo de prueba, se llevará a cabo con una bicicleta.

Una prueba de resistencia con una bicicleta se podría llevar a cabo de dos formas:

• Desde el punto de vista del fabricante.
• Desde el punto de vista del comprador.

Fabricante

La prueba de resistencia que llevaría a cabo el fabricante sería durante la construcción de la bicicleta, y lo que se llevaría a cabo sería someter a la bicicleta a distintas situaciones "extremas", esto se refiere a:

• Choques con distintos materiales.
• Resistencia de las cadenas.
• Aguante de las llantas.
• Aguante de frenos.
• etc.

En esencia lo que haría esta prueba sería someter a la bicicleta, o más específicamente a cada una de sus partes a una situación "extrema", en la cual esa parte en específico tiene que lograr cumplir con la función sin romperse, por ejemplo el esqueleto de la bicicleta debería de aguantar choques contra metal, paredes de distintos materiales, autos, etc, intentar frenar a velocidades muy altas, someter a las llantas a distintas superficies, etc. Toda aquella situación a la que se podría enfrentar una bicicleta una vez esté en las manos del comprador, todo esto con el objetivo de ver hasta dónde es capaz de aguantar cada una de sus partes, o la bicicleta entera antes de descomponerse.

Comprador

Del lado del comprador, la prueba de resistencia que éste podría aplicar sobre la bicicleta sería más que otra cosa, someter a la misma al uso más intenso que éste podría aplicarle, porque desde el punto de vista del comprador, la resistencia que va a requerir de la bicicleta es que soporte el uso que éste le va a dar, por lo que la forma en la que probaría la resistencia de la bicicleta sería simplemente utilizándola, tal ves con el agregado de darle el uso más intenso que podría presentarse en circunstancias especiales, pero más allá de eso, el comprador no puede realmente hacer mucho más en cuanto a pruebas de resistencia, más que otra cosa porque no lo necesita.