Introducción

La técnica de testeo funcional más sencilla es la que se conoce como testeo exploratorio (exploratory testing) que consiste en buscar fallos de manera intencionada y más o menos estructurada pero sin un guión predefinido.

Se podría considerar también testeo exploratorio el simple hecho de utilizar la aplicación ya que si bien no existe intencionalidad en la búsqueda de fallos, no es raro que se detecten. No en vano al utilizar la aplicación la sometemos a innumerables casos de prueba, muchos de los cuales sería imposible cubrir mediante pruebas sistemáticas.

Conviene remarcar que el testeo no solo abarca la búsqueda de fallos, si bien es quizá la parte más importante. Para que los fallos puedan ser arreglados de forma eficaz es imprescindible que el tester realice una serie de acciones posteriores: reproducción del fallo, acotación de las causas, comprobación de la existencia de una incidencia relacionada y finalmente, en caso necesario, apertura de una nueva incidencia. El presente documento recopila algunas buenas prácticas a tener en cuenta para cada una de esas acciones.

Búsqueda de fallos

Estas son algunas de las recomendaciones a la hora de realizar testeo exploratorio:

• Intentar probar todas las opciones de cada herramienta o funcionalidad, incluyendo la cancelación.
• Testear la robustez de la aplicación ante casos de prueba ilógicos (por ejemplo introducir una letra en un cuadro de texto que espera valores numéricos). En este tipo de pruebas se suelen descubrir gran cantidad de fallos ya que frecuentemente los desarrolladores se centran en los casos lógicos y olvidan los ilógicos.
• En general la actitud a adoptar por el tester debe ser la de tratar de “romper” la aplicación. Buscar sus fisuras y sus límites.
• Identificar variables y los distintos valores de éstas que a priori provocarían comportamientos distintos de la aplicación. Esto optimiza las pruebas en el sentido de que minimiza el número de casos de prueba manteniendo la cobertura. Por ejemplo, gvSIG utiliza el mismo driver para todos los formatos de fichero raster. Para gran cantidad de pruebas, probar con más de un formato de fichero raster sería redundante ya que no es de esperar que el comportamiento sea distinto en función del formato. Por tanto el formato de fichero raster en este caso no sería una variable a tener en cuenta. En el caso anteriormente comentado del cuadro de texto, la variable sería el tipo de carácter donde podríamos identificar los valores: numérico y alfanumérico. Además dentro de los valores de tipo numérico podríamos diferenciar entre número entero y número decimal. Estos valores recogen a priori todos los casos para los que podemos esperar comportamientos distintos.

Reproducción del fallo

Para que un fallo detectado -ya sea de forma casual o mediante testeo exploratorio- pueda ser arreglado, en primer lugar es imprescindible que seamos capaces de reproducir las condiciones que lo provocan. Así, lo primero que haremos cuando encontremos un error es intentar reproducirlo, es decir, volver a recrear paso por paso las condiciones del momento en que sucedió. En primer lugar probaríamos con las últimas acciones realizadas antes de encontrar el fallo y en caso de que no se consiga reproducir iríamos retrocediendo hacia acciones anteriores. En el momento en que somos capaces de reproducir el fallo dos veces consecutivas realizando exactamente los mismos pasos podemos concluir que el fallo es reproducible.

Acotación de las causas del fallo

Ser capaz de reproducir el fallo es imprescindible pero no suficiente. Podemos tener identificados una serie de pasos que desembocan en el fallo pero muy probablemente algunos sean meramente circunstanciales y no influyen realmente en el problema. Esta información no solo es irrelevante sino que puede ser contraproducente a la hora de arreglar el error ya que hace seguir pistas falsas.

Frecuentemente la causa real de un fallo poco tiene que ver con la que incialmente sospechábamos en el momento de detectarlo. Siempre va ser necesaria una mínima labor de investigación dirigida a acotar las verdaderas causas del fallo. Veámoslo con un ejemplo:

Pongamos por caso que sucede un error cuando realizamos un zoom en una vista en la que tenemos capas de varios tipos: raster, vectoriales, locales y remotas. Si tuviéramos que escribir el título del error en este momento seguramente pondríamos algo así como “Error al hacer zoom”. Supongamos que comenzamos a descartar variables y descubrimos que el error sólo sucede con una de ellas, una capa vectorial. Lo siguiente que nos podríamos preguntar es si sucede con todas las capas vectoriales o sólo con la que tengo cargada. Probamos con otra capa vectorial y no sucede. Entonces nos preguntamos qué características especiales tiene la capa en cuestión. Vemos que tiene configurado un etiquetado. Desactivamos el etiquetado y descubrimos que ya no se produce el error. Otra cosa que podemos descartar es si sucede solo al hacer zoom o en general al refrescar la vista. Descubrimos que sucede lo último. Además probamos con distintos tipos de capas vectoriales y resulta que sólo sucede con capas WFS. Lo que en un principio parecía tener que ver con la herramienta zoom finalmente tiene que ver con el etiquetado de capas WFS.

Se trata de identificar variables y los distintos valores de esas variables que puedan provocar cambios de comportamiento. Algunas de las variables típicas que podríamos manejar a la hora de acotar un error son:

• El tipo de fuente de datos: raster/vectorial, local/remota, el formato de fichero, la capa, el servidor...
• El sistema de referencia.
• Las unidades de medida.
• El tipo de leyenda.
• Etc.

Conviene remarcar que a la hora de identificar estas variables es muy importante la propia experiencia en el uso de la aplicación y en el testeo.

Comprobando si el fallo ha sido registrado con anterioridad

Una vez acotada la causa del fallo y antes de abrir la correspondiente incidencia es conveniente comprobar si ha sido detectado y documentado con anterioridad, es decir, si ya existe una incidencia o petición abierta relacionada con el mismo. Es importante, en lo posible, evitar la duplicidad de peticiones.

Para ello accederemos al sistema de gestión de bugs o tracker y realizaremos algunas búsquedas mediante las herramientas de filtro o mediante el cuadro de búsqueda situado en la parte superior derecha.

Si ya existe una petición relacionada con el fallo intentaremos aportar nuevos datos a la misma. En caso contrario procederemos a abrir una nueva.

Abriendo una petición

Una vez comprobado que no existe ninguna petición relacionada con el fallo procederemos a abrir una nueva desde el tracker (Se requiere estar registrado en el sistema. Conseguir una cuenta ).

Antes de ello es importante tener recopilada toda la información necesaria:

• Número de versión y número de build de gvSIG [1] (ver menú “Acerca de...” de gvSIG).
• Número de versión de la extensión [1] [2] (ver menú “Acerca de...” de gvSIG).
• Sistema Operativo [1]
• Fichero de registro de errores [1] [3]. ( Dónde encontrar el log de gvSIG ).
• Ficheros de datos [3].
• Capturas de pantalla [3].
• Nombre del caso de prueba y del plan de pruebas. En caso de que el error se haya detectado durante la ejecución de un plan de pruebas es recomendable indicarlo en la descripción del fallo.

Asimismo un dato a tener en cuenta a la hora de determinar la importancia de un error es el comportamiento de la aplicación tras el fallo. Básicamente identificar si podemos seguir utilizando la aplicación de manera normal o no, así como si se produce pérdida de datos o de configuración, en cuyo caso deberá aportarse el dato en la incidencia.

Una vez recopilada toda la información se procederá a rellenar la petición (consultar Ayuda para rellenar peticiones).

Por último se tendrá en cuenta que el idioma recomendado es el inglés.