Table of Contents
- Essentials 1: Test Artefacts Repository
- Essentials 2: Error Handling and Recovery
- Essentials 3: Object Identification Method
- Essentials 4: Test Data Management
- Essentials 5: Result and Error Reporting
- Essentials 6: Function Libraries Repository
As we discussed the types of QTP/UFT frameworks earlier in our post ‘Traditional Framework Definitions‘. In continuation of that, this article talks about the ‘essential components of a typical framework.
Irrespective of the kind of framework you choose, whether it’s Data-Driven, Keyword Driven, or BPT Framework, etc., one must address the following components which are hereby cited hereby as ‘essentials’. These components shall serve as the fundamental building blocks of your framework.
Personally, my choice is always the so-called ‘Hybrid framework’. In such a framework at a lower level, you can create data in external files as in a data-driven approach, and creation of keywords as in keyword driven framework, while keeping Functional decomposition as an ‘Umbrella’ strategy. Now tailor it all together alongside your project requirements and you get a potential ‘Hybrid Framework’. It just gives you all the benefits in one!
Essentials 1: Test Artefacts RepositoryÂ
By test artefacts, we mean scripts, function library, object repository etc. and even including the test cycle results. Of course, using a shared central repository with reasonable versioning makes sense and hence the most obvious choice should be HP Quality Center and if it’s added with a bit of ALM related salt then nothing like it!
Following are some of the upfront benefits of choosing HPQC ALM as your test artefact repository :
Essentials 2: Error Handling and Recovery
There is no doubt that without proper error handling or lack of recovery scenario would land you frequently into debugging your test scripts, test environment or data. You may end up re-running your test cycle or tests multiple times due to interruption caused as a result of such script failures.
In many cases, a lack of error handling may also give false or invalid results as the script may just go over without capturing errors or failures and still marking the scripts as ‘passed’
Hence your script or code should be built with sufficient error handling and recovery scenarios. Error Handling can be implemented using QTP/UFT inbuilt ‘recovery scenario manager‘ or manually through custom scripting in your script of library code.:
Essentials 3: Object Identification Method
This is again one of the most important aspects of any automation framework. This basically means, ‘how your automation tool recognizes or identifies the AUT UI, UI elements/components’ etc.
With QTP/UFT you have the following choices for object identification. Which method you choose does steer your script development and usability aspect of the framework :
Essentials 4: Test Data Management
Test Data provisions and strategy is another important aspect that should be a part of a good framework. With data parameterization, your test data would be kept separate from the code. And this will ensure that the same code can be re-used for different sets of data.
There can be a variety of Test Data sources options such as excel files, database, text files and XML files. But generally, the best one is mostly Excel or CSV:
You should adhere to following considerations and best practices for test data :
Elapsed time in loading test data: ‘Should you load all data globally before triggering any test suite?’ or ‘Should you load test data per-test basis?’ Hence this generally calls for carefully choosing the data source and weighing against the loading strategy. As a case study, in one of the projects, I observed a lot of time spent in loading data for each test individual basis from a database source. Not a good idea due to time spent in connecting/disconnecting from the database over a network!
Essentials 5: Result and Error Reporting
Ideally, a separate Reporting component can be developed which is basically a collection of Library functions and procedures customized for reporting only. Depending upon the project requirements and effort available, this reporting component may generally make use of external databases (MSAccess), excel files or text log files to write the output of the tests. such a provision comes handy when you want to drill down to errors or failures by applying filters on databases or file output.
Avoid implementing reporting into individual scripts directly using reporter.reportevent, WScript.Echo, MsgBox or any such statement, instead you should at least develop a small separate module for such functionality into your function library
On a last note, an HTML based result report generally offers the best presentation and usability. A good framework would generally have such customized HTML based result reporting module.
Essentials 6: Function Libraries Repository
Supporting Libraries is again one of the most fundamental and required part of any good framework.
Below is one such best practices for libraries and scope of libraries that can be maintained:
- Driver Script (Orchestrator): A driver script or as I call it, an ‘orchestrator script’ can be created to control the flow of test script execution. It mainly drives the order of test script or test set execution, calling and loading dependencies, triggering pre-test environment checks etc.
- Initialization Library: Initialization library initialize test execution and loads object repository, environment variables, business and support function libraries, closing open instances of the application and so on. This contains all function for initialization of test execution.
- Common Function libraries: This library should include functions for reporting, error handling, and all support functions like Date/time functions, string manipulation and external file manipulation that are used as support functions by business functions.
- Business Function Libraries: Business Function Libraries includes application-specific functions and works with manipulating objects in the applications. These functions cover the business flows.
