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 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.