Difference between revisions of "Metodología para usar GXtest"

Latest revision as of 19:27, 15 August 2013

link= {{{3}}}

No hay una receta para usar GXtest, pero en este artículo se muestran algunos lineamientos generales que esperamos les sean de ayuda.

Realizar un estudio inicial

Para comenzar se debe tener claro cuál es el objetivo del proyecto, qué metas se quieren lograr:

• mejorar la calidad
• mejorar el soporte evitando que vuelvan a ocurrir incidentes ya resueltos
• ampliar el cubrimiento del test ejecutando las mismas pruebas con distintos juegos de datos en menos tiempo que haciéndolo manualmente
• etc.

En [[1]] post pueden encontrar una lista ampliada de posibles objetivos.

En primera instancia es útil hacer un plan de las funcionalidades que se quieren cubrir. Algo así como un inventario de las funcionalidades a automatizar. Luego, para cada una, hacer una primer pasada conceptual, describiendo en alto nivel las cosas a probar, las distintas cosas que hay que considerar (entradas, casos borde, casos críticos, etc.). Esto sirve bajar a tierra las cosas de a poco. De todas las funcionalidades listadas se puede hacer una priorización, ya que no se puede automatizar todo, es necesario hacer un estudio preliminar en donde se seleccionen los flujos funcionales sobre la aplicación que se desean automatizar. Estos casos de prueba se deben elegir acorde con el objetivo elegido y acorde con un criterio especifico como criticidad, uso, riesgo, etc.

Diseño en alto nivel

Una vez que se tiene el inventario de funcionalidades en alto nivel, se pueden desprender distintos guiones de prueba. Estos guiones se pueden hacer tan detallados como se quiera, y serán los que se automaticen después con GXtest. En este paso se baja más a tierra el inventario, ya viendo cuál va a ser el resultado de las pruebas automatizadas. Los casos de prueba se pueden clasificar en dos grupos, los ciclos funcionales (más a nivel de usuario) y las pruebas unitarias o a nivel de módulo. Al pensar en las suites en esta etapa ya se va visualizando el resultado que se obtendrá al finalizar la automatización de pruebas. Las suites simplemente agruparán casos que se relacionan conceptualmente, pero no tienen ningún tipo de relación o dependencia. No se pasan datos entre una Suite y otra. En una suite sólo se agregan TC y se indica la cantidad de veces que se quiere ejecutar. En el caso de que falle un TC de una suite, se seguirá con la siguiente ejecución que corresponda. Además, al inicio de la suite, se ejecutará un BAT que ajustará el estado de la aplicación al deseado para las pruebas (cargando un respaldo de la BD, copiando archivos, etc.). Se puede pensar entonces qué juegos de datos se deben preparar para cada conjunto de Test Cases. Entender / definir variables (entrada/salida) que definen el comportamiento de cada funcionalidad. De acá luego se van a desprender los datapools se podría decir.

Diseño de bajo nivel

Acá es donde se podrían aplicar técnicas de caja negra como máquinas de estado, etc., como para definir qué flujos se podrían probar, para las pruebas unitarias o modulares. Diseño de pruebas con datos (basado en la definición de variables). Se toma cada funcionalidad a probar (las definidas en el diseño de alto nivel) y se analizan los dominios de las variables, clases válidas, inválidas, valores posibles. Se define luego con qué juegos de datos se van a probar (acá es donde se combinan los valores, se puede aplicar técnicas de valores límites, categorías, etc, para cada variable, y luego para combinarlas se puede aplicar all-pairs por ejemplo). Acá si se definen los datapools, y si hay relaciones entre ellos. Es bueno definir los datos en un excel y no directamente en los datapools.... luego se importan fácilmente. Estos últimos dos pasos se tendría que planificar en iteraciones, como para lograr eso que dijimos de tener algo funcionando lo antes posible.... o sea, no esperar a tener todo diseñando como para automatizar algo, sino diseñar una funcionalidad, automatizarla, y luego seguir con el resto.

Automatizarlas con GXtest Designer

Simplemente tomar lo diseñado, automatizarlo con GXtest, y luego cargar los datos en los datapools. Para este punto tener en cuenta los siguientes puntos:

Nomenclatura

Es importante definir una nomenclatura de casos de prueba y carpetas. Esta práctica si bien es simple redunda en muchos beneficios. Una recomendación para los nombres de los casos de prueba es distinguir aquellos que son pensados como componentes de otros casos de prueba de que son pensados como ciclos que incluyen los componentes. A los casos de prueba integradores (ciclos) se los puede nombrar con Ciclo. Por otro lado es útil definir una estructura de carpetas que permita separar los casos de prueba generales (típicamente login, acceso a los menúes, etc) de los casos de prueba de los distintos módulos. Muchas veces también surgen casos de prueba temporales a los mismos se los puede nombrar con un prefijo común como pru o tmp.

Comentarios y Descripciones

Cada caso de prueba y datapool puede tener una descripción que diga en líneas generales cuál es su objetivo. Por otro lado dentro de los casos de pruebas podemos incluir comentarios que ilustren los distintos pasos dentro del caso de prueba. Dentro de los datapool es conveniente agregar una columna más que sea comentarios en la cual en caso de que se quiera se agregue un comentario para cada dato que se utilizará en las pruebas.

Componentes Reutilizables

Una de las ventajas principales de GXtest es la facilidad para reutilizar casos de prueba. Para poder explotar al máximo esta cualidad es importante definir cuáles son los casos de prueba que serán reutilizados, que variables de entrada y salida tendrán y que datapools utilizarán. Luego se construyen los casos de prueba principales simplemente anidando otros casos de prueba.

Descripción de las validaciones

Cada validación en GXtest tiene un campo extra en el cual se le puede incluir una descripción a ser mostrada en caso de que falle. Esta descripción es sumamente útil a la hora de analizar los resultados de una ejecución.

Crear las suites y agendarlas en GXtest Manager

Lo único que resta finalmente es armar el ambiente de ejecución en GXtest Manager, lo cual implica definir el Environment donde se encuentra la aplicación donde se desean ejecutar las pruebas, definir las suites (conjuntos de tests a ejecutar en grupo, con su respectiva cantidad de veces a ejecutar cada uno), y no muchas cosas más. Los resultados de cada ejecución quedarán guardados en la base de datos de GXtest y podrán ser navegados desde el Manager. La consideración más importante aquí es pensar con qué frecuencia se desean ejecutar estas pruebas.