Difference between revisions of "Advice for when to automate"

From GXtest Wiki
Jump to: navigation, search
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Idiomas
 +
| ¿Por qué Automatizar?
 +
| Why should I include automation?
 +
}}
 
[[category: En-Testing]]
 
[[category: En-Testing]]
  
 
We are working to translate this page.
 
We are working to translate this page.
 
  
  
Line 8: Line 11:
  
  
 +
== Why should I automate my tests? ==
 +
 +
* Through automation we manage to increase the coverage of our testing, thus, increasing the quality of our product
 +
* Decrease the total amount of time to market, reducing the time employed in testing.
 +
* Early errors detection provides the development team with the insight required to work upon its resolution. Additionally, it is much easier for a developer correcting a defect which has recently been introduced in the code, as opposed to troubleshooting something which was introduced several months ago.
 +
* Costs reduction (through the automation of repetitive tests, thus, granting a bigger time frame for both the design and execution of tests)
 +
* Encourage the team for testing more often, making use of their creativity, leaving repetitive and boring tasks to a robot. The QA team may employ more time to testing new features, whilst the automation tests are running verifying the health of the build. Besides, more time may also be employed for automating more tests, in order to increase the size of the regression suite.
 +
* Having the possibility of testing simultaneously, unattended and across different platforms. More often than not, we come across with a situation which urges us for having automation, for instance, provided we want to run each and every test upon a crossed browser environment, with multiple generators (Java, .Net) and Databases (MSSQL, Oracle, etc.).
  
 +
== What's the main differential in GXtest? ==
  
 +
The main advantage in GXtest is that it quickly adapts test cases to the changes conducted in the application. Though the conventional approach, should large amounts of test cases be automated (because we acknowledge its potential), with every build the maintenance of the test cases turns into a VERY expensive task, making the cost larger than the return of investment. With the traditional tools, by simply changing the name in a control its automated actions will cease to work properly. We may stumble upon the very same problem in the event that either the GeneXus' version or the generator changes. Let's ponder about it for a moment, the name is changed from an attribute in a widely employed transaction, or the version in Genexus was updated and all of our test cases broke thereafter. At that point, the drive and motivation for maintaining the test cases is lost due to the cost required for refactoring them. With GXtest you may easily keep the traceability between the application and your tests in a simple fashion.
  
== ¿Por qué automatizar las pruebas? ==
+
GXtest's main advantage relies in its flexibility for adapting test cases to changes in the application. Technically speaking, the automation strategy is linked to the KB as opposed to the generated HTML. Since GeneXus permits conducting changes in a simple fashion and generate the application, it wouldn't be appropriate having testing as an impediment for improvements.
* Automatizar las pruebas ayudan a aumentar la calidad del producto (aumentando la cobertura del testing)
+
* Disminunir el tiempo de salida al mercado, reduciendo el tiempo insumido en testing.
+
* Detectar los errores antes permiten a los desarrolladores corregir antes el error introducido. Para el desarrollador es más fácil corregir algo que “rompió” ayer a algo que rompió hace unos meses.
+
* Reducir costos (permitiendo automatizar parte de las pruebas y dejando el testing manual para otras más artesanales)
+
* Animar al grupo de testing a testear más seguido, aplicando más su creatividad, dejando de lado las tareas rutinarias y aburridas. El equipo de testing se puede dedicar más a testear las nuevas funcionalidades, mientras que lo que está automatizado lo puede dar por sentado que se está verificando. Además, puede dedicar tiempo a automatizar más pruebas, para hacer crecer al conjunto de pruebas de regresión y permitir verificar más casos para las próximas liberaciones del sistema.
+
* Tener la capidad de testear en paralelo, en forma desatendida y en distintas plataformas.  Por ejemplo, hay veces que es totalmente inviable no tener automatización, si cada prueba se tiene que ejecutar sobre Internet Explorer, Firefox, Chrome, y/o en los distintos generadores (Java, .NET), y en distintas bases de datos (SQL Server, Oracle, etc.).
+
  
