Beneficios de GXtest

From GXtest Wiki
Revision as of 15:18, 15 March 2010 by Ftoledo (Talk | contribs)

Jump to: navigation, search


Según el Software Engineering Institue, el test ocupa entre el 30% y 40% del costo total de un proyecto. Para IBM y Gartner, si reparar un error en la etapa de desarrollo cuesta un dólar, repararlo durante la etapa de test cuesta 60 dólares y repararlo luego de la entrega del producto cuesta 100 dólares.

En este marco surge la pregunta de ¿por qué no adelantarse en el proceso de test en las etapas tempranas del desarrollo? La experiencia ha demostrado que la única forma de lograr esto es automatizando el test y con ese fin nace GXtest, único producto especializado en el test de aplicaciones GeneXus.

En este artículo recordamos sus principales ventajas, que lo hace único para la Comunidad GeneXus.

Contents

Específico para GeneXus

Mantenimiento

Los casos de test se adaptan a medida que la realidad va cambiando, de esa forma se integra al ciclo de prototipado de la aplicación GeneXus de manera natural.

La principal ventaja de GXtest es que permite adaptar rápidamente los casos de prueba a los cambios realizados en la aplicación. Con el enfoque tradicional, si se automatizan grandes cantidades de casos de prueba (porque se visualiza el beneficio que tiene la automatización), con cada cambio de la aplicación se vuelve MUY costoso el mantenimiento, haciendo que el costo sea mayor que el beneficio. Con las herramientas tradicionales con el simple cambio de nombre de un control dejarán de funcionar las acciones automatizadas sobre este control, y la forma de "darse cuenta" de que ya no funciona es al momento de ejecutar las pruebas que lo utilizaban. Este mismo problema se da si se cambia de versión de GeneXus o de generador. Imagínense que se cambia un nombre de un atributo en una transacción muy utilizada o que se actualiza la versión de GeneXus y se rompen todos los casos de prueba. En ese caso se pierde la motivación por mantener las pruebas automatizadas por el costo de retrabajo que implica. Con GXtest puede mantener la trazabilidad entre la aplicación y las pruebas en forma simple. La principal ventaja de GXtest es la flexibilidad para adaptar los casos de prueba a los cambios. Técnicamente, la automatización está ligada a la KB y no al HTML generado. Si GeneXus me permite hacer cambios de manera sencilla y generar la aplicación, no sería adecuado que el testing este trabando posibles mejoras.

Entendimiento del Modelo de pruebas

No hay que ser programador para crear los casos de prueba, cualquier analista funcional puede crear los mismos con total independencia tecnológica.

Con el enfoque tradicional, el esfuerzo construir un caso de prueba (aprender un lenguaje de scripting) y mantenerlos es muy grande, por lo cual muchas empresas deciden no automatizar. GXtest permite crear casos de prueba de manera sencilla (enfoque de record and playback), entenderlos mejor a través de un modelo abstracto, variar fácilmente los datos de entrada (con un enfoque de Data-driven testing) y mantenerlos al cambiar la KB. GXtest asocia los artefactos de prueba a elementos de la KB de GeneXus, y por esto no se pierden esas asociaciones, ya que es una herramienta específica para automatizar aplicaciones generadas con GeneXus.

GXtest, a diferencia de la mayoría de las herramientas, tiene un enfoque de Testing Basado en Modelos. Esto es como para acompañar la filosofía GeneXus en el sentido de la simplicidad en el desarrollo. Los modelos son más simples de entender y de mantener que el código. A partir de los modelos abstractos luego se pueden obtener casos de prueba concretos y ejecutables. Está de esta forma más asociado al modelo de desarrollo que si estuviera asociado al html que genera GeneXus.

Data-Driven Testing

Mediante esta técnica podemos separar el flujo del caso de prueba y los datos de entrada y salida de los mismos, para de esta forma fácilmente agregar más casos de prueba con tan solo agregar nuevos datos. No todas las herramientas permiten hacer esto en forma sencilla, cuando en realidad es algo que brinda grandes facilidades a quienes diseñan y automatizan casos de prueba.

Esto brinda la posibilidad de automatizar una sola vez un flujo sobre la aplicación y luego poder ejecutarlo con cientos de datos distintos viendo cuál es el comportamiento recibido para el mismo.

La estructuración de Test Cases y el modelo planteado hace que sea más fácil pensar los casos de prueba, y también más fácil agregar nuevas pruebas, agregando simplemente más datos. Para esto es que existen objetos llamados Datapools, los cuales son simplemente estructuras tabulares en donde podemos almacenar distintos datos. Si los testers ya contaban con datos de casos de pruebas en planillas de cálculo es posible transferirlas a GXtest en forma muy simple, ya que se pueden alimentar a los Datapools con datos tomándolos de archivo CSV.

Record and Playback

si bien es cierto que nada es grabar y ejecutar, el componente Recorder hace que la edición de las pruebas sea mucho más fácil.



Véase también

Algunas lecturas para entender mejor esto