Winrunner Usage - Best Practices S.A.Christopher

Origin of the Document VRZIVS team, a part of IVS is using a framework that makes the Automation Testing for Web applications easier using Winrunner. This presentation briefly explains the usage, Pros & cons of the architecture

Contents Need and Criteria for Automation Brief Introduction of the Architecture Software Requirements Components of the Architecture and their responsibility Table Structure Details Comparison of the architecture with the General Scripting adopted Pros & Cons of the Architecture

Test Automation gives improvement in test cycles. Automation is the only long- term solution for reduced costs in software testing and better quality Products. But these aims are achieved only when certain best practices are followed before and while developing the automation suite Howard Fear has aptly stated, "Take care with test automation. When done well, it can bring many benefits. When not, it can be a very expensive exercise, resulting in frustration”. Need For Automation

Which Test Cases to Automate?  Tests that need to be run for every build of the application (sanity check, regression test)  Tests that use multiple data values for the same actions (data–driven tests)  Tests that require detailed information from application internals (e.g., SQL, GUI attributes)  Stress/load testing  More repetitive execution? Better candidate for automation

Which Test Cases Should Not be Automated?  One-time testing  Usability testing “How easy is the application to use?”  “ASAP” testing “We need to test NOW!”  Ad hoc/random testing based on intuition and knowledge of application  Tests without predictable results  Improvisation required? Poor candidate for automation

Brief Introduction about the methodology adopted This is purely a Data Driven Type of testing. All the test data required to perform the automation testing are entered in the Microsoft access tables. The Winrunner scripts establishes a database connection, retrieve the test data and perform the automation run. The only modification to be done is the changes in the GUI Map File (due to any change in the GUI) and the corresponding entries in the tables.

Software Requirements Automation Tool Used : WinRunner 7.5 ( No Add-ins required) Data Base Used: Microsoft Access

Automation Architecture Winrunner Configuration Files Winrunner Driver Scripts Microsoft Access Database Application Under Test Initialize and Run Establish DB connection and Query Return the result for the Query Run Test

Components of the Architecture Configuration Files (.ini files and Winrunner scripts) Microsoft Access Tables WinRunner Driver Scripts Application under Test ( Web application )

1. Configuration Files This is the starting point of the whole automation process. The different tasks these Configuration files perform include: Initialization of Variables. Creation of reusable User Defined functions. Loading the User Defined functions to Win Runner’s Function Generator. Passing the control to the Driver Scripts after the initiation process.

……..Configuration Files The Winrunner scripts used for initializing should be called from the :\ProgramFiles\MercuryInteractive\WinRunner\dat\tslinit” file. As this is the first file called whenever the Winrunner tool is invoked, calling the configuration/initialization scripts in this file will initialize the parameters whenever the tool is started.  The “wrun.ini” file should be placed under “C:\Windows”. This should contain the environment which should be considered, the DSN name and the location of the Driver scripts.

2. Microsoft Access Tables The three tables used in the architecture are : APPLOGIN WIN_SEQ SCRIPTDATA

a. APPLOGIN – Table Structure

APPLOGIN – Contents The computer name in which the script should run. The Script name The sequence in which each scripts should be executed. Flag to turn ON/OFF any of the scripts.

b. WIN_SEQ – Table Structure

WIN_SEQ - Contents The Script Name Window names that each Script should invoke. The sequence in which the windows would be accessed. Flag to turn ON/OFF any of the sequence.

c. SCRIPTDATA - Table

SCRIPTDATA - Contents The Script Name and the Window name The GUI Window name and the GUI Object name that is in the GUI Map file. The Test Data to be supplied (if any) The Actions to be performed over each Html Object. The sequence in which each operation should be performed. Flag to turn ON/OFF the steps. Note : This table is the backbone of the whole architecture. All the parameters required for the execution of Winrunner scripts should be passed from this table.

C. Winrunner Driver Script These is the script that drivers the whole architecture. Following are the list of tasks these scripts perform. Establishing Database Connection. Executes the Database queries and retrieves the records from the tables. Performs required operations on the objects of the application depending upon the records fetched from the database. Checks for the desired outputs in each step. Generates the Final Report based upon the results.

Sub sections of the Driver script genericAction - To perform link clicks, List Select and others…. setData - For passing any value as the input…. getData - To retrieve the state of any Html Object….. verifyData - To verify the Expected (vs.) Actual Results…..

……Driver Scripts These sub-sections will in turn call the Winrunner functions. Appropriate arguments are passed to the relevant Winrunner functions from the database tables.

A snapshot of the Driver Script Switch ( Arg1 ) case "genericAction": Switch (Type) { case "Link Click": rc = web_link_click(Data); if (rc != 0) msg = “Data Execution Success..” else msg = “Data could not be executed”

In a Nut Shell ( About Driver Scripts) Get the Machine and Script Names Retrieve the Window names in Sequence Get all GUI Objects in the Window under Consideration Retrieve the Test Data and the Action to be performed on the GUI Objects (in sequence) Perform the action, check the Actual Result with the Expected and generate Report

Comparison of the architecture with General Scripting Usage of Architecture Usage of General Scripting Less number of scripts usedMore number of scripts used Reusability of code is maximumReusability of Code is minimum Frequency of Modification of script is minimum Frequency of modification of script is high Same set of scripts can be used for testing any web application. Too many changes required to use the same set scripts to test other applications. Debugging during test run is easyDebugging is complex. Selective scripts can be run in different Machines. This scenario is difficult to achieve.

Advantages Minimum amount of scripting is required. Changes need not be made to the scripts in the intermediate process Scripts can be run across different machines. Debugging a single scenario is simple as the rows associated with the other scenario’s can be turned OFF. Modifications needs to be made only for selected columns in the table whenever there is a change in the GUI of the application. Separate GUI Map Files can be used for each module.

Disadvantages The Bulk size of the table. Much involvement of Microsoft access tables. Creation of Dynamic Inputs is difficult. Run-time change in the GUI Map file is not possible.

Thank You