== ¿Cuál es el diferencial de GXtest? ==
+
Through a more traditional approach, the effort needed for both building a test case (learning a scripting language) and maintaining them is very demanding. Many a times, because the initial investment proves costly, companies make up their minds for either giving up or not taking up automation at all.  
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.  
+
  
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.
+
On the other hand, GXtest provides a simple approach to the creation of test cases with a record and playback feature, a better understanding the test cases through an abstract model, easily vary the data input with a data-driven strategy, and last yet not least, easily maintaining them as the KB changes. Among its functionalities, there is that of linking the test objects to elements from the KB in GeneXus, and since it is specifically addressed to automating applications created in GeneXus the associations are not lost.
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.
+
Unlike most of automation tools, GXtest is based upon a Model Based Testing approach. Models are much simpler to understand and maintain as opposed to code. Through abstract models we can obtain concrete test cases we can run.

Latest revision as of 14:26, 28 March 2014

Spanish.gif
English.gif
link= {{{3}}}

We are working to translate this page.


We suggest to read this edition of of this magazine Testing Experience - the magazine for professional testers, exclusively dedicated to test automation, its advantages and disadvantages.


Why should I automate my tests?

  • Through automation we manage to increase the coverage of our testing, thus, increasing the quality of our product
  • Decrease the total amount of time to market, reducing the time employed in testing.
  • Early errors detection provides the development team with the insight required to work upon its resolution. Additionally, it is much easier for a developer correcting a defect which has recently been introduced in the code, as opposed to troubleshooting something which was introduced several months ago.
  • Costs reduction (through the automation of repetitive tests, thus, granting a bigger time frame for both the design and execution of tests)
  • Encourage the team for testing more often, making use of their creativity, leaving repetitive and boring tasks to a robot. The QA team may employ more time to testing new features, whilst the automation tests are running verifying the health of the build. Besides, more time may also be employed for automating more tests, in order to increase the size of the regression suite.
  • Having the possibility of testing simultaneously, unattended and across different platforms. More often than not, we come across with a situation which urges us for having automation, for instance, provided we want to run each and every test upon a crossed browser environment, with multiple generators (Java, .Net) and Databases (MSSQL, Oracle, etc.).

What's the main differential in GXtest?

The main advantage in GXtest is that it quickly adapts test cases to the changes conducted in the application. Though the conventional approach, should large amounts of test cases be automated (because we acknowledge its potential), with every build the maintenance of the test cases turns into a VERY expensive task, making the cost larger than the return of investment. With the traditional tools, by simply changing the name in a control its automated actions will cease to work properly. We may stumble upon the very same problem in the event that either the GeneXus' version or the generator changes. Let's ponder about it for a moment, the name is changed from an attribute in a widely employed transaction, or the version in Genexus was updated and all of our test cases broke thereafter. At that point, the drive and motivation for maintaining the test cases is lost due to the cost required for refactoring them. With GXtest you may easily keep the traceability between the application and your tests in a simple fashion.

GXtest's main advantage relies in its flexibility for adapting test cases to changes in the application. Technically speaking, the automation strategy is linked to the KB as opposed to the generated HTML. Since GeneXus permits conducting changes in a simple fashion and generate the application, it wouldn't be appropriate having testing as an impediment for improvements.

Through a more traditional approach, the effort needed for both building a test case (learning a scripting language) and maintaining them is very demanding. Many a times, because the initial investment proves costly, companies make up their minds for either giving up or not taking up automation at all.

On the other hand, GXtest provides a simple approach to the creation of test cases with a record and playback feature, a better understanding the test cases through an abstract model, easily vary the data input with a data-driven strategy, and last yet not least, easily maintaining them as the KB changes. Among its functionalities, there is that of linking the test objects to elements from the KB in GeneXus, and since it is specifically addressed to automating applications created in GeneXus the associations are not lost.

Unlike most of automation tools, GXtest is based upon a Model Based Testing approach. Models are much simpler to understand and maintain as opposed to code. Through abstract models we can obtain concrete test cases we can run.