Table of Contents
Overview of the self-healing function
MagicPod has a "self-healing" function that allows the AI to automatically follow the changes and continue testing when the UI element you want to operate changes, due to design changes or similar. If you know that the UI elements have been changed in advance, you can re-upload the screen capture on the “In case there is a correction to the test target” screen, but it is not realistic to assume that you will grasp all of the changes before running the test each time.
Let us look at an actual case. For example, the button shown in Figure 1 was originally named “Register,” but was renamed to “Register the content.” Although it depends on the implementation of the app, if the only thing that identified this button was the button string, the test would fail as is.
Figure 1 Changing the button name
If you actually run the test, and perform self-healing in relation to the button UI element, the execution test result status will change to the orange “Requires confirmation.”
Figure 2 Batch execution test results
If you click the link and open the test results detail screen, the self-healed content shall be displayed. As it was healed in step 3, and the test did not stop here, and the next steps were run without issue.
Figure 3 Test results details screen
Furthermore, if you click on the "Confirmation Required" message or the orange frame in the list of captures, a pop-up window will appear showing the details of the healing.
Figure 4 Self-healing results detail pop-up window
In this state, the self-healing result is only a "proposal" and the original UI elements have not been changed.
Check the results, and click “Approve” if there are no problems. If you do this, the test result status will change to “Success” and the “UI elements” and capture screens used in the test case shall be replaced with the new ones.
Figure 5 Approval of the results of self-healing
If the changes do not match the actual UI, click "Reject." The test result will change to "Failed" and no changes will be made to the UI elements.
Points to note
- Currently, the self-healing function is only enabled for tests that are run as a batch. Note that this will not work when running a single test from the test case edit screen.
- The self-healing function is a function that provides assistance when an element cannot be found, and does not work if the result of a command to a confirm a found element or screen results in a failure.
- "Confirm that the value of the UI element XX matches the value to register" → The test will fail if the value is registered.
- “Confirm that the title matches MagicPod” → If the title is MAGICPOD, the test will fail.
- The self-healing function will not work when the condition branching is based on whether an element exists or not, or when the result of an element is expected to be "does not exist."
|Command does not operate||
<In case the condition branching is based on whether an element exists or not>
In case the UI element exists
In case the UI element does not exist
In case the UI element is displayed
In case the UI element is hidden
<In case the result of an element is expected to be “does not exist”>
Check that the UI element does not exist
Wait until the UI element no longer exists
Confirm whether the UI element is hiddenWait until the UI element is hidden
|Commands to operate||
Confirm whether the UI element exists
Wait until the UI element exists
Check that the UI element is displayed
Wait until the UI element is displayed(and many other commands)
If the test case in which the self-healing occurs fails in a later step, the self-healing will be considered to have been mistaken, and the self-healing results will be automatically rejected. In practice, however, there may be cases where the success or failure of a healing result has nothing to do with the subsequent test failure, and you want to approve the healing result. In such a case, more warnings may be displayed compared to normal repair results, but you can still approve these by pressing the “Force accept” button.