Have you ever tried test automation? When including static analysis of source code, unit testing, integration testing, end-to-end testing, many developers have experience. But when it comes to end-to-end testing including UI operation, and the question evolves to “have you ever succeeded in test automation”, more developers will answer “No.” We’ve talked with many customers and a large part of them have tried E2E test automation, These developers gave up automation due to the cost of creating / maintaining the test cases.

Why is E2E test automation so costly? One of the biggest points is that the created test cases easily get broken due to various reasons. Messages or design change, test data change, OS version update etc., we encounter many troubles in keeping the tests green. Above all, test failures due to design change are so frequent in actively developed applications, which can discourage test automation engineers. We need testing because there are changes, but the changes themselves break the test. It’s so annoying.

The “self-healing” feature of MagicPod resolves this pain. When you have some design changes in your application and your existing test case cannot find elements you want to operate, MagicPod automatically finds the corresponding element in the new design and continues the testing. After finishing, all you have to do is to accept or reject the element change proposed by MagicPod. Then your test case is applied to the latest design without any other maintenance.

Let’s look into it in detail. Assume you have a simple user registration form on your mobile application. You also have some test cases starting from user registration and they have been working well. 

But they suddenly start to fail at the very beginning due to the registration button’s text change, “Register” to “Register me”.

When you don’t have the self-healing feature, the steps to make them successful are as below.

1. Check the failure reason
2. Fix the test case to use “Register me” button instead of “Register” button
3. Rerun the test case from the beginning 

When you have the self-healing feature, it becomes like

1. Check the self-healing result
2. Accept it

Each self-healing result contains detailed information of how the element is updated, so you can easily judge if it should be accepted.

There are mainly two advantages of this feature. One is that it continues testing after the healing. So you don’t have to rerun the test case after the acceptance. It really saves your time especially when there are many steps after that. If the remaining steps have some problems, we can find the problems earlier thanks to self-healing. The other advantage is that the healing result is applied to all occurrences of the same element.  For example, when you use the registration button in 10 test cases, just one approval will make all of them successful. It also saves your time and keeps consistency of your test cases.

We believe self-healing is indispensable in maintaining automated test cases. We’d appreciate it if you try MagicPod and feel its power.