Wednesday, September 8, 2010

Web application Automation testing –Part3 - Page Objects



First Step – Understanding a Page Object

As we all know web page mainly consists of 3 elements

1. Elements which are used for inputs like textbox, checkbox, radio buttons etc.

2. Elements on which actions can be performed like buttons, links, or any clickable objects on webpage

3. Static items on webpage like text or any images etc..

Now most of your test cases are around these elements and their expected functionality on a webpage.

We need to have a mechanism by which we should be able to access all these elements by defining a single object of a webpage and using it to do all the actions as we required.

Here is the thumb rule,

1. All the input elements we will define as properties in which we can use getters and setters

2. All the elements on which we can perform action, we will create a function for it.

3. Static text and Images we don’t have to do anything about it because we can test it anyhow.

Let’s take example of Google Search page


As you can see in a picture, we have elements which can be clicked and in which we can enter the values

Let’s create a page object for it. Please see the code below for it.

using System;

using System.Collections.Generic;

using System.Text;

using OpenQA.Selenium.IE;

using OpenQA.Selenium.Firefox;

using OpenQA.Selenium.Internal;

using OpenQA.Selenium.Chrome;

using OpenQA.Selenium.Remote;

using OpenQA.Selenium;

public class GoogleSearchPage

{

protected IWebDriver browser;

public GoogleSearchPage()

{

browser = new InternetExplorerDriver();

}

public string SearchText

{

get

{

return browser.FindElement(By.Name("q")).Value;

}

set

{

browser.FindElement(By.Name("q")).SendKeys(value);

}

}

public void ClickSeachButton()

{

driver.FindElement(By.Name("btnG")).Click();

}

}

Now whenever we will create a object for GoogleSearchPage we will have a ready property for searching a text and at the same we also defined a function for clicking a button.

Now how defining a function will help instead of directly using a single line code inside it.

When we are defining a function for actions we can define multiple actions to be performed under single function avoiding repetitive steps to go into test script

Lets take example of gmail login. Please see the PageObject Gmail Login

public class GoogleMailPage

{

protected IWebDriver browser;

public GoogleMailPage ()

{

browser = new InternetExplorerDriver();

browser.Url = http://www.gmail.com

}

public string Username

{

get

{ return browser.FindElement(By.Name("Email")).Text;

}

set { browser.FindElement(By.Name("Email")).SendKeys(value); }

}

public string Password

{

get { return browser.FindElement(By.Name("Passwd")).Text; }

set {

browser.FindElement(By.Name("Passwd")).SendKeys(value);

}

}

public void LogIn(string username, string pass)

{

Username=username;

Password = pass;

browser.FindElement(By.Name("signIn")).Submit();

}

public void LogOut()

{

browser.FindElement(By.LinkText("Sign out")).Click();

// m_browser_IE.FindElements("");

}

|}

Now lets say we have to create a test script for login using above code how I will create it

It simple and will involve minimum steps as below

GoogleMailPage Gpage = new GoogleMailPage()

Gpage.Login(“test”,”12345”)

See how simple and clean test script we have prepared.. This is easy to maintain and with less code inside it.

Now you got the concept of PageObject.. if you are clear on it then we will understand the concept of automation library which we will be designing using page object… in next post.

Sunday, September 5, 2010

Web application Automation testing -Part 2 - Approach

In my previous post, we talked about the introduction to “designing a test automation framework”. In this post, I will discuss about the factors that needs to be considered before finalizing test automation frameworks.

Before stepping into phase of test automation, we must be clear on certain facts

1. We cannot really implement 100% automation in the project. There are certain types of testing which we can do more efficiently using manual testers and we don’t really need to invest our time in writing or evaluating scripts for it. Some of the examples can be Usability testing, Extensibility testing etc.

2. Manual tester should be willing to learn some OOPS concept of programming and should be at least aware about concepts of writing a program. You cannot really create efficient scripts with any paid tool also if you are not aware about concepts of programming.

3. Base of any test automation is test cases designed by manual testers. All of your functional test cases should be managed properly in order to execute proper test automation phase.

4. People who are actually participating in test automation framework designing should be clear on what actually they are expecting from a test automation framework.

5. No automation can replace manual testers’ participation in successful delivery of any product development lifecycle.

6. In some applications, some part might have designed using flex or any other platform which might not be supported by tools that I have explained in my previous post. So in order to avoid surprises in between we must be clear about which part and what level automation we are going to achieve in our project.

7. Myth about test automation is that one should not do test automation if record and playback is not available but with the tools I have listed we can design it in a way that we don’t even need record and playback however we will need so background of programming which can be built up among team with few trainings.

8. Collaboration with dev team is important because you might need to ask dev people to make changes in code in order to support some tweaks in test automation e.g. Most of the ajax calls related to dropdown value change in a webpage should be based upon change event rather than click

Above are some of the facts which we should know before starting any test automation framework designing else we might not get what we have expected!!!

Expectation from test automation framework

1. Framework should be robust, flexible and easy to maintain.

2. Framework should be designed in a way so that it can support frequent changes in the requirements

3. It should not add overhead to team for creating new test scripts and maintaining old ones else most of their time will go into modifying and fixing old scripts.

4. It should be adoptable to new tool support if we find any good tools for automation in future

5. It should support strong reporting of scripts failures for analysis

6. It should be integrated with continuous integration framework like cruise control if we have any in our project.

7. It should support data driven approach for test scripts and should have strong exception handling.

8. It should be used by dev team to create their own unit test cases for Web automation testing

9. It should handle complex scenarios like ajax calls

But is it really possible to cover all these expected behavior from a test automation framework??

Let’s see and discuss it in details using a tool Web Driver i.e. selenium 2.0…