Monday, February 22, 2016

First few steps on starting a new UI automation project



Deciding on which tools to use, what kind of architecture to follow, what steps to take could be cumbersome. Hence it is very important to make a check-list for yourself when starting a new automation development project.

1) First step is making the decision of whether an application is ready to be automated or not.
As an automation engineer, have a look at the application, do basic sanity and exploratory testing of the application to understand whether the application is stable enough for automation. Find out if there is any planned big change in the application structure, and if there is, wait till after that change.

2) Understand the need of automation here. The requirements and whether the application even  requires testing enough for putting in the effort of automation.
Get the requirements in place. Ask questions like - Whether it is for the purpose of regression testing?, how much percentage of the application can be automated?, do you need an end-to-end scenario testing of the application?

3) Think ahead, and what all will be required from automation in the future. Plan your automation accordingly. Stay updated on technology, and make sure you are using the latest. Do good research on the tools available, the costs of these and the skill set required for these tools.

4) A thorough POC on which tool to pick up for the application is required. This would include trying to verify, using the different tools, which is the most efficient/ cost effective and fast way of automating your application.
Verify that all the forms/ pages and controls in the application can be identified by the tool and that you are able to perform basic actions on these. Try to automate a small scenario and see if it works. Try this with all your choices of tools and see which one fits your expectations the best. Ensure you pick the right tool.

5) Plan, prepare to work on the skill set required for using the tool you've picked up.

Of course once you are ready to start automating make an elaborate test automation plan, with the purpose of the project, all the requirements, the timelines, the estimates, what all resources required and the risks and slippages that you think may occur.
The first step is always building a great scalable framework for your automation activities if you don't have it in place already.

Saturday, February 20, 2016

Page Object Design Pattern



One of the most widely used and efficient ways to automate an application, be it web, windows, mobile or any other, is following the approach of Page Object design pattern.

A Page Object design ensures that  there is class or a separate module for each page/form which encapsulates all functionalities of that page/form.  This reduces to a great extend scope or need of code repetition of any type.

In this kind of a design, a class A of a page/form A will make sure all the objects present in that page A are defined in this class, all the properties to be accessed from this page are defined in class A and all the actions to be performed in the page , example entering data, clicking on submit, verifying a field etc. are encapsulated only in the class A in the form of methods. Whenever any action needs to be performed on this page or a property needs to be accessed from this page, an object of class A has to be created.

Let's take an example. An application has two screens :

Screen 1 contains :

'UserName' field
'Password' field
'Submit' button

On entering username and password and clicking on submit in Screen 1, the user is navigated to Screen 2.
A page object class for Screen1 would look like :







This is an example of how a simple page object class could normally look like.

Few points to remember about Page object model:

- the actions which expect the navigation to go to another screen return a type of page object class of the other screen. In the example, ClickonSubmit expects to open Screen2 , hence return type is an object of Screen2 class.

- the actions which expect no navigation, but to stay on the same screen, return a type of the same class. In the example, Enterdata expects no change in screen, hence return type is an Screen1 object.

- all actions performed in a page are limited and encapsulated to a single class.

This is just one approach, great and efficient, to follow during automation although not a mandate. Deciding on what kind of a framework to develop, which tool to use, what design patterns to follow also depend on the kind of application being automated and what is required and expected from the automation of it.


Test Automation


Test Automation is a major need for testing a software regressively before bringing any new feature in the software to live,

Test automation ensures a fast and inexpensive approach to quickly testing applications and making sure they are ready to go. It is of course a fact, without mentioning, that automation of the testing will never replace manual testing but it will make life easier especially in cases of regression testing.
This blog is to share views and talk about good standards to follow for test automation.