Difference between revisions of "Beneficios de GXtest"

From GXtest Wiki
Jump to: navigation, search
(Específico para GeneXus)
(Beneficios del testing)
Line 4: Line 4:
 
== Beneficios del testing ==
 
== Beneficios del testing ==
 
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.
 
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.
 
''' buscar referencias '''
 
  
 
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 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.
  
 
Recordamos sus principales ventajas, que lo hace único para la Comunidad GeneXus:
 
Recordamos sus principales ventajas, que lo hace único para la Comunidad GeneXus:
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.
+
* 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.
No hay que ser programador para crear los casos de prueba, cualquier analista funcional puede crear los mismos con total independencia tecnológica.  
+
* No hay que ser programador para crear los casos de prueba, cualquier analista funcional puede crear los mismos con total independencia tecnológica.
 
+
  
 
== Específico para GeneXus ==
 
== Específico para GeneXus ==

Revision as of 20:36, 9 March 2010


Contents

Beneficios del testing

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.

Recordamos sus principales ventajas, que lo hace único para la Comunidad GeneXus:

  • 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.
  • No hay que ser programador para crear los casos de prueba, cualquier analista funcional puede crear los mismos con total independencia tecnológica.

Específico para GeneXus

Mantenimiento

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

está más asociado al modelo de desarrollo que si estuviera asociado al html que genera Genexus.


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.

Data-Driven Testing

no todas las herramientas permiten hacer esto en forma sencilla


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.


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