If you are using Internet Explorer 8 or higher you can press F12 to
open the developer tools. If you are using Firefox you need to install
Firebug then F12 will open Firebug. If you are using Chrome then CTRL-
SHIFT-I will open the developer tools.
Beyond that, the only tool I use is my brain and the W3 standards.
Reading the W3 standards (or any standards documentation, ISO, ANSI,
IEEE, etc.) can be difficult at first. Especially if you have been
learning from books like "Web Design in 21 Days" or "Software Testing
for Dummies." However, the more you read and understand standards
documentation, the easier it gets to read other standards documents.
If generating XPath was easy enough for a piece of software then why
would they pay you to do the work? There are probably a dozen XPath
locators for any given element on a page. Some will work once and need
to be revised on the next release of the application. Some will work
within the design pattern of the application and might never need
updating. There is no way for a piece of software to spot the design
pattern and know which locator will work best. This is what they pay
you to do.
Excessively long XPath is brittle and will need a great deal of
revising from release to release. Extremely short XPath will sometimes
find the wrong element between releases. This leads to a test which
fails unpredictably and can be difficult to debug. Not something you
want in an automation suite. Finding the right balance is your job.
The first time you select a locator it might need revising for the
next release. You need to look at why you selected the first locator
when selecting the revised locator. The second locator should work for
the first release and the second release. When the locator fails, you
need to select a new locator which would have worked on the first
release and all subsequent releases, including the next release. After
a while you should start to see the pattern. The pattern is usually
derived from some design pattern the application is being developed
with. Learn about Design Patterns, it will be extremely helpful in
generating good test automation. If the developers change the tools,
libraries, design patterns, etc. you should expect the locators to
fail. At this point, selecting a locator which works with the next
release but does not work with the previous release makes sense. Major
change in development usually implies major change in test automation.
It would be difficult for a tool to realize when it needs to abandon
Essentially, automation is all about finding elements (locators),
performing actions on them, confirming the expected results (usually
involves more locators). Two thirds of the work is about the locators.
Learning XPath, CSS and DOM will make your job that much easier.
XPath 1.0: http://www.w3.org/TR/xpath/
XPath 2.0: http://www.w3.org/TR/xpath20/
XPath functions: http://www.w3.org/TR/xpath-functions/
CSS 1.0: http://www.w3.org/TR/2008/REC-CSS1-20080411/
CSS 2.0: http://www.w3.org/TR/CSS2/
CSS 3.0: http://www.w3.org/TR/selectors/
When possible, use CSS selectors as they are faster. Some things are
easier to locate using XPath and XQuery (XPath functions). It is
better to have a test run slow and be easy to maintain. So if CSS
selectors are complex and unintuitive you might want to use XPath
I am Masud Parvez. Working as IT Senior Project Manager for RMIT University. Previously I built and run a distributed Test Center. My success was to turn that in to one of the most successful business units of the company.