Saturday, May 21, 2016

A Test Automation approach: Object Oriented frameworks - Part-I [ Introduction ]

B.J Rollison had recently posted about the programming paradigms in test automation. This inspired me to write-up some of the work my team has been doing in automation. My team has been working on a rather "non-traditional" approach on test automation of an product. I'm terming this as "non-traditional" as I've not seen this approach being discussed test automation community and forum. There's been a lot of discussions on key word driven and the much widely accepted data-driven approaches.

For the lack of a better terminology I'm terming this approach as "Object Oriented approach" in test automation. Considering the elegance of this approach, I'm sure this approach has been practiced by testing teams but just that its not been discussed in the testing community and forum.

The "Object Oriented approach" considers the system under test as single object or a series object depending upon the complexity of the application and business functionality. The user action performed on the system are considered as methods/functions of these object. This approach also makes a clear distinction between the Test automation framework and the test suites that consumes this framework. The code that implements the encapsulation of the application into the methods and classes are part of the framework. Test Suites instantiates the classes and invokes the methods of these classes to simulate specific sequence of user actions performed by this application.

To explain further, I'll summarize the project we've been working on. This is a business analytics application performing complex statistical analysis on a data warehouse and publishing the results. At a very high level, users create projects. These projects create data filters based on complex queries defined by users. There are up to 16 different types of data filters that are supported and up to 12 types of statistical analysis. Considering the data warehouse scenario, the underlying data undergoes periodic updates and the application requires to handle historic as well as current data conditions.

A traditional automation approach to script the screen level user actions would have to take into approach the innumerable combinations. Automating the screen level entities would have been a maintainance nightmare considering that the application GUI changes based on an agile development methodology.

The approach taken by us was to bifurcate the test automation development into two distinct entities, framework development and test suite development. The framework will provide the classes and methods and the test suites will strictly use these classes and methods for test development. For example, in our approach the framework provide classes and methods such as Project.create(...), Project.edit(...), Project.delete(...), Filter.create(...), Analysis.create(...), Analysis.verify(...), Filter.edit(...), Filter.delete(...), Application.close(...) etc. The Test suite strictly uses these classes and methods for the test development.

I'll explain further about the design philosophy, advantages and disadvantages of this approach in my next post.


Dhanasekar said...

This kind of approach leads itself into a separate development project.It is very difficult to convince the management that, automation by itself a separate project.In my experience many people thinks that if you buy a tool you can automate whole application over night(thanks to marketing people of the tool vendor).Until you proof them the ROI from these kind of approach(OOPS or other robust framework), it is difficult to get time and resource.But of late these kind of approaches are coming up,the cat and mouse race is still going on
Another issue is resource,many manual testers don't show interest in coding,if some one is interested in coding he wants to code in popular technology not in automation tool.

Rajesh Kazhankodath said...

You are right in terms of tool usage and managements perceptions of ROI is concerned. In my experience any kind of automation without a framework is going to hit a roadblock mainly because of maintainability.
My suggestion on creation of frameworks will be to take a 'just enough' approach. When automating, start with creating a framework that solves your immediate automation needs so that you are on top of the ROI. As more and more automation tests needs to be automated, expand on the framework on an incremental manner.

Dhanasekar said...

I never start automating an application without right framework in place.But my doubts is about the time and resource spent on the.Instead you may opt for a keyword driven framework which can be application independent.
"This means that a automation framework developed with the object oriented approach can never be a generic one, it always has to be specific to the product you are automating. The object oriented approach also assumes the test developer has a sound understanding of object oriented concepts and the programming language." by you in your subsequent post degrades your ROI.I have half baked idea on similar approach but never attempted practically.Since you have implemented this I am putting all my negative thoughts,so I might get clarified on them :)

Rajesh Kazhankodath said...

You queries are valid. Thanks for raising it. The OO framework is never designed as a generic one. The framework in fact should mimic the functionalities of your product that is being automated. This framework will suite only those projects that has a long term perspective on ROI and medium to large size projects. The framework developer should have a strong OOAD fundamentals for success of this approach. Test developers used the APIs of the framework, so OOAD skill is relatively less important, but they have to have programming skills.
If you'd need to show immidiate ROI, the approach should still work provided you focus on developing the framework only to the specifc areas you're interested in automation. But in reality the OO approach will pay dividents only in long run when you pass through several releases of the product.

Dhanasekar said...

It is a very difficult in service based industry where you run behind the client.I like to give one example where I was "forced" to do automation for a module which is supposed to be one time development module,because the client was promised with automation :).
So here more application independent framework comes in handy that can be used in various projects.It would be great if you can write on, at least scope of moving this to a generic one from where we can build upon it.

Anonymous said...

Genial dispatch and this enter helped me alot in my college assignement. Gratefulness you as your information.

Rahul Verma said...

Hi Rajesh,

It's very important to make the distinction that you made. I've developed an OOTAF for my team which consists of multiple components which have a specific purpose to serve e.g. web interface, product specific modules, general test modules, tests etc.

OOP rocks! :-)

Dhanasekar is talking of a context which is faced by a lot of testers in the services industry. In such context, if a free/commercial framework of this nature is made available it works, developing one rarely gets permission from the management. There would be exceptions (and I am happy for them), but I have heard these concerns from many testers.


Creative Commons License
The Elusive Bug by Rajesh Kazhankodath is licensed under a Creative Commons Attribution-Share Alike 2.5 India License.