Over the years Functional Test Automation has come a long way from WinRunner to QTP and until ALM. The tools have evolved to a great extent in terms of enhanced functionality, look and feel and inclusion of support for new technologies, etc. The competition between some market-leading tools like Silk Test, and QTP including freeware communities like Selenium led to a great deal of innovation with versions after versions.
However, what I don’t feel has ever evolved is the precise ‘Definitions’ and distinctions between different kinds of Frameworks. There is a lack of clear understanding or documentation distinguishing between what we call frameworks. The online literature still talks about the same traditional or legacy definitions.
Well, this article is dedicated to the legacy definitions for some of the common Frameworks around QTP as we know them. This is the first post in the series while in the subsequent (coming soon) articles I will share our understanding and definition of Frameworks. So here is the traditional introduction to frameworks with a little preface …
Appreciate Frameworks
Before starting with automation, we should be defining a set of assumptions, rules and concepts that provides a framework within which we create our automation test suite. The framework is a foundation on which the physical structure of potential tests or test suite is based. This foundation itself could be comprised of more than one modular components (libraries or scripts) working together to provide for the test journey through AUT. The logical interactions among these components are again defined by Framework.
Defining a framework before starting an automation project keeps all the automation engineers aligned to common goals and objectives thereby less chance of failures and increased team efficiency. The advantages of laying a framework do not stop at the development phase but rather there are significant gains after the project completion.
A framework-based approach is proven to provide for increased code re-usage, higher portability, scalability to accommodate new tests, and less cost of maintenance. Such an approach also makes the automation robust, reusable, and easy to understand for new resources as well
In this tutorial, we will discuss various framework techniques and scenarios in which using the particular framework is productive. Below described are different types of Test Automation frameworks.
Guidelines for Creating Automation Framework
- Select the tool to be used for test automation. (Tool Evaluation Process)
- Review the AUT and test scope complexity to chart out a breakdown of challenging areas.
- Select the type of automation framework to be implemented based on project complexity and the tool selected.
- Define the automation components needed to be created for framework implementation. These modular components should together form the framework.
- Define driver script to execute tests in batch and control flow of script execution
- Ensure robust error handling is implemented in the framework, which shall be one of the automation components
- Validate coding standards are implemented.
- Ensure high reusability of code in the framework in terms of modular and reusable components, functions, and procedures
Types of Automation Framework
Linear Framework
When we record an application in QTP, operations done on objects are displayed as VB Script statements in expert view. When we run the script, steps recorded in the application are executed as recorded, Hence this is also known as record and play testing. This framework is useful in case the reusability of the scripts is low, and the script is created for the current testing cycle, quickly, and the automation skills of the testers are low
E.g. Linear Framework Code Snippet:
SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Mercury"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
Window("Flight Reservation").Check CheckPoint("Flight Reservation")Â Functional Decomposition Framework
In this framework, test scripts are broken down into functions. Suppose an application requires login into the application, perform some actions on objects, log out, login again, and perform some other action, logout, and so on, In this framework, we divide test into logical groups or functions, i.e. functions for a specific task. For e.g. Functions for Login, logout, and similar other functions. This framework has better reusability as compared to a linear framework, but still cannot be run with multiple sets of data as data is hardcoded in this framework.
E.g. Functional Decomposition Code Snippet:
Call funcLoginApp
Call LoginApp
Public Function funcLoginApp()
SystemUtil.Run "flight4a.exe","","","open"
End Function
Public Function LoginApp()
Dialog("Login").WinEdit("Agent Name:").Set "Mercury"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
End Function Data-Driven Framework
One of the major reasons for doing automation is for regression of applications with different combinations of test data. Test data stored in external files like excel files or database drives the automation by executing scripts with multiple sets of data in a Data-driven framework. This framework helps in executing multiple scenarios with the same scripts using multiple data combinations.
E.g. Data-Driven Framework Code Snippet:
SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("Agent", dtLocalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Pwd", dtLocalSheet)
Dialog("Login").WinButton("OK").Click
Check Flight Reservation Window has loaded Keyword Driven framework
When we record on some application in QTP, recording steps are displayed in Keyword or expert view. Similar to the keyword view, in this framework, we define the item or the object on which we have to perform an operation, which operation to be performed, and any inputs that is required for the object. All this information is stored in a table, and functions/methods are defined for the operations to be performed on an object. Object, action, and argument for the action are maintained in an excel sheet as shown below. The function for each of the actions with required arguments should be defined, and a driver function to loop through the data table and perform action on object should be created.
E.g. Keyword Driven Script Frontend:
Hybrid Framework
This framework uses the best features of various frameworks resulting in a robust and maintainable framework. Features of a hybrid framework include different function libraries with similar sets of functions, object maintenance as shared Object repository and descriptive programming objects, Driver scripts to control the execution of scripts, environment variables to define global configuration, error handling, and recovery scenario, and reporting structure for better reporting of results
Business Process Testing Framework
In this framework, we divide the test scenario into multiple flows and script each of the flows using business process components. Components can be linked together to create test script using the Quality Center. Application Area (where we store business process components) and business process component (where we write scripts in BPT framework) are features of BPT framework. We require Quality Center Access and a license for using BPT.
Advantages and Disadvantages of various types of frameworks
