Page Object Pattern is a pattern that displays user interface as a class. In addition to user interface, functionality of the page is also described in this class. This provides a bridge between page and test.

Why should it be used?

Here are the main advantages of Page Object Pattern using:

1. Simple and clear tests.

2. Good support of tests, because everything is stored in one place.

3. Easy creation of new tests. In fact, tests can be created by a person not knowing the features of automation tools.

Simple example of using Page Object Pattern and PageFactory in Selenium WebDriver

So we have the page LoginPage shown on the image above.

This page contains the following elements:

1. login field

2. password field

3. button «LoginButton»

And the following functionality:

4. to enter something into login field

5. to enter something into password field

6. to click on the button «LoginButton»

7. to log in to the application

So our class describing LoginPage will look the following way:

public class LoginPage {
final WebDriver driver;
@FindBy(how = How.NAME, using = "login")
private WebElement loginEdit;
@FindBy(how = How.NAME, using = "pass")
private WebElement passwordEdit;
@FindBy(how = How.NAME, using = "button")
private WebElement loginButton;
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void enterLogin(String login) {
loginEdit.clear();
loginEdit.send(login);
}
public void enterPassword(String password) {
loginEdit.clear();
passwordEdit.send(password);
}
public void clickLoginButton() {
loginButton.click();
}
public HomePage login(String login, String password) {
enterLogin(login);
enterPassword(password);
clickLoginButton();
return PageFactory.initElements(driver, HomePage.class);
}
}

Before we’ll examine the above code, let’s look at another HomePage page that we enter after clicking the login button.

This page contains the following elements:

1. Text «Hello!»

2. button «ExitButton»

And the following functionality:

1. Logout

So, our class describing HomePage will look the following way:

public class HomePage {
final WebDriver driver;
@FindBy(how = How.NAME, using = "text")
private WebElement helloText;
@FindBy(how = How.NAME, using = "exit")
private WebElement exitButton;
public HomePage(WebDriver driver) {
this.driver = driver;
}
public void clickExitButton() {
exitButton.click();
}
public LoginPage logout() {
clickExitButton();
return PageFactory.initElements(driver, LoginPage.class);
}
}

Now let’s look at our code:

