Automation Framework Overview & Approach

Automation Framework Overview & Approach


1 Introduction

The purpose of this document is to provide a broader view of technical specification for the automation approach and then overview of the Automation Framework. It will define various functional aspects for automation approach and will also explain framework’s technical its purpose, approach, model, flow, scope and context as well as its components.

It is a technical deliverable and is produced by the Automation Engineer {Expert} and guide to the design of the automation framework. It is used by automation team even normal tester to automate test cases.

 

2 From Functional and Planning Aspect

 2.1  Automation Candidate     

Automation Candidate is a good candidate for automation as No major upgrades planned in near future, Application is not expected to be retired or replaced in the near future, Consistent datasets can be used and application is stable.

 2.2 What to Automate as first deliverable

            Modular approach will be followed and team has already divided the whole application into   different modules for e.g. Admin, KYC and others and with in with in each module test cases are divided into high, medium and low priority test cases. In first take we will automate high  priority test cases of all modules.

2.3 Test Automation Planning

            Keeping expertise level of team and need of developing automation framework from very  scratch in mind tentative delivery dates for different modules are already defined. It is based on the iterative model and dates can be revisited.

           

2.4 Automation Environment

            Dev team had been agreed and already provided separate automation environment. As in     separate environment the data elements would be used only by IDC test team and not by any other users. Also chances of automated tests failing due to data not found/data state changed in database would be minimal as pre-defined data sets which exist in separate test environment would be used in automation scripts.

            Data elements are considered as a pre-requisite before running the automated test scripts.

2.5 Execution Plan for Scripts

       Execution Plan for the automation scripts that how automation scripts will be executed what can be the frequency. As of now from   perspective whenever release will come            automation team run automation scripts prerequisite is that all sufficient execution and debug time  will be provided and all the data sets and environmental specific issues are in place.

     

2.6 Maintenance of Automation Scripts

Maintenance provides the approach for maintaining the scripts and datasheets. It starts with identifying components to be changed as a result of any modifications to the Application Under Test (AUT). The application change should be Minimal to be considered under this phase. If the application has major changes it should be considered as a separate project with the entire cycle. The standard approach for the modification, versioning as well as documentation is provided

3.       Automation Framework

  3.1 Automation Framework Objective/Purpose

·         To help test- scripting without knowing much details of its internal working.

·         Provide the building block for future Web automation

·         To reduce maintenance overheads as application changes.

·         Framework will be design in such a manner that it will incorporate the some changes in the application.

·         Framework is design to provide a certain level of decoupling between the framework and script and various component of within framework to provide a kind of abstraction to the normal tester or automation engineer.

       

3.2 Some of the key attributes of   automation framework of the framework that is    being developed

       

Environmental Specific Data - Functions to pick all environmental specific data from excel file     so that tests can be run on different environments. Each test script takes input from a data pool. Thus, different environments can be tested by merely changing the data pool values. This also provides a way to extensively test all the various permutations combinations of the application in terms of test data and environment.

Reporting mechanism Friendly to Higher Management  Automation Framework is  designed in a such a way that reporting is done in excel with proper error logging and with user friendly colour scheme for Pass and Fail test cases so that can be well interpret by higher management.

Execution Plan Driver script functions to pick from the excel itself that what test case needs to run and what need not to run according to their merit. With this approach tester can run any of the different tests according to the needs of business e.g. acceptance, regression.

Recovery Scenarios  the beauty of the Frame work that it is designed in such a way that while execution if any test fails at any step frame work will call Base State function which will take care that application is in Base state i.e. from where new test case can be run smoothly. Also just to a double check at the start of execution of new test case it ensures that application is in base state

Error Handling  For error handling and to make sure that when ever any test case fails at any step then in result file proper user friendly message will be logged with which user can interpret that at what step test case is failed and what is the reason of that.

Wrappers for different objects- Automation expert will write wrappers/common functions for all the different objects and classes or here we put all the common functions for different object so that can even normal tester can be used by just passing object’s name and code looks clean.

Project Based Libraries – In Project based libraries we put functions which are common to independent of any module any commonly performed task designed as a function and included in the library to be used in the test scripts. For e.g.

Module Based Library - In module based library functions which are specific to modules.

              

 3.3 Description of the working of the framework in a nutshell:

            Pre requisite Automation candidate is defined and automation engineer knows the flow of test     case.  

Creation of Scripts

·         Each test case will be implemented as different function and there will be an action driver script which will drive them. Global functions with proper documentation will be written by automation expert so that tester can do scripting with help of those functions.

·         For each step will be written in a if statement so that test case will not proceed after any of the steps failed and proper logging of error in result file and recovery scenario will be called for smooth flow of next test case done is errors Standard recovery scenarios and With this framework we can control Execution Plan from the xls itself mark the test case in excel itself which need to run. Open the plan file for the functionality which needs to run Test Driver loads the corresponding test script that contains the test scripts to be executed.

Running of Scripts

·         As part of execution first function pick all the environmental data from the xls file and then global variables set according to that where we can choose different servers and browsers and other environment specific details.

·         With this framework we can control Execution Plan from the xls itself mark the test case in excel itself which need to run. Open the plan file for the functionality which needs to run Test Driver loads the corresponding test script that contains the test scripts to be executed.

·         The test data is picked up from the corresponding xls file and executed by invoking appropriate function in the Action Library.

·         After execution, the error log and / or test reports are generated based on the execution result with appropriate colour.

4. Version Control

Till now Version Control is not in place how ever Win CVS can be used as a version Control  for Framework and Script file. All the relevant documents related to this project will be maintained thru Win CVS.  All the low level folder structure in CVS server will be created by Automation team.

5. Naming Conventions

As of now we are using Application name and then module name then test case name as              naming convention for automation scripts proper guidelines yet to be established.

For e.g.  _ADMIN_CreatePermission

6. Framework Model

Framework can be divided into following 3 parts that makes it scalable, extensible &           maintainable:

QTP scripts - Used to read test script and data, start up script to invoke automation suite, interact with application under test (AUT) and retrieve output from the application.

VBScript - File & error handling, logging test result and verification and validation of test conditions etc.

Test scripts & test data in excel files - The excel sheet containing keyword and data is interpreted at runtime and the actions and business actions gets triggered.

7. Framework Architecture

Core Library/Product Specific function Library: Main purpose of using the Core Library/Product Specific function Library is to minimize the complexity of Script file and proper management of Input Data.

Data Table/Test Data Management: All the Input data required to test the application will be managed in external xls files. Data is managed according to the objects, environmental specific data test case objective data.

Script file: Script file will contains the call to various functions in vbs file and each function is associated to one test case. To maintain the high level of decoupling between the script file and Core Library/Product Specific function Library, parameter should be passed to the function from script file only as it will avoid the frequent changes in the Core Library/Product Specific function Library and it will also improve the readability and maintainability of Script file.