Descripción para cada nivel

• Sistema: El sistema, por regla general, será la aplicación en sí. En el caso de gvSIG el sistema es gvSIG Desktop o gvSIG Mobile.

  En el plan de prueba piloto el sistema es gvSIG Desktop v1.1.2.

• Subsistema: El subsistema definido en el plan de test debe estar relacionado con las extensiones de gvSIG, esten éstas embebidas en la aplicación principal o externas a la misma. Se debe tener en cuenta en qué extensión está contenida cada funcionalidad que se desea testear para evitar el caso de no tener instalada una extensión que debe ser probada. Se intentará definir los posibles subsistemas de forma que sean independientes unos de otros. De este modo asociar los subsistemas a las extensiones (tanto embebidas como externas) de gvSIG garantiza cierta independencia.

  En el plan de prueba piloto uno de los subsistemas es la extensión JCRS v0.2. En general se pretende definir un subsistema por cada directorio presente en .../bin/gvSIG/extensiones. En este sentido las funcionalidades que se probarán en cualquier subsistema son las que proporcionan las extensiones de gvSIG (que se pueden consultar a través del panel de Preferencias) que cuelgan del directorio que define el subsistema.

• Módulos: Los módulos definidos en el subsistema deben representar todas las funcionalidades que cubra un determinado subsistema. Cada módulo estará asociado a un verbo como puede verse en el ejemplo de plan piloto.

  En el plan de prueba piloto los módulos son: 1."Definir CRS" ,2."Transformar CRS" y 3."Definir CRS de usuario". Un pequeño comentario sobre el módulo "Definir CRS de usuario": a priori parece ser un caso particular del módulo 1, pero al utilizar la extensión JCRS nos damos cuenta que el modulo 1 se refiere a la asignación de un CRS, mientras que el módulo 3 implica la edición de un CRS.

  Los módulos no tienen porqué coincidir con las extensiones de cada subsistema. Se intentará agrupar las funcionalidades del subsistema de forma que resulte cómoda para el tester de definir/ejecutar los casos de prueba. Funcionalidades similares irán a parar al mismo módulo.

• Casos de uso: Estos casos definen qué hace el módulo correspondiente desde el punto de vista del usuario. Los casos de uso representan las distintas formas de hacer uso de la funcionalidad definida en el módulo correspondiente.

  En el plan de prueba piloto y para el módulo 1, los casos de uso son: 1.1 "Definir CRS por defecto", 1.2 "Definir CRS de la vista" y 1.3 "Definir CRS de la capa".

