Notas previas

Cuando hacemos mención a gvSIG, nos estamos refiriendo tanto a gvSIG desktop como gvSIG Mobile.

¿Qué es la redacción de un Plan de Pruebas (PDP)?

Para saber la estructura, contenido, y demás temas relacionados con PDP te remitimos a la documentación que hemos preparado en base a nuestra propia experiencia.

Qué es un Plan de Pruebas

Consejos útiles sobre PDPs

¿Qué tipo de pruebas abordamos primero en el PDP?

Al generar el primer plan de pruebas de una extensión sobre gvSIG, será necesario desarrollar 2 conjuntos de pruebas: las llamadas pruebas de nueva funcionalidad (o alfa) y las de persistencia de datos.

Pruebas de nueva funcionalidad: se entiende que estas pruebas son las que testean las nuevas funcionalidades desarrolladas, sin tener éstas interacción con el resto de la aplicación (resto de extensiones existentes en gvSIG), aunque para el testeo de algunas de estar nuevas funcionalidades sea imprescindible utilizar otras partes de gvSIG (nos referimos a crear vista, abrir vista, etc).

Pruebas de persistencia: la persistencia de datos es fundamental a la hora de estabilizar una o varias extensiones de gvSIG. Es la forma de garantizar al usuario final que sus proyectos (.gvp o .gvm) no serán corrompidos y podrán ser abiertos y guardados correctamente por nuestra aplicación. En este sentido será importante testear la persistencia de todo tipo de dato susceptible a ser guardado y recuperado. Más información en Persistencia de datos .

Una vez que este tipo de pruebas estén lo suficiententemente documentadas, podrán abordarse pruebas más transversales a las funcionalidades nuevas, pero siempre como una segunda etapa.

¿Dónde redactar el PDP?

La redacción de los PDP se hace sobre una herramienta de gestión de pruebas. Más información en Gestor de pruebas .

Para acceder correctamente al gestor, hemos escrito esta ayuda de cara a sortear los problemas de compatibilidad que hemos detectado entre el gestor y la java que esté usando nuestro navegador web. Ayuda para navegador Firefox .

De cara a ver un ejemplo de pruebas redactadas en el gestor, seguir este enlace.

De cara a aprender a usar el gestor de pruebas, se ha elaborado una guía de diseño (centraros a partir del apartado 4.1.4 - Creación de un caso de uso). Esta guía complementa el manual de la aplicación Salome TMF. Te recomendamos que estudies este material antes de redactar las pruebas.

¿En qué idioma redactar las pruebas?

Tener en cuenta que las pruebas podrán ser ejecutadas por cualquier tester interesado en colaborar con la estabilización del desarrollo que se está testeando. De esta forma entendemos que adoptar una lengua lo más común posible facilitará el testeo colaborativo. Es por ello que hemos decidido aconsejar preferentemente el uso del idioma inglés.

Para los casos en que no sea posible la adopción del idioma inglés, se coordinará a través del área de internacionalización, de cara a conseguir la traducción de las pruebas redactadas en un idioma distinto al inglés.

¿Qué datos utilizo en las pruebas? ¿Dónde los dejo?

Para las pruebas que se redacten será necesario la utilización de datos de tipos diversos; nos referimos a que seguramente nos toque trabajar con:

1. Ficheros de geodatos en local (distintos formatos, vectoriales, raster...)
2. Bases de datos (siempre que se pueda se tendrá que tener acceso público a las mismas)
3. Url de servicios web (se deberán de proveer las url con fecha de último acceso)
4. Ficheros proyecto (.gvp, .gvm) para pruebas de persistencia
5. Tablas de color
6. Leyendas predefinidas (.gvl, .sld)
7. etc...

Las pruebas almacenadas en el gestor deberán estar enlazadas a los datos necesarios para ejecutar dichas pruebas. Si así lo hacemos, estos datos pasarán a distribuirse a los testers, y por ello es necesario que sean datos libres y distribuibles. En cada caso se evaluará la posibilidad de, junto con los datos, distribuir los créditos correspondientes.

Desde el área de testeo de gvSIG, hemos creado un espacio en el servidor de Osor y unas instrucciones mínimas de cara a subir los datos necesarios y enlazarlos en el gestor de pruebas.

Una vez las pruebas están en el gestor...

... y hayan sido validadas por el área de Testing se procederá a ejecutarlas, para lo cual previamente será necesario crear las correspondientes campañas o de ejecución o suites en la aplicación de gestión (ver documentación al respecto).

Además de ejecutar las pruebas específicas de las nuevas funcionalidades (pruebas alfa) será necesario ejecutar también las pruebas genéricas de regresión y de persistencia que el área de Testing estime oportuno, para lo cual desde la mencionada área se generarán las correspondientes campañas.

Para saber cómo ejecutar las pruebas, hemos redactado esta guía de ejecución. Para hacerlo más ágil, hemos redactado los 10 pasos que todo tester debe saber para ejecutar sus pruebas asignadas en el gestor de pruebas.

Reportar los errores de la ejecución a los desarrolladores

Mediante la ejecución de las pruebas, se detectarán errores que deben ser reportados en el trac de bugs de gvSIG para que los desarrolladores puedan abordarlos y corregirlos en sucesivos binarios, hasta llegar a un grado de estabilidad aceptable para una versión final del producto que está en proceso de estabilización.

Estos mismos conceptos son aplicables a las sugerencias de mejoras que se detectan a la hora de testear una nueva extensión de gvSIG.

Para dar de alta un nuevo ticket en cada uno de los tracs, se deben tener en cuenta ciertas peculiaridades, descritas aquí .

Enlace a los trackers públicos de gvSIG

Para el caso de los errores que provienen de la ejecución de pruebas redactadas, es muy aconsejable hacer mención al nombre de la prueba y el escenario concreto en el que se ha detectado el fallo. De esta forma, el tester se estará ahorrando la descripción paso a paso del error.

Conviene recordar que tener los errores documentados en los tracs públicos es de vital importancia de cara a no duplicar faena, y poder consultar en cualquier momento el estado de un error cualquiera.