public class HomePage {

declare a class HomePage

final WebDriver driver;

declare our driver

@FindBy(how = How.NAME, using = "text")
private WebElement helloText;
@FindBy(how = How.NAME, using = "exit")
private WebElement exitButton;

here we use the annotation FindBy for making the WebElement object to know to which element it belongs on web page (for example helloText belongs to the element whose attribute is name = text, and exitButton belongs to the element whose attribute is name = exit)

public HomePage(WebDriver driver) {

…

constructor of our class must take one WebDriver object

public void clickExitButton() {
…
public LoginPage logout() {
…

functionality described above

public LoginPage logout() {
…

this method returns to us the page class to which we go after a successful logout

clickExitButton();

here we describe the main steps of logout

return PageFactory.initElements(driver, HomePage.class);

and so we return the page class initialized with PageFactory.

The same situation is with LoginPage.

It seems to be easy.

How will our test look?

public class LoginLogoutTest extends TestCase {
WebDriver driver;
private static String login = "admin";
private static String pass = "test";
@Before
public void setUp() throws Exception {
driver = new FirefoxDriver();
}
@Test
public void testLoginLogout() throws Exception {
driver.get("yousite.ru");
LoginPage loginPage = PageFactory.initElements(driver, LoginPage.class);
HomePage homePage = loginPage.login(login, pass);
LoginPage loginPageAfterLogout = homePage.logout();
}
@After
public void tearDown() throws Exception {
driver.quit();
}
}

As we see we’ve got a simple and intuitive description of our test:

LoginPage loginPage = PageFactory.initElements(driver, LoginPage.class);
HomePage homePage = loginPage.login(login, pass);
LoginPage loginPageAfterLogout = homePage.logout();

Why use PageFactory?

For example, in the above classes, we used the following description of the elements on the page:

@FindBy(how = How.NAME, using = "text")
private WebElement helloText;

But as we use PageFactory, code can be written as follows:

private WebElement text;

where text will refer to an element with the attribute name = text

What’s going on?

When we initialize the page using PageFactory, then, if annotation FindBy is not specified, PageFactory searches for elements on the page which name or id attributes match the name of WebElement.

As a result, we actually do not have to worry about searching for elements on the page. If the element will appear on the page, so when we turn to it, it will be initialized.

Also, if we know that element is always present on the page, it is best to use the following declaration:

@FindBy(how = How.NAME, using = "text")
@CacheLookup
private WebElement helloText;

If we don’t do it, then every time when we turn to our element, WebDriver will check if the element is present on the page.

What now?

In this article, I gave a simple example of using Page Object Pattern and PageFactory in Selenium WebDriver. If you are interested in this method, then the following links will be helpful for you:

1. http://code.google.com/p/selenium/wiki/PageObjects

2. http://code.google.com/p/selenium/wiki/PageFactory

3. http://code.google.com/p/selenium/wiki/DesignPatterns

If you’d like we apply our experience and knowledge to make your software better, you might be interested in our software testing service.

Software Testing: A History
Which testing role are you playing and why

Automated Testing

Thoughts on Test Automation in Agile
Data Driven Testing Using Selenium (webdriver) in C#

Usability Testing

Usability: “The customer is always right”
Usability Testing Summary Template
Do Not Close This Window (Or Click The Back Button)

Are you interested in software testing service?

Some time ago I published the post “Test plan + templates”. I received many comments reflecting different views, so in this article, I decided to continue the talk about planning.

Firstly, I liked J.Hoffman’s and Hannibal’s comments very much, and at the beginning of the talk, I’d like to mention the main points of their comments.

Jerry Hoffman said:
“…by writing a complete and appropriately detailed test plan, it is possible to better define the anticipated amount of work and anticipate many future problems. Discovering them later during the actual testing is normally more expensive in time and money…
Test Plan like any other test documentation should also be review by all appropriate individuals… At the least it will provide another set of eyes to locate areas you may have missed.
I must also respectfully disagree with the idea that “a simply check list” would even really be sufficient. The lack of detail really does not the author to better organize his/her ideas and does not allow any real third party feedback…”

Anibal (Hannibal) Alarcon said:
“To created and accurated Test Plan we must base our document on Test Requirements for the product. As a Q.A Test Engineer and with over 15 years on my badge obtaining Test Requirements it’s the most difficult task to achieved.
Lots of companies do no believed on Test Requirements and we the Q.A people must be creative and think outside the box to created test plans from verbal instructions…”

You can read the full texts of these comments and other ones there.

Now, let’s consider the problem described by Hannibal. How can we plan if there’s no sufficient information?

In order to deal with this issue, smart people have thought of adaptive planning. Other possible terms are dynamic, flexible, just-in-time, responsive, pliable, progressive, purposeful planning.

Classical planning is being done long before the testing can begin. The system has not been built yet, but everything has already been planned. Then we start tests and see that our plans disagree with the reality. We must update the plans and spend time again.

With adaptive planning we choose a strategy (depending on our current knowledge); and then the planning is being done before each feature is to be tested. During the test process, our notion about the system is changing constantly; also the test plan will be updated and corrected. Adaptive planning can be done at the start of an individual test. We are taking new knowledge from previous tests and changing our plans correspondingly. Thus, we don’t consume excess time and force.

Adaptive planning supposes that we plan as much as we can and when we can. Our plans are based on the available knowledge, time and resources.

Adaptive planning allows avoiding the troubles peculiar to classical planning: attempting to plan in too much details, inflexibility and trying to forecast events too far into the future.

If you’d like we apply our experience and knowledge to make your software better, you might be interested in our software testing service.

10 Commandments of Software Testing
Financial Software Testing – Best Practices
Software Testing: Evolution over the years

Automated Testing

Announcing Selenium 2.19: the Prancing Unicorn release
Ruby Trick Shots
#SFSE Meetup Video: Keeping Selenium Tests 100% Blue
API Software Testing

Usability Testing

Usability Testing Includes Users as Stakeholders
Qualitative or Quantitative Usability Testing?

Are you interested in software testing service?

Decision tables are usually divided into four parts.

Conditions – a list of possible conditions.
Variants of the conditions’ performance – a combination of performance and / or failure of the conditions of this list.
Actions – a list of possible actions.
The need for actions – an indication whether the appropriate action should be performed for each combination of the conditions.
The actions can be simple, but can refer to other decision tables.
By actions execution, a priority can be set (for example: if it is possible to implement several actions by a certain combination of conditions performing, we should specify the priority of these actions in the decision table).
The table’s structure:

Conditions – incoming data.
Actions – outgoing data.
Terms of Service – test cases.

The steps of table constructing
1) To identify / write all the conditions.
2) To calculate the number of possible conditions combinations.
3) To fill in the combinations.
4) To remove excess combinations.
5) To record actions.
Example:
Input: a, b, c.
Output: determine the type of the triangle (equilateral, isosceles, versatile, not a triangle).

The step 1 (to determine the conditions):
Condition 1: a, b, c form a triangle? {Y, N};
Condition 2: a = b? {Y, N};
Condition 3: a = c? {Y, N};
Condition 4: b = c? {Y, N}.

Step 2 (to calculate combinations):
If all conditions are simple ({Y, N}):
The quantity of combinations = 2 * quantity of the conditions;
If the conditions are difficult ({A, B, C, D}):
The number of combinations = VC1 * VC2 * VC3 * VCn
N = 24 = 16

Step 3: (fill in combination)

If you’d like we apply our experience and knowledge to make your software better, you might be interested in our software testing service.

Getting your testing project into orbit!

Don’t Test It

Classic Software Testing Mistakes

Automated Testing

Continuous Performance Monitoring

Exploring Test Automation

Web Accessibility Testing: Do Automatic Testing First

