Personal tools
You are here: Home Production Proyectos Testing Documentos de trabajo Procedimientos de testeo de gvSIG Información relevante Pautas para generar planes de prueba (gvSIG 2.x)
  1. Para definir los planes de pruebas se utilizará la aplicación Freemind.
  2. Se definirá un plan de pruebas para cada plugin de gvSIG.
  3. Cada plan de pruebas se corresponderá con un fichero .mm
  4. En cada plan de prueba se identificarán los distintos casos de prueba, los cuales se podrán organizar por casos de uso o por cualquier otro criterio de agrupación. Un caso de uso es una acción o conjunto de acciones que tienen un objetivo concreto desde el punto de vista del usuario (ej: imprimir un mapa) mientras que un caso de prueba es cada una de las múltiples vías que existen de llevar a cabo un caso de uso teniendo en cuenta todas las variables que puedan provocar que la aplicación tenga un comportamiento distinto (ej: imprimir un mapa a partir de capas vectoriales / imprimir un mapa a partir de capas raster).
  5. Para cada caso de prueba se detallarán los pasos necesarios para una correcta ejecución del mismo incluyendo los pasos correspondientes a la comprobación, ya que es imprescindible que el tester sea capaz de saber si el caso de prueba se ha ejecutado correctamente o no. Se indicarán, asimismo, los datos concretos a utilizar (las instrucciones para adquirir los datos deberán figurar como nota del elemento raíz del plan de pruebas). En lo posible se utilizarán datos ya incluidos en los juegos de datos existentes. En caso de que sea necesario utilizar otros datos se deberán incluir en el repositorio de geodatos junto con un fichero de texto descriptivo en el que se incluirá al menos información sobre el autor y la licencia de uso). El fichero o ficheros que formen los geodatos junto con el fichero de texto se comprimirá y se adjuntará a una petición de tipo "add-on request" en el sistema de gestión de peticiones del proyecto.
  6. En el elemento raíz se insertará una nota (menú Insertar>Nota) que contenga los siguientes elementos:
    • [Testplan] (etiqueta que identifica el elemento de Freemind como plan de pruebas)
    • name= (indicar el nombre del plan de pruebas; deberá coincidir con el nombre del plugin al que corresponda)
    • description= (breve descripción de las funcionalidades que certifica el plan de pruebas)
    • application= (indicar el nombre del plugin que se certifica)
    • version= (indicar la versión del plan de pruebas)
    • notes= (aquí se indicará cualquier otra información de interés, como por ejemplo requerimientos de software o de datos; se recomienda hacer una recopilación de los datos necesarios para pasar todo el plan de prueba y aportar las instrucciones para su descarga)
  7. Cada uno de los elementos intermedios entre el raíz y un caso de prueba es un módulo, en el cual se deberá insertar una nota que contenga los siguientes elementos:
    • [module] (etiqueta que identifica el elemento de Freemind como módulo)
    • name= (indicar nombre del módulo)
    • description= (indicar descripción del módulo)
  8. En el elemento correspondiente al caso de prueba se insertará una nota que contenga los siguientes elementos:
    • [testcase] (etiqueta que identifica el elemento de Freemind como caso de prueba)
    • name= (indicar nombre del caso de prueba)
    • description= (indicar descripción del caso de prueba)
    • priority= (indicar la prioridad relativa del caso de prueba; la prioridad relativa hace referencia al orden con el que conviene ejecutar los distintos casos de prueba en función de la importancia de los mismos; los posibles valores ordenados de mayor a menor prioridad son los siguientes: blocker, critical, major, minor, trivial)
  9. Para cada uno de los pasos se insertará una nota que contenga los siguientes elmentos:
    • [step] (etiqueta que identifica el elemento de Freemind)
    • name= (indicar el nombre del paso; debe hacer referencia a la acción a realizar)
    • description= (indicar instrucciones concretas sobre la acción a realizar en caso de que el nombre del paso no sea suficientemente descriptivo)
    • severity= (indicar el grado en que afecta al uso de la aplicación el hecho de que se produzca un error al ejecutar el presente paso; como referencia, a un paso que potencialmente afecta a más de un caso de prueba (como por ejemplo “añadir capa”; común en múltiples casos de prueba) se le asignaría una severidad alta; Los posibles valores ordenados de mayor a menor severidad son: blocker, critical, major, minor, trivial).

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: