By Pallavi Sharma

If you are trying to automate your web application using selenium, a few things which you should know before you start the quest. For most of the selenium commands a “target” is required which is laymen terms is the object in your web-application on which you wish to perform a desired action.

Selenium follows a location strategy to locate the element in your application which consists of four modes:

1. Locating by Identifier.

2. Locating by XPath/CSS

3. Locating by DOM

4. Location by CSS

You will find detail description of the above locating techniques on the selenium website which are explained well there [http://seleniumhq.org/]. But what not is explained is when to use what and the negatives of each locating strategy.

1. Locating by Identifier: To locate an element using an identifier means that the element must have either an “ID” attribute or “NAME” attribute which should be unique on that page. You may use “type” or “index” property in combination with these identifiers to help selenium uniquely identify the element.

Selenium is right in expecting that if will find an element uniquely by locating using an identifier. The W3-standards also states that the “ID” attribute has to be provided for all elements and it should be unique. But since the HTML has no inherent check on such slip-ups, most of the developers end up doing so in their web applications while developing forgetting that it has to undergo testing also.

So if you know before hand that “Selenium” is the automation tool which suits your web application scenario the best; ensure your developers haven’t made such mistakes.

2. Locating by XPath: To locate an element using an Xpath, is not a very straightforward solution but it helps immensely when you have to use multiple attributes to help locating an element. Xpath is a powerful way of using any attribute by which you would want the tool to find the element and perform action on it. It is useful mostly in the cases when the developers have used same name, ids across the website and didn’t cared for the W3-standards.

But if you can expect your developers to overlook W3 standards for unique IDs you may very well expect them to give you “unclosed” tags in your application! And if your web application has even a single unclosed tag, Selenium won’t be able to detect the element using the “XPath”.

So if the above is the locating method, you expect to find an element ensure you don’t have unclosed tags in the application.

3. Locating by DOM: The last resort to find an element and weakest one to. It is not advisable to use especially if your website undergoes too many changes. And also if the intention of testing your web site is functional/regression.

4. Locating by CSS: If for initial thoughts you are thinking that what if my web-app doesn’t have CSS will this work, then the answer is “Yes”. This locator type works whether you have CSS or don’t have CSS. It is faster than X-Path, and as stated on the Selenium website, experience users like to use the CSS way of locating an element. This also doesn’t works if the DOM is broken, and also is browser depended, as different browsers have different way of handling CSS.

To summarize the above, it is vital to do a W3 standard check on your website so that you can throw all issues back at your developers to fix, before you jump in to testing your website using Selenium. A good starting point is the, W3-validator [http://validator.w3.org/] available freely online. It clearly list down the issues like duplicate ids, unclosed tags and other slip-ups. Selenium is a powerful tool to use to test your web application across operating systems and browsers but if the DOM is broken than none of the locators will work, coz selenium using the browsers java script engine so the results will also depend on which browser you are using for the test.

It is not mentioned clearly on the website www.seleniumhq.org when to use what locator strategy, and it is kind of overwhelming information why they have provided all such locator categories to the users? Couldn’t there have been a simpler and straight forward way of handling elements using just a single locator type which works under any circumstance. I don’t know the answer to this yet, but maybe will have….

Till the next blog happy testing your sites with Selenium.

By Rajat Singhal

These opinions are strictly my own based on my own observations and experiences with both kinds of software and trying to understand the dynamics at play in each environment. I’m sure others share similar opinions. Also note that these are sweeping generalities and caricatures, but I think provide a good starting model for critiquing both.
The main Gap between Open Source and commercial tools is licensing. Using the Open Source Edition (under the GPL license) obligates you to share your source code without restrictions with the users of your program. Using the GPL also means you may not demand compensation for or limit subsequent re-use and re-distribution of the source code. You need the commercial license if you want to avoid these obligations.

Open source Functional Tools

The reason many users originally try an open source solution (myself included) is price. An open source functional tool will be significantly cheaper than a commercial functional tool. As with many open source programs, because the code is “open,” the opportunities for customization are also greater than they are for a commercial functional tool. Depending on your functional tool needs, there may very well be an existing open source functional tool that will fulfill your requirements.

The arguments against implementing an open source functional tool are numerous, but are generally tied into one key concern: uncertainty. Product support, documentation, and user training are often subject to the whims of volunteer (read: unaccountable) developers. As a result, there is often no brand name or customer service department to offer assurances or assistance in maintaining functional tool stability and security. Enterprise-level workflow management may therefore be difficult to achieve, and product implementation may take considerably longer than with comparable commercial functional tool products.

Commercial Functional Tools

Buying a commercial functional tool offers a number of distinct advantages, not the least of which is commercial support and well-defined service level agreements. A commercial functional tool may already be ready-built for your needs and will likely be faster to implement than an open source functional tool. Documentation and training for commercial functional tool products are usually significantly stronger than for an open source solution. Your average person also associates a certain degree of safety with commercial software as opposed to open source. If you or your client has the resources to purchase and appropriately license a tool, it can often be the safest bet.

Arguments against buying a commercial functional tool come down to one issue: cost. Commercial functional tool license costs can be prohibitively expensive, and customization/integration expenses can send these prices even higher. Commercial functional tools rarely represent a “budget” solution.

On top of that commercial software needs to demonstrate that they have solved a hard problem that no one else has solved or make competitors solutions to problems seem hackish. So the marketing folks will use words like “You want to solve the problem the right way, don’t you?” which often means “The hard way that only we know how to do.” A corollary to that is if a problem is really hard and you have solved it or can convince people you have solved it, make sure everyone knows that and make sure everyone thinks they have the same problem. That actually holds true for both commercial and open source but is generally easier to pull off for commercial software.

Comparison Parameters

Tools => Record and Play Back => Language support => Application support
Watir => Support with WET => Ruby => Web Based Application
Sahi => Inherently Supported => JavaScript => Web Based Application
AutoIT => Inherently Supported => BASIC-like syntax => Windows Application
QTP => Supported => VB Script,Java script => Windows/Web Application
RFT => Supported => Java,HTML,VB.NET => Windows/Web Application

After Thoughts

In the end, I would just like to say that it’s a trade off between how uncertain is the uncertainty of a free Open Source solution with how costly is the cost of a commercial reliable solution. Many companies are trying to bridge the gap between the two by providing software with the reliability and user friendliness of a commercial solution for an open source tool price. Well my team is also working on the same, so keep looking out for my blog people if you are someone needing that Bridge ….