• Casos de prueba: Los casos de prueba representan los posibles caminos (secuencia de pasos) mediante los cuales probamos un caso de uso concreto. En este punto debemos analizar las opciones de posibles caminos que se nos presentan en una ventana/formulario. Además cada caso de prueba debe de detallarse paso a paso para no dar lugar a interpretaciones ambiguas de la prueba a realizar.

  Se generarán 2 casos de prueba diferentes una vez se haya identificado que la selección/inclusión de un parámetro resulte en diferentes configuraciones de opciones. Por ejemplo, si al seleccionar un parámetro en un listado cambian las opciones que ve el usuario, debemos de hacer un caso de prueba para cada una de las opciones disponibles en el listado.

  Si al describir un caso de prueba se deben especificar un conjunto de pasos que ya están definidos en otro caso de prueba más simple, se intentará no repetir todo el conjunto de pasos, haciendo referencia al nombre del caso de prueba anteriormente definido. Esto trae algunas repercusiones en caso de que el test falle: suponer que estamos ejecutando el test B donde un conjunto de pasos que se deben seguir son el test A más simple. Si falla el test A, pero no lo hemos pasado con anterioridad al test B, fallará el test B. Una solución puede ser imponer precondiciones a los test de prueba, como por ejemplo, haber pasado test A para empezar con test B. Estas precondiciones pueden estar definidas en los comentarios del test B.

  Las variantes, dentro de un mismo caso de prueba, que no modifiquen el camino a probar se llamarán variables. Cada variable debe estar identificada por un [nombre_de_variable] que toma diferentes valores dependiendo del caso concreto que se esté probando.

  Para la definición de los casos de prueba se priorizará según las opciones más comunmente utilizadas en gvSIG, por lo menos para una primera versión del plan de pruebas. Luego, para siguientes versiones se ampliarán los casos de prueba lo máximo que sea posible.

  En el plan de prueba piloto para el módulo 1 y caso de uso 1, algunos casos de prueba identificados son los siguientes: 1.1.1 "Definir CRS por defecto Tipo EPSG y Aceptar", 1.1.2 "Definir CRS por defecto Tipo EPSG, consultar InfoCRS y Aceptar", 1.1.3 "Definir CRS por defecto Tipo EPSG y Cancelar", etc. Además cada caso de prueba debe tener la secuencia de pasos que lo definen. En este sentido, para el caso de prueba 1.1.1 se tiene:

  Caso de prueba: "Definir CRS por defecto Tipo EPSG y Aceptar"

  1. Abrir gvSIG
  2. Pinchar en Preferencias
  3. Seleccionar Vista del árbol de Preferencias
  4. Pinchar en Proyección actual
  5. En Tipo seleccionar EPSG
  6. Verificar que esté seleccionado la opción [opción_de_selección]
  7. Escribir el criterio de búsqueda [cadena] a buscar
  8. Pinchar en Buscar
  9. Pinchar en Aceptar de la ventana de nuevo CRS
  10. Aceptar la ventana de Preferencias
  11. Crear Vista nueva
  12. Seleccionar Vista creada
  13. Abrir la Vista
  14. Comprobar que se cumple [Condición_comprobación]

• Escenarios: El escenario se crea cuando el caso de prueba se particulariza con los valores de las variables.

  Existen variables de entrada y de salida (datos de entrada y de salida). Las de entrada deben ser definidas priorizando los casos que se utilicen con más frecuencia en gvSIG, ya que es imposible cubrir todas las posibilidades con costes de tiempo razonables. Las variables de salida deben ajustarse al comportamiento esperado de la aplicación. En este punto ya podemos hablar de que se valide o no el test en función de la comprobación de las variables de salida.

  Cuando sea necesario utilizar ficheros como variables de entrada (cartografía, simbología, etc.) se tendrá que definir el nombre completo del fichero y además se debe describir donde están localizados dichos ficheros.

  Cuando las variables de salida sean la comprobación de varios parámetros presentes en una misma ventana, se intentará definir el conjunto como un único dato de salida a comprobar.

  A la hora de definir escenarios, primero se definen los datos de entrada que comprueben que la funcionalidad se ejecuta correctamente. En este sentido se debe pensar en las diferentes posibilidades de datos de entrada, pero teniendo muy presente que no se pueden probar todos los posibles valores de datos de entrada. Debido a esto, se debe pensar en definir conjuntos de datos de entrada que sean equivalentes entre sí (ésta es la definición de clase de equivalencia).

  Por último se deben crear escenarios para valores de datos de entrada que hagan que la aplicación falle (poner valores numéricos en campos de tipo texto, etc.) para controlar los mensajes de error/aviso que deberen de aparecer. Esta es la forma de testear las excepciones controladas en el subsistema.

  En el plan de prueba piloto para el módulo 1, caso de uso 1.1 y caso de prueba 1.1.1, un escenario identificado es:

  "Escenario 1":

  Datos entrada -->[opción de selección] = Por código, [cadena] = 63096405

  Datos salida --> [Condición comprobación] = EPSG:63096405 en la barra de estado de la vista creada

Esquema ejemplo extensión JCRS

Otras funcionalidades

• Geoprocesos: De forma interna gvSIG crea una clase abstracta para cada tipo de dato, que es al que se le aplica el geoproceso correspondiente. Por ejemplo una capa de líneas recibe el mismo tratamiento sin depender de su origen, es decir no importa si las líneas provienen de un shp o un dxf, el tratamiento y las rutinas son las mismas.
• Main gvSIG: Uno de los principales problemas sino el mas importante, es la estructuracion de la aplicación en modulos, casos de uso y casos de prueba. Al abordar el pdp de un modulo nos podemos topar con dos problemas que tienen la misma solución.

