QUICK TEST PROFESSIONAL 8.2 Case Study for QUICK TEST PROFESSIONAL 8.2

Case Study overview – For Internal Use Only Client Name: Countrywide Logo Usage: Logo cannot be used Client Reference: Cannot be referenced Alternate Name: A leading WholeSale Lender in the world Infosys Contact Person for the Case Study: Aruna Bala Kumari D IVS’ association with the client: Nearly 3 yrs Infosys’ revenue on this validation engagement for the current year (specify the year within parenthesis – e.g. ’04 – ’05): Engagement Manager: Venkatesh Nagarajan Technology Architecture: J2EE Business Domain: Mortgage Banking Service Offerings: Functionality and Performance Testing (Manual & Automation) Snapshot of the Engagement: Infosys is doing around 11 projects with this client for functional (manual + automation) & performance testing. Viper has been the Test management Tool for logging & tracking defects and QTP and Load runner are used as Functionality and Performance testing tools,Along with these Test Director is used for executing QTP scripts

Background of the Client Company is a leading Mortgage Banker Client Company offers a wide range of Housing loans Recognized expert in the field of Mortgage Holds second position in Mortgage Services in Americas most admired companies. As a part of the company's development company launched a web application which is user friendly for the use of all their business partners to apply for loans and get them approved online and hence reducing the documentation time. Infosys has partnered with this Mortgage banker in setting up "Testing Centers of Excellence“ for all their applications.

Problem Statement Client needed automation of the WEB application which could be used later on with each release without consuming time in doing manual regression testing. As most of the features in this Web application remains unchanged everymonth and hence the test scripts generated for QTP can be reusable Automation was required because of multiple releases of application having their own set of unique requirements and parameters which were critical to test manually. So with slight modification in Test Scripts, these releases could be tested easily.The tool QTP also has various features like reusable actions and shared object repository which makes the task easy

Why Infosys? Infosys has been involved in manual testing of various applications for this client. Hence this application is also added along with the existing applications . As an extension to the manual testing projects already existing, Infosys was asked to do automation testing for this new application as a separate account from the same client The testing process followed in the previous projects as well as the quality of deliverables in the past to the client made this new account for Infosys

Key validation challenges for this project The Biggest challenge for this automation project was that Application was too vast and complex. The Automation was required in the way that it can be used at any location i.e. Offshore, Onsite. The Test Scripts generated should not fail when moved from one drive to another. The unexpected error generated by the system were needed to be handled while running the scripts to avoid unexpected failures. Application is Data driven, so data should be handled in such a way that a new user should easily be able to run the scripts with his/her own data.

Infosys’ approach for this engagement Client trained Testing Team on QTP as well as Test director through online KT Manual Test Cases were analyzed to find the percentage possible automation of application. Pilot test cases were automated to get the in-depth knowledge of functions available in QTP. Test Strategy was prepared to identify the time utilization, resources required and Scope of the project for automation.

Technology Architecture The Testing Tool used for the automation of this project was Quick Test Professional. Client suggested for this tool to be used. Quick Test Pro 6.0 was used for the functional testing of the application at the beginning of the project Later Client provided QTP 8.2 and asked to use the same for testing the application as Client wants the tool to be of the latest version available to make a use of all the available features

Team Organization The team comprised of the following Offshore Test Analyst - 1 Test Engineers - 4 The project duration was feb 1st 2005 to dec 31st 2006

Measures and Metrics Productivity of test case generation = (No of test cases generated / No of person hour spend on that) % automation achieved = (No of automated test cases/Total no of manual test cases) % Reduction in testing effort = (Effort to execute manually - Effort to execute the automated test scripts)/ Effort to execute manually, expressed as a percentage % Reduction in Testing Time = (Time to execute manually -Time to execute automated test scripts)/ time to execute manually, expressed as a percentage>>

Sample case study of the Tool The main steps followed in our project while automating can be briefed as follows 1)Generate the test cases covering all the requirements 2)Getting the test case document reviewed by the client and obtain confirmation to generate script which checks all the cases in the test case document 3)Record a sample scenario 4)Insert Check points wherever validation is necessary 5)Modify the QTP script in the Expert view if necessary 6)Make the script datatable driven . Ensure that all the scenarios are covered in the Datatable 7)Execute the QTP script generated 8)Store the pass results in the folder 9)Update the PCR information as tested completely and upload the pass results in the PCR folder

