Un plan de pruebas para una aplicación gráfica.

Saludos a todos.

Recientemente me he visto involucrado en un interesante proyecto para desarrollar una aplicación de escritorio con una interfaz gráfica en Java. Esta aplicación permitirá diseñar formularios de una manera gráfica. Estos formularios se almacenan archivos XML, son específicos de una empresa y utilizan un juego de controles predeterminados y bien documentados.

La aplicación no es vital. De hecho, sus futuros usuarios llevan ya tiempo creando y trabajando con estos formularios. Sin embargo, ahora estos formularios se construyen a mano con editores de texto. Esto presenta varios problemas: no se puede ver el resultado o los cambios a medida que se hacen y hay que conocer un número muy alto de etiquetas y atributos.

A continuación expongo un resumen preliminar de cómo creo que debe ser un plan de pruebas y, en concreto, la parte que aborda las pruebas del sistema.


Pruebas del sistema.
Las pruebas del sistema (según Métrica v3) ejercitan a fondo el sistema completo para verificar que todo funciona bien. Dentro de las pruebas del sistema se encuentran varios tipos de prueba como pruebas funcionales, de carga, de seguridad, de usabilidad, de stress, etc. En este caso, yo me voy a centrar solo en las pruebas funcionales, esto es, las pruebas que verifican que el sistema hace lo que debe hacer a través de su interfaz externa, en este sistema, una interfaz de usuario gráfica.

Lo primero que vamos a definir es qué se puede hacer con la aplicación:

1. Crear un nuevo formulario.
2. Modificar un formulario existente.
2.1. Añadir nuevos controles.
2.2. Eliminar controles
2.3. Modificar las propiedades de los controles
2.4. Modificar la posición de los controles.

Una vez definida la funcionalidad a probar, hay que determinar los valores de prueba. Estos valores de prueba son, sin duda, los formularios. Dividimos los formularios en distintas categorías.

- Formularios básicos: Un único componente.
- Formulario simples: Entre dos y cuatro componentes.
- Formularios medios: entre cinco y ocho componentes.
- Formularios grandes: entre 9 y 14 componentes.
- Formularios enormes: quince o más componentes.

También será necesario, cuando haya más información sobre el proyecto, estudiar las características de cada componente que puede haber en un formulario y decidir si es necesario diseñar pruebas específicas para probar características particulares de componentes.


Diseño de pruebas.

Ahora, se trata de combinar las operaciones y los tipos de formularios para construir pruebas. Combinando las 5 operaciones a realizar sobre un formulario con los 5 tipos de formularios posibles tenemos un total de 25 tipos de pruebas iniciales. Algunos ejemplos son:

1. Crear un formulario básico.
2. Añadir un nuevo control a un formulario medio.
3. Eliminar un control de un formulario enorme.

Estas pruebas se repetirán varias veces con distintos tipos de controles. Además, estas pruebas se combinarán entre ellas para construir pruebas mayores. Por ejemplo, si combinamos las pruebas 2 y 3 para un formulario enorme obtenemos una prueba que añade nuevos controles y después elimina otros controles ya existentes.

Estimamos que, en las primeras iteraciones, la herramienta tendrá pocas opciones y pocos controles. Así, en las primeras iteraciones deben primar las pruebas de creación de formularios básicos y simples. Por la misma razón, en las últimas iteraciones deben primar las pruebas de modificaciones de formularios grandes y enormes.


Herramientas.

Queremos usar dos herramientas para realizar estas pruebas.

La primera herramienta nos permitirá definir una secuencia de interacciones con la interfaz gráfica (mover el ratón, hacer click, etc.) y ejecutarlas sobre nuestra aplicación. Además, esa herramienta debe permitir comprobar que los resultados de las interacciones son los esperados (un cambio en la pantalla, la aparición de una nueva ventana, etc.).
En un post anterior ya hemos comentado algunas de las herramientas que podemos utilizar para implementar este tipo de pruebas en sistemas Java, tales como Marathon (http://marathonman.sourceforge.net/) o Abbot (http://abbot.sourceforge.net/).


Hemos visto que queremos construir nuevas pruebas a partir de pruebas básicas (por ejemplo una prueba que sea crear un formulario nuevo, insertar tres controles, guardarlo, cargarlo, insertar dos controles más, borrar un control, modificar otro, etc). Esto presenta algunos problemas:
1) Estas pruebas son largas de codificar (perdemos recursos) y, cuanto más largas sean, más tendremos que escribir más errores podemos tener.
2) El número de posibles combinaciones de añadidos y modificaciones es muy alto.
3) Si hay algún cambio en la interfaz o bien damos por perdidas las pruebas que nos ha constado mucho tiempo implementar, o bien las modificamos con lo que perdemos más tiempo aún.

