1.SISTEMAS OPERATIVOS EN LOS QUE TESTEA GVSIG:

gvSIG es multiplataforma. La estabilización de una nueva versión se hará sobre por lo menos una distribución de los siguientes sistemas operativos: Linux (Kubuntu), Windows (XP) y MacOS.

2.FASES DE UN INSTALABLE:

Las fases del ciclo de vida de un instalable de gvSIG serán a lo sumo 3: fase de desarrollo, fase de estabilización y fase estable. En las tres fases será posible hacer testeo de la aplicación, reportar errores y sugerencias. Puede darse el caso de que se quiera publicar de forma oficial un desarrollo estabilizado por otra organización. En este caso bastará que el dueño del desarrollo... (caso de la extensión de Castilla y León).

3.TESTEO COLABORATIVO:

El testeo de las aplicaciones gvSIG seguirá 2 metodologías: testeo exploratorio y testeo mediante planes de pruebas. En ambos casos la participación de la comunidad gvSIG será prioritaria.

4.SISTEMA DE GESTIÓN DEL CAMBIO:

Se tendrá una base de datos para el seguimiento de las incidencias (errores y sugerencias tanto para las aplicaciones gvSIG como para la documentación). Dicha base de datos tendrá que contener los campos necesarios para el correcto seguimiento de las incidencias.

5.PUBLICIDAD DE LOS INSTALABLES:

De cara al testeo colaborativo será necesario tener acceso público a los instalables que se generen para ser testeados.

6.REPORTE DE ERRORES Y SUGERENCIAS:

Para dar de alta errores será necesario tener acceso público a un formulario para dar de alta errores a través de una interfaz web. Además será necesario tener listados accesibles de forma pública en donde consten: los ticket de error en nestado abierto para una versión y los ticket corregidos por cada build publicado.

7.SOPORTE A LAS LISTAS GVSIG:

Dado que muchas veces los reportes de error se hacen a través de las listas, es necesario dar soporte a dichas listas en temas relacionados con testeo: bien respondiendo dudas concretas sobre errores que aparecen a los usuarios, bien traduciendo a tickets de error los reportes que nos hacen llegar los usuarios a través de las listas de correo.

8.PRIORIDADES DE CORRECCIÓN EN LAS DISTINTAS FASES DE TESTEO:

En fase de estabilización las prioridades e importancia de los errores a corregir los fijará la CIT (¿u organización gvSIG?), mientras que en fase de desarrollo estas prioridades las gestionará la propia organización responsable del desarrollo en cuestión. En fase estable, los errores recibidos serán tenidos en cuenta para la siguiente versión a publicar a menos que se trate de un error grave de la aplicación.

9.ESTABILIZACIÓN DE UNA VERSIÓN:

Todo desarrollo de gvSIG (Desktop, Mobile, etc) pasará una fase de estabilización de cara a ser publicada una versión estable del mismo. Esta fase de estabilización será coordinada por el equipo de testeo de gvSIG, como se detallará en el procedimiento correspondiente. Dependiendo del origen del desarrollo en cuestión podrá darse el caso que dicha fase tenga duración casi nula, en el supuesto que el desarrollo ya haya sido entregado a un cliente (distinto de la CIT) y éste quiera publicarlo como desarrollo oficial. Al comenzar la fase se decidirá que funcionalidades se estabilizarán. Además se deberán tener en cuenta los errores detectados en versiones anteriores para que sus correcciones sean incluidas en la nueva versión.

10.NUEVA VERSIÓN ESTABLE:

Previamente a publicar una nueva versión estable de gvSIG se tendrán que verificar todas las correcciones realizadas sobre el instalable (y si procede sobre el manual también). De esta verificación se generarán 2 listados: 1.lista de correcciones de errores respecto a la versión anterior, 2.Lista de errores conocidos

Se tendrá que disponer de una lista de novedades (nuevas funcionalidades) respecto a la versión anterior.

11.JUEGO DE DATOS PARA TESTEO:

Será necesario poner a disposición de los potenciales testers un juego de datos completo (ficheros locales, servicios remotos, BBDD, etc) cuyo acceso sea público.

12.PLANES DE PRUEBA:

Cuando se decida que un desarrollo debe ser estabilizado, junto con los instalables, la organización responsable del desarrollo entregará a la CIT un plan de pruebas en donde se tendrán definidas las pruebas de nueva funcionalidad del desarrollo en cuestión. Por tanto dichas pruebas deberán definirse en la fase de desarrollo del proyecto. Puede darse el caso de que el desarrollo provenga de una colaboración entre proyectos, en cuyo caso la definición de las pruebas del plan quedará a cargo de la CIT (¿u organización gvSIG?), debiendo evaluar la posibilidad de definir o no dichas pruebas.

13.PUBLICACIÓN OFICIAL DE UNA EXTENSIÓN (caso organización externa al proyecto):

Una organización que haya desarrollado una extensión para una versión de gvSIG podrá pedir la publicación oficial de dicha extensión. En este caso, se deberá identificar la estabilidad de las nuevas funcionalidades implementadas en dicha extensión y a su vez identificar la inestabilidad que dicha extensión introduce en las funcionalidades de la versión de gvSIG sobre la que se instala. En caso de que la extensión ya esté en producción, se podrá no testear las nuevas funcionalidades, dejando a cargo de la organización externa la responsabilidad de su estabilidad. Respecto a la evaluación de las inestabilidades que dicha extensión introduce en las funcionalidades de la versión de gvSIG sobre la que se instala, se hará mediante testeo de regresión (de cara a la documentación de estos errores) y se evaluará también la corrección de los errores identificados, siempre que éstos se deban corregir sobre la propia extensión.