En primer lugar, se suele dar el caso de llegar al Caso de prueba, y necesitar mas niveles para abarcar toda la herramienta o aplicación del módulo en concreto. Un plan de pruebas, como ya sabemos, esta estructurado en 5 niveles: Subsistema, Módulo, Caso de uso, Caso de prueba y Escenario. Conforme vamos subdividiendo las funcionalidades de la aplicacion para adaptarla a la estructura de un plan de pruebas, en muchos casos llegaremos al caso de prueba y sus distintos escenarios y todavia nos faltarian mas subniveles para poder abarcar todas las funcionalidades que ofrece la herramienta. En ese momento cabe plantearse si seria mejor separar ese módulo en otros módulos, de forma que quedara algo así:

Módulo A---Casos de uso---Casos de prueba, y en un paso/accion de un Caso de prueba se nos remite a otro Módulo B, que a su vez contenga Casos de uso y Casos de prueba, y así sucesivamente.

Esta forma de actuar es posible siempre y cuando tenga una cierta lógica, como en el caso de que la funcionalidad a separar en un modulo independiente es común a otras herramientas, y no se deja al otro módulo "colgado". Por otro lado está el caso de las herramientas o ventanas que son comunes a otras herramientas. Tal es el caso del Selector de color, y del Selector de simbología. A estas ventanas se llega desde muchos caminos distintos, con lo que vale la pena separarlos en modulos distintos.

A la hora de desarrollar los casos de prueba de las Propiedades del gráfico, para los gráficos tipo punto, línea y polígono (rectángulo, círculo y polígono) nos encontramos con la situación descrita anteriormente: las ventanas que se abren al acceder a las propiedades de estos tipos de gráficos, son iguales a las del Selector de simbología para cada tipo de geometría, es decir, la ventana Propiedades del gráfico (para gráficos tipo punto) es igual que la ventana Selector de simbología (para símbolos tipo punto), y lo mismo ocurre con líneas y polígonos. Por lo tanto se recomienda que al desarrollar los pasos de los casos de prueba relacionados con las propiedades de este tipo de gráficos, al llegar a la acción en la que se abren las propiedades del gráfico, se remita al caso de prueba del selector de simbología que corresponda.

Otra forma de ahorrar tiempo y esfuerzo es la siguiente: En muchos casos, una herramienta o un cuadro de diálogo se puede abrir desde varios sitios, como en el caso anterior de las propiedades del gráfico (módulo mapa), a las que se puede acceder desde el menú desplegable Menú Mapa, desde el botón derecho del ratón, y haciendo doble click sobre el gráfico. En estos casos se recomienda desarrollar todos los casos de prueba partiendo de un mismo camino, y por otro lado hacer un caso de prueba que abarque los otros caminos, pero solamente desarrollarlo hasta que aparezca la ventana de propiedades, ya que una vez se abre la ventana de propiedades, lo que ocurre utilizando las herramientas de esa ventana es común, sin importar el camino escogido hasta abrir la ventana.

Por lo tanto se haria un caso de prueba en el que se encadenaran las acciones de hacer doble click sobre cada tipo de gráfico y luego botón derecho sobre cada tipo de gráfico, introduciendo la condición de comprobación en cada acción, de que se abre la ventana de propiedades. Nota: Las propiedades de los gráficos Control de vista, Leyenda, Norte... son diferentes a las de los gráficos punto, línea y polígonos, por lo que deben desarrollarse en casos de prueba independientes.

También se pueden juntar en un único caso de prueba las pruebas de herramientas o funcionalidades muy sencillas, que no requieren de un cuadro de diálogo para su uso, y que ofrecen un resultado visual inmediato (comprobación inmediata), como por ejemplo las herramientas de navegación: zoom más, zoom menos, pan, zoom completo, zoom previo, etc. Es una pérdida de tiempo tener que abrir y cerrar el programa sólo para probar un zoom más.