Usability Testing

Website Usability Testing

Remote Usability Testing – What, When, and How?

Are you interested in software testing service?

Self-Reporting Logs

Self-report logs are forms of “pencil-paper” type, in which users fix all actions and thoughts about interaction with application. This method is economical enough as experts are involved only in handling of results, without supervising action of the user in runtime of jobs.

The main disadvantages of this method, as well as other methods that involve independent work of users, are the inability of monitoring and recording their emotional responses to interaction with the application and issue of the adequacy of their reports of what they actually do. Therefore, in this case, the selection of users participating in an experiment becomes fundamental.
For research carrying out, it is necessary to provide examinees with access to an application prototype, the task description, which they should solve at its usage, and the standardized form for registration the users’ actions.
Normally, this technique is used at early stages of planning or development or for detection of the user’s preferences.

Thinking Aloud Protocol

Fixing of thoughts of the user involved in experiment is one of the most popular techniques at an estimation of functionality of application. Ask the user to say aloud all thoughts, feelings and representations which arise in the course of the task decision.
The user is provided with access to tested application or its prototype and given the job, which should be done in the course of its maintenance. User’s task is to carry out the task by simultaneously “sounding” everything that comes to mind concerning the interface. The data is registered in an audio tape or fixed in writing.
Unlike the majority of other methods, this technique allows to estimate immediate responses of the user to interaction with the separate application components, not delayed on time. And if his waiting concerning necessary for the decision of the task operations disperses from the application designer’s decision, probably, it’s necessary to change this decision.
In spite of the fact that the primary goal of technique is clearing up of the user representations, with its help it is possible to implement other purposes, too. For example, terminology, which is used by the user for a designation of these or those elements of the interface, can be used in the design of application.
The method assumes generalization of the data received from several users. There is also a close to this technique method of answers to the questions, using not verbalization of thoughts and emotions, but the directive questions of the experimenter with fixing of answers of the user.
Next time we’ll continue to consider usability testing methods.

If you’d like we apply our experience and knowledge to make your software better, you might be interested in our software testing service.

How To Test Documentation
Truth about test plan document & test case document
The future of testing?
More Time to Test

Automated Testing

Automated Testing Best Practices
Automated UI testing for Android applications with Robotium

Are you interested in software testing service?

With Robolectric you can write tests like this:

@RunWith(RobolectricTestRunner.class)
public class LogoutTest {
private Activity activity;
private Button pressExitButton;
private TextView result;

@Before
public void setUp() throws Exception {
activity = new MyActivity();
activity.onCreate(null);
pressExitButton = (Button) activity.findViewById(R.id.exit_button);
result = (TextView) activity.findViewById(R.id.result);
}

@Test
public void logout() throws Exception {
pressExitButton.performClick();
String resultText = result.getText().toString();
assertThat(resultText, equalTo(“Login Screen”));
}
}
Robolectric makes this possible by intercepting the loading of the Android classes and rewriting the method bodies. Robolectric re-defines Android methods so they return null (or 0, false, etc.), or if provided Robolectric will forward method calls to shadow Android objects giving the Android SDK behavior. Robolectric provides a large number of shadow objects covering much of what a typical application would need to test-drive the business logic and functionality of your application.

Presentation: TDD Android Applications with Robolectric

Robolectric Sample

You can take sample from here

Useful links:

• JavaDoc
• User Guide
• Extending

Are you interested in software testing service?

Screenshots are needed for bug reports, user guides, figures of expected results, etc. Sometimes one screenshot is more useful than long confused description. In this post I gathered methods of screenshot creating which I use in my daily work.

1. Original approach for Windows OS is Print Screen key. Screenshot will be put into the clipboard. If you want to place only a snap of the active window into the clipboard, then press Print Screen + Alt keys.

2. Original approaches for Mac OS are cmd + shift + 3 and cmd + shift + 4. The first one takes a screenshot and saves it on the desktop. The second one takes a snap of selected area and saves it on the desktop. If you press ctrl with these keys combinations, the snap will be put into the clipboard instead of the desktop.

3. PrtScr application is a pretty free program for Windows OS. It supports main features needed for screenshots creating:
- captures full screen, rectangle selection, freehand selection or active window;
- saves capture straight to desktop or to any file, sends it as email, edits, prints or sends to clipboard;
- exports as JPG, BMP, or PNG (transparent or opaque).
You can download PrtScr application from here.

4. Snagit is a commercial application. They’re versions for Windows and Mac OS. It’s a powerful application for screenshots creating, editing, sharing and organizing. The program has a free 30-day trial version which can be downloaded from here

5. Screenshot Plus is a dashboard widget for Mac OS X. The application has freeware license. It can take full screen captures, grab portions of the screen, and even capture windows, desktop icons, and other widgets. Captures may be saved to the clipboard or to the hard drive, or they may be exported to any application directly from the widget. For downloading Screenshot Plus go to here.

And how do you take screenshots?

Are you interested in software testing service?