Best Practices: Element Identification with ID and AutomationID

As a QA professional, it’s important to get involved with the development team early on in the process. This article will discuss just one of the many benefits in doing so – coding standards and the use of ID’s for enhanced team productivity. Require this up front and you can significantly cut back test case maintenance.

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 ID’s 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.

Stop the madness.

Ask your development team to implement ID’s for your dynamic HTML applications or Automation ID’s for your Silverlight applications. As long as the ID’s are unique, your element repository will not require maintenance when changes are made to your application.

Our Automated Testing Tools do an amazing job at automatically identifying elements for you – this saves countless hours and allows you to continue the expansion of your regression suite while keeping your project on schedule. Why not take this to the next level by implementing ID’s as a coding standard and substantially reducing your test case maintenance time.

Silverlight Users – read more on the AutomationProperties.AutomationID Attached Property

Dynamic HTML Testers – read more on the Element ID Attribute