Hi,
I have lots of automations for the same system (Silverlight) to check/test all the functions of the system, but each new build on server and system re-installed, automations can't find the element and of course tests are not passing, There is a same element to click and expected state and capture time of failure screenshots are the same,
Also when I re-recorded this step and the code and the description are same again ; but old one doesn't work.
How can I fix this?
Thanks,
Deniz
I have lots of automations for the same system (Silverlight) to check/test all the functions of the system, but each new build on server and system re-installed, automations can't find the element and of course tests are not passing, There is a same element to click and expected state and capture time of failure screenshots are the same,
Also when I re-recorded this step and the code and the description are same again ; but old one doesn't work.
How can I fix this?
Thanks,
Deniz
1 Answer, 1 is accepted
0
Hello Deniz,
I am sorry to hear you are experiencing these issues. This is the first time I hear for such an issue from a customer. Please note that when you are recording a test you can change the default find logic for the element in order to make the test more robust. Please check this article for more information on how to proceed with changing the find logic.
One of the best practices in such cases is to identify the elements in your application using automation IDs. No matter what software you use for your test automation, the method in which elements are identified plays a critical role. Small changes to your application can often break the test's find logic causing your test runs to fail. Let's say a couple elements are moved to another location on the page - if IDs are not present, then alternative find logic is used to locate the element. Such find logic includes identification techniques such as Tag Indexes, NodeIndexPath, XPath, and HTMLPath.
I'll use Tag Indexes as my example – if my find logic says locate the tenth <div> tag (DIV:9), and the application changes making the target element now the ninth <div> tag, your script has just been broken – time to drop into maintenance mode.
If you don't have the automation IDs present in your silverlight application you can ask your development team to implement them for you. As long as the IDs are unique, your element repository will not require maintenance at all.
Regards,
Ivaylo
Telerik
I am sorry to hear you are experiencing these issues. This is the first time I hear for such an issue from a customer. Please note that when you are recording a test you can change the default find logic for the element in order to make the test more robust. Please check this article for more information on how to proceed with changing the find logic.
One of the best practices in such cases is to identify the elements in your application using automation IDs. No matter what software you use for your test automation, the method in which elements are identified plays a critical role. Small changes to your application can often break the test's find logic causing your test runs to fail. Let's say a couple elements are moved to another location on the page - if IDs are not present, then alternative find logic is used to locate the element. Such find logic includes identification techniques such as Tag Indexes, NodeIndexPath, XPath, and HTMLPath.
I'll use Tag Indexes as my example – if my find logic says locate the tenth <div> tag (DIV:9), and the application changes making the target element now the ninth <div> tag, your script has just been broken – time to drop into maintenance mode.
If you don't have the automation IDs present in your silverlight application you can ask your development team to implement them for you. As long as the IDs are unique, your element repository will not require maintenance at all.
Regards,
Ivaylo
Telerik