Hybrid Test Automation FrameworksImplementation using QTPPallavi Patwa"When developing our test strategy, we must minimize the impact caused by changes inthe applications we are testing, and changes in the tools we use to test them."--Carl J. NagleAbstract:Various white papers have been published on Test Automation framework however howto implement the framework is the puzzle often faced by Test Automation Developer.This article provides overview of how the hybrid test automation framework can byimplemented using QTP with example.Need for Automation Framework With the onset and demand for rapidly developed and daily deployed build, testautomation is crucial. Test Automation is kind of development activity. And for the most part, testershave been testers, not programmers. To have faster cycle time for development of test automation with less expertise,use of application-independent test automation framework becomes inevitable.Automation Frameworks Various automation frameworks are available viz Data Driven Automation Frameworks Keyword Driven Automation Framework Modular Framework Hybrid Test Automation (or, "All of the Above")Implementation of Hybrid Test Automation framework using QTP is discussed in thisarticle
Hybrid Test Automation Framework ArchitectureDiagram 1Let us start with Intermediate tables which are based on keyword or test driven approach.Here the entire process is data driven including functionality. The keyword controls theprocessing.Spreadsheet has been used as a mean for Intermediate data table. The records in datatable contain the keywords that describe the actions we want to perform. They alsoprovide any additional data needed as input to the application.Consider following example Invoke browser, provide username / password & click sign on.Check if user have entered correct username /password, if not instruct to providecorrect username/password.After providing correct username and password, click ‘Yes’ on the warningscreen to proceed further.In end check if user has successfully logged in home page.For above test case, consider following data table record as seen in Table 1
Table 1Brief explanation of Table 1:Based on keyword contained in Component column i.e. Web, the Web related functionswill be called.Any object in QTP is identified primarily by its parent child relationship. So Browsercolumn contains the name of Parent Browser in which object reside.Object column contains child object in the Browser on which action needs to beperformed. Object name is the name of the object or unique identity of the object E.g. forobject like Web Element; it may not have its name as unique identity so html tag & classhave been taken as unique properties to identify the object. The unique identity of objectin object name column is required for creation of run time object from Application Map.Action column contains action to be performed on the object. Here apart from genericaction i.e. set or click, this column also has keyword as ‘VerifyMinorError’. Based onthis keyword, the functions to check if user has entered correct username /password willbe called.As name suggested Param column contains inputs for action to be performed.Expected column contains expected value that needed to be compared with actual whilecheckpoint column contains the user defined messages to be displayed in pass/fail report.How this will be processed furtherThe Intermediate Tables are handled by the Sub Driver which passes each Step to theCore Engine (consist of application map, component function, support function.vbs) forfurther processing.
About Core EngineThe Application Map:The Application Map is one of the most critical items in this framework. Since theapplication GUI is not stable enough, so as suggested ‘Application Map file’ concept hasbeen implemented.Application Map is a .vbs file consisting subroutines that create runtime object by usingDescriptive programming. With the use of application map file, creation of objectrepository step has been omitted.Consider the below snippet of code for implementing a Application Map file conceptSnippet 1In above snippet 1 of code, Subroutine which accepts Object & Object name has beendeclared. Initially Parent Objects i.e. Browser & Browser Page are created in thissubroutine. Afterward based on keyword in object column of Intermediate table, otherchild objects are created.The Component Functions:
Once the objects has been created using Application Map, next step is to perform actionon the object to drive the test script forward.Component Functions are those functions that perform specific tasks (e.g. Invokeapplication action, press a key or button, etc), also call “User Defined Functions” ifrequired.In this automation framework various Component Functions for each type of object (e.g.WebEdit, WebButton, WebElement, WebLink, etc.) have been clubbed in a single .vbsfile.Consider the below snippet of code for Component Functions.Snippet 2In above snippet 2 of code, the Browser, Page & Child Object descriptions (derived fromApplication Map) have been passed as parameter to the Component function. Apart fromObject descriptions, the action which needs to be performed on these object along withparameter required to perform the action has also been passed.Expected value & user defined checkpoint message passed to these functions are in turnpassed to “User defined Function” for further comparison with actual value derived incomponent function. E.g. refer fnWebElement Function in above snippet 2 of code.
Here, we can also add extra code to help for initial conditions; synchronizations apartfrom those provided by the tool. E.g. refer fnBrowser Function in above snippet 2 ofcode. In this function before invoking the application, open browser (if any) has beenclosed.The Support Functions:The Support Function consists of generic functions with core logic. These functions areindependent of Test Automation Framework & can be also useful outside the context ofthe framework. In this framework the Support Functions.vbs contains the general-purposeroutines and utilities that let the overall automation framework do what it needs to do.They are the modules that provide things likeoooooFile HandlingString HandlingDatabase AccessLogging UtilitiesError Handling UtilitiesConsider the below snippet of code for Support FunctionsSnippet 3
Snippet 4While in Snippet 3 generic database functions to Execute SQL & Disconnect databasesession have been provided, Snippet 4 provides the user defined functions whichcompares actual with expected & log pass/fail messages or error correction messages inMain Driver tables (For more details on Main Driver tables ref session Role of MainDriver in Test Automation Framework ).Role of Sub Driver in driving the Core EngineAfter understanding the primary purpose of Core Engine (i.e. Application Map,Component Function, Support Function) let us now understand how the Drivers (whichconsist of Main Driver & Sub Driver) drives the core Engine. Let us first take look at therole of Sub driver in driving the Core Engine.Sub Driver in this framework is the QTP Script. Sub Driver script processes intermediatelevel tables listing Steps to execute. Sub Driver reads each record from the intermediatelevel tables and passes each Step to Core Engine it finds during this process.Consider the below snippet of code for Sub Driver
Snippet 5Snippet 6
In Snippet 5, Intermediate data tables & the Library Files are passed as the parameter toSub Driver. After processing, the Library Files are included in the script, whileintermediate table are read line by line until it reaches end of file. While reading everyrow of intermediate data table, Sub Driver stores value/Keyword of each column in thevariable list.In Snippet 6, When Sub Driver encounters the Component Keyword i.e. “Web” fromintermediate data table; it starts further processing for web related events. Firstly it passesparam list as the inputs to Application Map for creation of runtime objects. Afterwardbased on object keyword, it invokes the corresponding Component Function module tohandle the taskRole of Main Driver in Test Automation FrameworkMain Driver mainly deals with the entire set up required before running the individualtest scripts The Driver Script consists of the following components, which are plug andplay units.Driver tables: - The Main Driver tables plays crucial role in this framework. Relationaldatabase concept has been implemented while designing main driver tables. Main Drivertables are ported in a separate schema created in Oracle Database.Various tables are designed to hold data like the Core Engine File names that requires tobe included in Sub Driver Script, the intermediate data table i.e. spreadsheet names, thesequence in which the intermediate data tables need to be sent to Sub Drivers (E.g. forbatch processing, after login.xls the Functionality Test 1.xls, the Functionality Test 2.xlsrequired to be sent in sequential manner to Sub Driver for further processing), etcApart from these tables, a special table named Audit Trail Table is designed to hold pass /fail results logged after comparing expected vs. actual while processing the test script.The idea being the development of the reporting tool that can represent data in AuditTrail Table (For more details on this refer session Reporting Tool).Library Functions: - For reading data from Driver tables, Support Library Functions(that consist database handling functions) are included in the Main Driver script.Initialization.vbs:- The initialization.vbs in this framework is used to declare and definethe variables which are not going to changes frequently e.g. schema name/ password forthe main driver tables, the sequence list for the intermediate tables, etc. The idea being atany point of time, the script executor should not require to interfere the Main driver code.Initialization.vbs is also included in the Main Driver ScriptHow Main Driver will work?The main driver script connects to driver tables, reads data like Core Engine file/Intermediates data file name, creates absolute path for these file names & sends to Sub
driver as parameter. After Sub Driver completes processing of first intermediate datatable, the control returns back to main driver which is now ready to send the nextintermediate data table for further execution.Reporting ToolReporting Tool is the interesting plug & play feature for this Test Automation Framework. Here reporting tool are simple .jsp pages that represent data logged in driver table(viz: pass/fail results with user defined check point, start & end execution time of thescript, etc) in html format. The advantage being the viewer can get online status of scriptexecution, pass/ fail result on internet. Special feature like export to excel can be alsoadded to this reporting tool.In NutshellWe have seen the features of implementation of Hybrid Test Automation frameworkusing QTP; let us now recapture implementation of Automation Framework work flowfrom start.The flow starts with the Main Test Driver Script. The Main Driver Script first loads thesupport functions & variables available in Initialisation.vbs file e.g. schema name/password for the main driver tables, etcMain Driver Tables are repository built in Oracle database that consists the informationsuch as Core Engine File names, the intermediate data table i.e. spreadsheet names, thesequence for processing of the intermediate data tables, etc.Main Driver Script connects to Driver tables with the help of support functions &variable list available from Initialisation.vbs, reads data from Driver tables & sends thesame as parameter to Sub Driver Script.The interaction logic with AUT has been depicted in Intermediate Data tables i.e.spreadsheet in the form of keyword. Sub Driver Script after including Core Engine files(consist of Application Map, Component Functions, Support Function), reads each recordfrom intermediate data tables and store the same in variable list.Application Map is a .vbs file consisting subroutines that create runtime object by usingDescriptive programming. Sub Driver passes the variable list i.e. each record read fromIntermediate data table to Application Map for creation of run time object. Based onkeyword/ value available in variable list the Parent as well as child object required toexecute the test steps are created.Once the objects has been created using Application Map, next step is to perform actionon the object to drive the test script forwards. Component functions consist of low levelevents (i.e. press button, set param in input boxes) to be performed on the object.
Sub Driver passes the object description (derived from Application Map) along withaction to be performed & parameter required for performing action as inputs toComponent Functions. Based on object name & action to be performed the correspondingcomponent functions are invoked to handle the task.The Support Functions are functions with core logic which are independent of anyautomation framework. These functions can be called from any module of framework ifrequired. Apart from providing generic utilities (e.g. Database Access utilities, Errorhandling utilities, etc.), support functions also contain user defined functions viz subroutine for comparing actual vs. expected & logging pass and fail result in Main DriverTables. The Pass/ Fail results logged in main driver tables are then represented in theForm of Reporting Tool.ReferencesTest Automation Frameworks by Carl J. NagleAbout the AuthorPallavi Patwa is a Senior Technical Consultant at TechMahindra Ltd. She is a CSTE fromQAI and ISTQB Certified tester. She has about ten years of experience in the area ofsoftware validation and verification and test automation