Process Diagram to automate a test Using QTP Record a sample scenario modify the script in the expert view Insert check points to all the objects to be Validated Parameterise all the action and make the script Datatable driven execute the script and upload the xml results file against the concerned PCR

Best Approaches used in Tool 1) Objects Repository – Started with per action repository, but on finding the problems with per action system, team decided to use Shared object repository because of following reasons: Easy maintenance of test script when an object in the application changes. Manage all the objects for a suite of tests in one central location. On change of Object description/properties in the shared object repository for an open test, Quick Test Professional applies the change to all the tests that use the same shared object repository file. 2) Log Files – These log files were created using VBS files to store the test results whenever any error was generated by system while execution. The functions ‘err. Number’ & ‘err. Description’ was used to capture the error number and then its description in Log files. Test results on the basis of error number were saved e.g. If error number is zero then step passed, if error number is not zero then step failed.

Best Approaches used in Tool Continues… 3) Relative path approach – Relative path approach was used to utilize the same test script from two different drives (Onsite and offshore is a good example of it, same drive may not be present at both places) Tree structure explains it well with child at the bottom and great grand parent at the top. Great grant parent folder is present in any drive directly. If one Great grand child ( any action ) is present under one parent and needs to call another great grand child (another action) then the system goes backward to the top most folder and goes towards second child. But in Relative path approach, the path is diverted from the Grand parent only so that drive path does not come in the way, which may vary from onsite to offshore. 4) Library Files – Library files were used when common functions are present e.g. Sorting of results or column and wild character search.

Best Approaches used in Tool Continues… Data pool from excel – so that if someone new runs the script s/he does not need to change the data every where in all scripts. But if data pool is being used, data can be imported from the excel directly. Object Properties change with each build – With shared object repository, the properties need to be changed at one place only and it would be reflected in all scripts. 7) Recovery Scenario – Sometimes when system errors pop up in the application or application crashes due to load of data or some other reason. It is very difficult to execute the test scripts in such condition. Recovery scenario is used for that purpose. It has three stages a) Trigger event – Recovery event is triggered when any exceptional error message pops up. b) Recovery option – In this stage you have an option to click on [OK] button of the message.

Best Approaches used in Tool Continues… c) Post recovery option – This stage allows you to select the option, you want to ‘stop’ the execution or ‘skip’ the step in execution at which error message pops up. 8) Batch run – Test scripts for the complete applications were run together in a batch. It was impossible without giving any pointer for the Last step of previous test script and first step of next test script. (Means last step of first test script should end where the first step of the second test script starts) Execution flow given in Test director under Test Lab tab was mapped to the test scripts to create an execution flow. Under each test scripts, Actions were used to modularize the functionality of the application. 9) Integration with the Test Director – Test scripts were maintained in Test Plan of Test director and executed from the Test Lab only. Defects can be logged automatically from QTP but it was not used to avoid the duplicate defect.

Business Benefits delivered to the client The Key Performance Indicators (KPIs) achieved are The Parameterisation activity performed reduced a lot of time that needs to be spent on testing same scenario for different conditions .In brief the following can be achieved Reduction in total Testing Cycle More Reliability Less Time consumption than Manual testing Initially Automation is expensive because of Licensing cost and training but for later cycles, automation helped in reduction of the overall testing cost. These KPIs helped in saving Time, Effort, Cost, etc.

Value addition by the validation team The following are the significant value addition that the testing team has brought in: The test scripts provided were reusable with slight modification even after application was upgraded to higher version platform. In addition to the functional test results, the testing team suggested numerous tuning tips for the Java based Applications. Many Scripts are made reusable for the scenarios which needs to be performed every release The team has also makes the script to execute in all environments by giving conditions while execution As most of the scripts are datatable driven and even check points are parameterised testing has become easy even when the conditions to check are being modified for every release

Thank You!