Creating maintenance friendly modules in Tosca


In Tosca, modules are created by scanning the Application Under Test (AUT), so that all needed objects on screen (e.g. textboxes, links, tables, buttons, etc.) are added to the module. The module can then be added to a test case so it can be executed. This method already ensures that any maintenance will be done in one place only, because a certain module can be used in many test cases, but any changes to the module is automatically applied to all test cases where the module is used.

However, the way modules are created can still be improved to ensure that maintenance is needed even less and when it is needed that it can be easier to do. In this article I will explain why this is important and how to achieve this.

Why is maintainability important?

The number one key success factor for test automation is the long term maintainability. I have seen many projects where test automation is started with real enthusiasm and a nice set of test cases is created. But when the AUT changes, these changes are not subsequently changed in the test cases, resulting in failing test cases. When this cycle repeats itself over and over again, the set of test cases is slowly dying and ends up unused on the shelf, simply because executing all the brittle, failing test cases take more time than manually executing them.

This becomes even more of a problem when test cases are added to the CI/CD pipeline, because a failing test case due to forgotten or ignored maintenance will now cause the build of the application to fail. If this happens multiple times, the test cases will be removed from the CI/CD pipeline, because no one wants these false positives causing disturbances in the build process.

The reasons why this maintenance is not done or not completely done are different. It can be that there is no time allocated for this maintenance or that the test automation specialists are gone elsewhere after setting up the testset, without properly handing over the right knowledge.

Another reason can be that the way the objects are recognized by the test tool are not maintenance friendly, so any change in the application will result in a failure.

How to improve maintainability in Tosca

With Tosca, objects like text fields, buttons and links are scanned with the XScan tool and added to modules. This in itself is already very maintenance friendly, because the idea is that any object is only added once to a certain module and the module is then reused multiple times in test cases. This way any change to an object, like a new class or ID, only results in one change in a module, instead of multiple changes in many test cases.

Normally, when an object is scanned with XScan, you must make sure that the object is unique by selecting a combination of properties. But an unique module attribute doesn’t mean it is also maintenance friendly. I have three rules I always apply when scanning objects:

  1. A module attribute has a meaningful name
  2. The chosen properties are as much as needed, but as few as possible
  3. Alternative strategies are chosen by applying context

Let’s look into each of these rules in more detail and explain what they are and why they are so important.

1. A module attribute has a meaningful name

This one seems obvious, but a proper, meaningful name for a module attribute can be a life saver later on. So when a button “Save customer” is scanned, the name it is been given is sometimes a more technical name which is found by Tosca while scanning the properties, it can for instance result in a name like “saveBtn”.

But later on it is unclear which button this was exactly. Of course, it is possible to check this with a rescan, but if you or someone else cannot find the button “Save customer” easily, they might scan it again and you end up with duplicate objects. So if a button is called “Save customer” in the application, make sure it is also called “Save customer” in the module.

2. The chosen properties are as much as needed, but as few as possible

An object must have a set of chosen properties which make the object unique on the page. It is important to chose the right properties to make the object unique, but also as few as possible. Every property added increases the chance of maintenance later. So if an object can be recognized by only the ID property, then only use this property and nothing else.

Also use wildcards when possible. Suppose an object can be recognized by the property Class and the value is button button-default button-save disabled-style. Using a wildcard like *button-save* also makes the object unique, but it ensures that any change later in any of the other classes doesn’t have influence on the scanned button.

3. Alternative strategies are chosen by applying context

When it is not possible to scan an object by only using its properties, then one of the other strategies can be used: by index, by anchor, by descoping. There is no fixed order in applying these alternative strategies, because it very much depends on the context. For example, using the by index strategy is fine when an object has an index of 1 of 1 or 1 of 2, but it is not useful when it is 7 of 13.

The by anchor strategy is useful when the anchor is in close proximity of the object you are scanning, but if this proximity is large, then the chance of maintenance later increases. In that case using the by index strategy might be better. The by descoping strategy (where you also scan a parent of the object, so the scope of the chosen properties only applies to within the paren instead of the whole page) is really useful, because it makes it really explicit on which other object you are relying compared to the by anchor strategy.

So chosing the right alternative strategy can make a difference and should be chosen carefully.

Take your time

Although it seems this is all a bit overkill, I am convinced that every minute spent extra while scanning an object with XScan to make considerate decisions about what strategy to use, will save several hours of maintenance effort in the long term. Simply because when applying these rules, maintenance is needed less frequently and if it is needed, the right modules are found easier because they have a meaningful name.