Monday, July 27, 2015

Guidelines of Developing a Test-Automation framework - PART 1

PART 1:

Importance of Test Automation:
With drastic and continuous reduction in the Product development cycle times, there has been a growing pressure on specifically on the Testing. This is pressing the Testmangers to adopt the automation regioursly now-a-days. More and more new technologies are coming without even notice, it is becoming increasingly difficult to stick to traditional approach of building TestAutomation frameworks. Furthermore, clients requirement of All-In-One framework(which should work for both Mobile and Desktop platform) ís only worsening the situation.

Following is a kind of general approach that to address the above challenges.

Test Automation Framework: As the name suggests, this is a ground on which testers can tests(testcases) without much knowledge on the underlying technology. The groundwork includes various layers to it.

1) Tool layer
2) Wrapper layer
3) Business logic layer
4) Test development layer
5) Utilities layer
6) Test data layer


Lets see the various layers in detailed.

1) Tool layer: Any automation tool available on the market - Selenium, QTP, Ranorex, SeeTest or Appium - which has an inbuilt API to work with the application under test(AUT).
For example, Selenium provides the following to interact with the elements on a web application.

org.selenium.openqa.WebDriver
WebElment
click()
text()..etc

Likewise, all the tools have their own rich set of automation kit to handle various actions on AUT.

2) Wrapper Layer: This is the most significant part of overall architecture of the Automation FW. The level of sophistication provided with this layer would make rest of the development process much smoother. At this stage the Automation FW developer provides the wrapper methods to all those tool specific methods or functions which will be useful to interract with AUT.
In this layer, we normally use lot of Utility functions which are going to be used by the Wrapper functions.

3) Business logic layer: The functions or actions which are specific to the application under test (AUT) will be defined here. This layer makes use of the wrapper layer to define the AUT specific action-automation.

4) Test development layer: Its purely the testscript design section which re-uses the methods/functions defined in the business logic to define the flow of Teststeps.

5) Utilities layer: Report handling methods, Logging functions etc come under the Utilities layer. Any sort of functions or methods that are not related to an application business logic but needed as part of testing..they can included in this section to give support to the Wrapper layer and any other layer based on the need.

5) Test Data layer: This is completely independent of any of the layer. It has functions to handle the activities of working with testdata retrieval from an existing testdata source. It just does not use any of the layer functions. It will only be used by all other layers based on the context.



The advantages of the framework designed based on this guidelines will give lot of scope for maintenance and re-usability of the framework to different needs.
Eg 1: If there is any change in the tool requirement, the simply modifying the Wrapper layer would solve the problem
Eg 2: If there is a change in the application, Business logic layer and Test Developement layers are required to be modified without the need to touch any other layers.
Eg 3: If customer wants a single framework to various platforms(mobile and Desktop and web) with different tools then modifying the Wrapper layer to enhance the existing capabilities would be yet another not-a-bad idea(Though not 100% suggestible)



Below is a sample directory structure which has various folders each containing specific category of files(explained below...)


Sample Test Automation Project directory structure.


Automation Project Root Dir: This is the root folder of the whole project.

Configuration Setup: This folder contains files(config.properties) holding the global data/ static data per the project - Class path, Test data directories path, various other folders paths, IP address, Port, URL etc.

TestData: .xls, .xlsz files containing the various test data

Libraries/Wrapper Functions: This includes the following
a) Wrappers methods for tool specific functions

b) Reporting utility functions (Functions to generate client specific reports)
c) Any other utility functions

Business Logic functions of AUT: This section contains the functions to automate the application under test(AUT) with the help of wrappers created in the above dir.

TestScripts: All the test steps or test management functions are placed here. This include Test suites, Testcase files. Eg(testNG.xml)

Batch Run: This is a sort of optional as it does more or less same function as TestSuite.

Reports: Test summary, Error or defect summary and Test Status etc., all sorts of reports are published to this folder. This module has to be developed as sophisticated as possible to give substantial information on what went wrong to debug the failed scripts.

Resources: This would include the client specific/ styling data for reports- company logos, report styling pics etc.


End of PART 1
Note: This is a draft version.

No comments:

How J2EE components work together in any Container - Spring or Application Server

In a Spring+Jersey+Hibernate RESTful webapplication, we can spot various J2EE components - JTA, JPA, Java Bean Validation, JSON-B API for B...