Test maintenance just isn’t fun. If a tester is looking for website bugs to fix, they’re not going to want to instead focus on fixing brittle tests. This is where the magic of self-healing comes in. Ok, it’s technology, not magic, but it feels like that sometimes. After looking at what test maintenance traditionally looks like, we’ll dive into that self-healing and look at exactly what it is so it’s less mystical and more comprehensible. 

Traditional Test Maintenance

A good way to judge the progress of a technology is to compare it to what came before. Before self-healing, the engineers on the QA team had to provide manual maintenance for tests written on automation frameworks. Whenever a test step would fail, they had to check whether it was an actual bug on the web application or just a brittle test.

Tests can break for a number of reasons: last week when talking about Intelligent Object Identification, we mentioned that object-based identification tends only to record one attribute of a button, drop-down, text field, etc. This traditional method means that if that ID or attribute (like an xPath, which wouldn’t be a good choice, or a CSS class selector) changes for any reason, the test won't be able to identify the object anymore. In this case, the tester has to get in and adjust the code, adding the new ID or other attribute to the test step.

Maintenance for image-based can almost be more frustrating. Test breakage can come from something as simple as a button changing color or shifting slightly in placement. Sometimes it's as simple as the framework taking another snapshot of the web app, but if a recorder is in use, the tester has to go back and re-record the steps. Who wants that kind of hassle? 

Still other tools use object repositories. Here, you can maintain a single object in a repository and it will change across all the tests. However, the tester still needs to know what changed and go in and fix it themselves. Separating objects from user journeys through the use of a repository doesn’t give you a very user-centric test (but that’s a story for another post).

The best way to maintain your tests is to make sure they’re authored in the same way. We’ve talked about this before, both in a blog post and a recent podcast. In the end, making sure that your authoring and maintenance are happening in the same place is going to save a lot of time. 

Virtuoso's Self-Healing

With all the (not-so) new-fangled Artificial Intelligence and Machine Learning out there, tests can heal themselves! This comes in part from Intelligent Object Identification. Virtuoso builds a model of the element by taking note of all of the attributes, this way when one of those attributes changes, there are plenty of others to fall back on. Virtuoso then uses an ML-trained algorithm to compare the expected model to the new one that it finds. 

For example, if the object is moved, the xPath ID (of course, choosing this element solely isn’t best practice due to how brittle it is) is going to change, but the CSS class is still there for the test to find. The test then goes through the self-healing process of replacing the out-of-date selector with the new one with 95% accuracy while the test is running so the tester doesn't have to worry about it. 

Virtuoso's self-healing is hint-based: if you're telling Virtuoso to look for a button that says "Add to Cart," that's the first thing it's going to look for, then it will take note of all the selectors (if you have multiple “Add to Cart” buttons, you can give Virtuoso directions, which we talked about in last week’s post). However, if you change the name of the button to "Add Item to Cart," the test won't throw a fit, we promise. The button still performs the same function and has the same ID, so Virtuoso will know that it’s the same one. 

So we’ve cleared up the magic of self-healing and let you have a peek behind the curtain to see what it’s all about. Interested in taking Virtuoso for a spin? Book a demo with us to see the self-healing in action!