La solución es una herramienta que coja unas pocas pruebas simples, las combine y genere tantas pruebas complejas como queramos. Existen trabajos que hablan de como combinar pruebas pero no conozco ninguna herramienta que pueda hacerlo.

Como opino que las ventajas superan a los inconvenientes, nos planteamos construir una herramienta ad-hoc para construir pruebas a partir de otras. Una vez que tengamos decida una herramienta concreta y sepamos qué formato tienen las pruebas (por ejemplo archivos de código Python o archivos XML) podremos desarrollarla.



Siguientes pasos.

Como hemos comentado al principio, esto es una aproximación preliminar. A medida que el desarrollo del sistema avance, se definan con más precisión la funcionalidad del sistema, se obtengan formularios de ejemplo por parte de los clientes, etc. Este plan de pruebas y las pruebas diseñadas se irán completando. Así, durante cada iteración se dispondrá de un conjunto de pruebas del sistema listas para verificar que todo va bien.

La información necesaria para seguir completando este plan es:
- Una descripción detallada de los componentes.
- Los casos de uso.
- Formularios, a ser posible, reales.

Ojo, las pruebas contempladas aquí no son suficientes para desarrollar una buena fase de pruebas del sistema. Además se deben probar la correcta implementación de los casos de uso (http://es.wikipedia.org/wiki/UML#Ejemplo_de_diagrama_de_caso_de_uso) del sistema. Por ejemplo, probablemente exista un caso de uso que sea cargar formulario de archivo y otro que sea guardar formulario en archivo dónde se explicará como tiene que comportarse la aplicación al realizar esas operaciones. Por tanto, debemos desarrollar también algunas pruebas que comprueben no solo que los formularios se cargar y guardan correctamente y dichas operaciones se comportan como dicen los casos de uso.


Si este proyecto sigue adelante y, además, hay la oportunidad de poner estas ideas en prácticas, os lo comentaré.

Andalucía, tierra de OpenCMS

Saludos a todos.

En una entrada anterior comentada que, en Andalucía (al sur de España), las tencologías dominantes en la industria, sin duda, son Java y Oracle (http://rincew.blogspot.com/2005_10_01_rincew_archive.html). De un tiempo a esta parte, me he dado cuenta que varias empresas (de las más importantes, al menos en mi opninión) están utilizando OpenCMS como plataforma de desarrollo de portales (http://www.opencms.org/).

No conozco la herramienta, así que ignoro si es la mejor, pero si varias empresas importantes y la administración pública la usan, desde luego hay que tenerla en cuenta.

Referencias sobre generación de pruebas a partir de casos de uso.

Saludos.

Para quién le interese. A continuación pongo algunos enlaces sobre documentación para generar pruebas a partir de casos de uso.

En mi página web ha puesto los reusltados de un enlace comparativo con casos prácticos:
http://www.lsi.us.es/~javierj/publications.html
(descargar "Generación de casos de prueba a partir de la especificación funcional")

En STORM es posible encontrar varias listas de herramientas de prueba. Aunque no conozco ninguna herramienta de acceso público para generar pruebas, sí
se pueden encontrar algunas herramientas muy interesante para implementar las pruebas. Se puede encontrar alguna herramienta de libre descarga para
TSL, pero está a añados luz de distancia de WinRunner.
http://www.mtsu.edu/~storm/

Algunos artículos que pueden ser interesantes. Son fáciles de encontrar en Google. Si alguien no los localiza que no dude en pedírmelos:

Axel Ruder et-al. 2004. A Model-based Approach to Improve System Testing of Interactive Applications. ISSTA’04. Boston, USA.
L. Briand, Y. Labiche. 2002. A UML-Based Approach to System Testing. Carleton University Inner Report.
Heumann , Jim, 2002. Generating Test Cases from Use Cases. Journal of Software Testing Professionals.
Nebut, C. Fleurey, et-al. 2003. Requirements by contract allow automated system testing. Procedings of the 14th International symposium of Software Reliability Engineering (ISSRE'03). Denver, Colorado. EEUU.

UCTSystem. http://www.irisa.fr/triskell/results/ISSRE03/UCTSystem/UCTSystem.html

Espero que los disfruteis.

Si alguien tiene interés en el tema y quiere más información que no dude en comunicármelo.