Self-healing is a powerful capability to address run-time element identification issues associated with the dynamic nature of application screens, ongoing updates to application UI, user errors in picking attributes for the Element definition, etc.
ACCELQ takes a comprehensive approach to self-healing by bringing all facets of the application change cycle to work cohesively. Element Identification becomes pretty transparent and contextual to the Automation developer.
Turning on self-healing
By default, self-healing is turned ON for all your test runs. In case it is desired to turn off the self-healing, you may do so from the Run modal. This preference is cached for the user and is applied for all future runs.
Self-Healing analysis in the test report
ACCELQ brings a rich visual interface to display and analyze the self-healing activity. Users can determine the source of element flakiness and gain an understanding of the application's change behavior.
Self-healing is not exercised for certain statements in your test logic, where the presence of the element on the screen is contextually doubtful. Examples include where the test logic is trying to wait until an element disappears or verifying that a certain element does not exist on the screen etc. In these cases, it is clearly indicated in the report that self-healing was not exercised.
ACCELQ calibrates the self-healing data continually from various test runs that you perform in your Project. At times, when it is helpful to apply a project-wide calibration, you may be prompted to do so at the time of login.
This operation may take up to a few minutes based on the size of your Project.