Friday, July 20, 2012

How not to automate..!


       Whatever you do, do not simply distribute a testing tool among your testers and expect them to automate the test process. Just as you would never automate accounting by giving a program compiler to the accounting department, neither should you attempt to automate testing by just turning a testing tool over to the test group.
   It is important to realize that test automation tools are really just specialized programming languages, and developing an automated test library is a development project requiring commensurate skills.


Automation is more than capture/replay
If you acquired a test tool with the idea that all you have to do is record and playback the tests, you are due for disappointment. Although it is the most commonly recognized technique, capture/replay is not the most successful approach. Selecting an Automation Approach, capture and replay does not result in a test library that is robust, maintainable or transferable as changes occur.


Don’t write a program to test a program!
The other extreme from capture/replay is pure programming. But if you automate your tests by trying to write scripts that anticipate the behavior of the underlying program and provide for each potential response, you will essentially end up developing a mirror version of the application under test! Where will it end? Who tests the tests? Although appealing to some, this strategy is doomed - no one has the time or resources to develop two complete systems.   Ironically, developing an automated test library that provides comprehensive coverage would require more code than exists in the application itself! This is because tests must account for positive, negative, and otherwise invalid cases for each feature or function.


Duplication of effort
The problem is, if you just hand an automation tool out to individual testers and command that they automate their tests, each one of them will address all of these issues - in their own unique and Introduction personal way, of course. This leads to tremendous duplication of effort and can cause conflict when the tests are combined, as they must be.


Automation is more than test execution
So if it isn’t capture/replay and it isn’t pure programming, what is it? Think of it this way. You are going to build an application that automates your testing, which is actually more than just running the tests. You need a complete process and environment for creating and documenting tests, managing and maintaining them, executing them and reporting the results, as well as managing the test environment. Just developing scores of individual tests does not comprise a strategic test automation system.



Need for a framework
Instead, approach the automation of testing just as you would the automation of any application - with an overall framework, and an orderly division of the responsibilities. This framework should make the test environment efficient to develop, manage and maintain. 

Remember, test tools aren’t magic - but, properly implemented, they can work wonders!

Saturday, July 14, 2012

isElementPresent ?

Selenium RC we became quite used to using methods like iSElementPresent and waitForCondition/waitForPageToLoad to deal with Ajax and page loading events. With WebDriver we have to write them ourselves.


There are 4 important things going on here. In order:
  1. Setting implicity_wait to 0 so that WebDriver does not implicitly wait.
  2. Returning True when the element is found.
  3. Catching the NoSuchElementException and returning False when we discover that the element is not present instead of stopping the test with an exception.
  4. Setting implicitly_wait back to 10 after the action is complete so that WebDriver will implicitly wait in future.
Method
 isElementPresent(WebDriver driver,By by)  
 {  
    driver.manage().timeouts().implicitlyWait(0, TimeUnit.SECONDS);  
    try  
    {  
       driver.findElement(by);  
       return true;  
    }  
    catch(Exception e)  
    {  
       return false;  
    }  
    finally  
    {  
       driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);  
     }  
 }  


Regards,
Santosh.

How to write Xpath ?





How to write Xpath?
In Selenium-Rc/WebDriver automation xpath is the one of the way to locate elements on webpage.XPath uses path expressions to select nodes/element in an XML/ HTML document.

How to verify in firebug?
  • Open firebug in firefox/Chrome.
  • Go to console.
  • type : $x("<xpath>").
  • Hit Enter.
  • If it is correct path you can element in that console. If you mouse hover on that, the element will highlight in web page.
Example:


How to write Xpath?
Examples
Facebook signup form
1. Select first name
 //input[@id='firstname]     OR       //input[@name=firstname]   
In this case no need of xpath locator because we can use By.id, By.name,By.cssSelector.
By.id("firstname")    |   By.name("firstname")  | By.cssSelector("[id=firstname]")

2. Selecting first name input using First Name label
 //label[text()='First Name:']/parent::td/following-sibling::td/div/input  
                          or  
      //label[text()='First Name:']/../../td/div/input  
In above example,
parent This keyword helps you to back track to parent node from child node.
following-sibling This keyword helps you to go following-sibling.
preceding-sibling This keyword helps you to go preceding-sibling.
.. This also helps you to go parent node from child node
See below table for more keywords
3. Using contains, starts-with

Select Last Name using contains //label[contains(text(),'Last')]/../../td/div/input
Select Last Name using starts-with //label[starts-with(text(),'Last')]/../../td/div/input

4. Index/position based

5. Some more expressions


If you have any doubts in xpath..Post your html code snippet here I would try to give you solution.


Happy Coding..! 

Regards,
Santosh