Advice for when to automate

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 GeneXus' version 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.

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.