Making software tests more robust

There are a number of tips to know when doing software test automation in general, and with Agilitest in particular to make your tests more robust.

Indeed, when it comes to automated software testing, there is an automation tool, and there is also the SUT (system under test) which has its own behavior, its response times and its peculiarities that will have to be taken into account.

This post covers a set of tips that we recommend you use to make your tests more robust.

About the use of Max / Wait for in a test

Your server is slow to respond : never mind, we will wait 5 more seconds !

We do not recommend doing that, this post will explain why and how to deal with the subject. The proposed technique will allow you to manage all the solutions where a certain latency between the software and Agilitest can occur : waiting for a server response, complex calculation on a Desktop solution...

Object identifiers

Some component frameworks generate identifiers that may only be valid for a given browser session, and relying on these identifiers to perform tests is risky, since it is highly likely that during execution The identifiers have been changed.

In some cases this can still be done using regular expressions.

It is enough to recognize the part of the value of the attribute of the component to be recognized that is always fixed, for example a prefix or suffix, in the following case :


"id = select_4657

To treat this case, the following regular expression applied to the attribute "id" should do :

select_( d{4})

So the number of four digits can vary depending on the executions, but we will always find in a very robust way the component with an id beginning with "select_".

The design of ATS

During the design of Agilitest and the ATS language, we have benefited from several years of experience in market automation solutions, and we aim to overcome a number of shortcomings and/or defects. This involves the implementation of configurations specific to runtime environments: by default, ATS is designed to work correctly in most cases, But it is still possible to change its configuration.

Double property checks

When recovering a value on a composter, Agilitest will double-check the value to ensure that it retrieves accurate and stable information. This ensures that the values we want to control are definitive and those provided by the test, while adding stability and reliability.

The configuration by robot execution

The reliability of a test also depends on its speed or its slowness of execution. Indeed, networks and machine performance can put tests into chess.ATS takes into account the possibility that machine performance impacts the execution of tests. Thus, when it is launched, ATS will recover a configuration file .atsProperties specific to the job it is running on.

This makes it possible to fine-tune runtime environments to the desired context, for example a development software version or a production version may not respond in the same way: With this system there are many more guarantees to always have a regular replay.

Configuration by navigator

The behavior of the test and therefore the result of its execution may also vary depending on the browsers. It is therefore also possible to configure the execution environment according to the browsers used.

Robustness at the center of the issues of our development product

Robustness and maintainability of the tests are at the center of our concerns because we want that the testers focus on what is really important to them. In Agile/Lean jargon, we seek to remove "muda" (waste of time/waste) as soon as we have the opportunity.

Still require support?
Contact support