Manual Override - Best Practices
What is Manual Override?
Manual Override is a powerful feature that allows you to manually adjust how an element is identified during test automation.
You can override default values or define a custom XPath to more accurately locate or map a specific element.
You can override the component selection by specifying the Text, Resource ID, XPath, Content Description and other element properties.
When to Use Manual Override?
Use Manual Override in the following scenarios:
- Changing Attributes Between Builds: When attributes such as Resource ID or Content Description vary between builds, but no UI change is seen. You no longer need to re-record or insert a new step. Instead, you can simply edit the existing step with one click and override the values.
- Dynamic Elements: When working with dynamic elements where attribute values are not static. Partial matches & indexed targeting can help ensure consistent element mapping.
Refer the attached document for Manual Override Steps in offline edits & in Lab sessions:
https://docs.sofy.ai/mobile-automate/manually-overriding-automated-tests.
Best Practices to Fix failures using override.
Check logs, screenshots, or error messages to understand why the failure occurred.
Identify whether it’s due to changes in the UI, attribute values, timing issues, or test data. |
Identify the changes & override only the changed attributes (e.g., content-desc, resource-id)
Keep overrides minimal and relevant to avoid brittle test cases.
|
Ensure elements are interactable before performing actions. |
Keep notes or comments explaining why a specific override or fix was applied to help future debugging. |
How to fix a Failure using Manual Override?
Scenario 1: Changing Attributes Between Builds:
When attributes such as Text, Class, Resource ID or Content Description etc vary between builds but no UI change is seen. For any UI changes, it is recommended to record & insert the step instead of Manual Override.
Example: In this example, both content description and resource ID changed in a recent build, leading to a failure because the previous element attribute values were no longer found in the XML
Fix: Such scenarios are a good example of when to override attribute values. Instead of running the entire flow again & re-recording a step where there is no UI change but only a minor change in attribute values, we can use manual override & update new values.
Scenario 2: Handling Dynamic Elements:
Dynamic elements can be handled with Customized Xpath using partial match & indexing for duplicate values.
Example: The contact’s name may differ between devices, affecting the content description and leading to test failures.
Fix: Use a customized XPath with a partial match to make the locator more flexible and robust.
Examples of some customized Xpath
- Contains used for dynamic items & partial match: //Classname[contains(@content-desc,’Partial Value’)]
- Defining index for duplicate values: (//Classname[@resource-id=’Value’])[1]
- Use * when the class is inconsistent: //*[@text=’Value’]
