In Quality Assurance
0
92

About QuickTestPro(QTP)

QTP is one of the Test Automation Tools developed by Mercury Interactive in 2002. And, it was acquired by HP (Hewlett-Packard) in 2007. Currently, it supports Windows Operating Environment only.

QTP is a mercury automated keyword-driven testing solution, like WinRunner. QuickTestPro provides everything we need to quickly create, run, debug, the test scripts. This blog describes how to use the quick test to create and manage test scripts. It explains how to use the function definition generator to create user-defined functions and register them to test object in your test scripts.

Automated testing with QuickTestPro

Automated testing with QuickTestPro improves the speed of the testing process than WinRunner. We can create tests by using QuickTestPro that checks all aspects of our application build. And, then run these tests every time in your application build changes for regression. As QuickTestPro run tests, it simulates a human user by moving the mouse cursor in an application build screen, like window or web page, clicking graphical user interface (GUI) objects, and entering keyboard input. However, QuickTestPro does this faster than any human user.

The use of QTP with examples

Assume that you are developing an application similar to Gmail. Once, after completing your development you need to test it by doing login with different username and password combination to make sure that your application will allow only the valid users.
For doing this testing, you can just start QTP and do the login activity one time. QTP will record the steps and it will be able to run the same steps at any time i-e QTP will automatically login to your application without doing any manual task other than just starting the QTP script replay. And, one of the most important points is that you can feed various username and password data to the QTP script so that it can do the same testing using various data.

QTP provides multilingual support. With the help of QTP, it is possible to support multi-byte character languages such as Chinese and Japanese also. (But I had faced some difficulties with multi-byte character languages when using an old version of QTP. I believe those problems should be solved now. If you still face any difficulty with using multi-byte characters then you can use a new version of QTP. This is also possible to use SQL Queries within the script in QTP.
Record and Replay feature of this tool can be easily used by anyone who is having some basic knowledge of computers.
And, we can use QuickTestPro by programming experts also as it is supporting the VBScript and the COM. Because of this wide-range of capability, many companies are using QuickTestPro to automate their software testing activities.

Here is something about QuickTestPro

  • Developed by mercury interactive.
  • Functionality testing tool.
  • Supports all WinRunner supported technologies and asp.net, SAP, people soft, oracle application, XML, and multimedia.
  • Recognizes objects and windows in your application build while creating test scripts like WinRunner 8.0.
  • Creates automation test scripts in VBScript.

TESTING PROCESS

The QuickTestPro testing process consists of the following main phases to convert our selected manual functional test cases into automation test scripts.

  • Preparing base state.
  • Recording action on application build.
  • Enhancing recorded test script.
  • Debugging test script.
  • Running the test script.
  • Analyzing test results.
  • Reporting defects.

PREPARING BASE STATE

We can confirm that our application build and QuickTestPro are set to match the needs of the test Before creating a test. Make sure, our application build displays the elements on which we want to record and that our application-build options are set as we expect for the purposes of our test, so we can call it base state.

RECORDING ACTIONS ON APPLICATION BUILD

As we navigate through our application build with respect to corresponding manual test case actions, QuickTestPro graphically displays how each step performs as a row in the keyword view and displays VB Script program in the expert view.

ENHANCING RECORDED TEST SCRIPT

This is about inserting checkpoints with our expected values to determine whether our application build is functioning correctly or not. While Exchanging fixed values with parameters, we can verify how our application performs the same operations with multiple sets of test data. Adding logic and conditional or loop statements enable us to add sophisticated checks to our test.

DEBUGGING TEST SCRIPT

We debug a test to ensure that it operates smoothly, without runtime errors. This debugging phase is an optional phase before running our test script on application build. We can run a test script to check the behavior of our application build. While running, QuickTestPro opens the application build and performs each step in our test script.

RUNNING TEST SCRIPTS

We can run a test script to check the behavior of our application build. While running, QuickTestPro opens the application build and performs each step in our test script.

Example

Window ("Flight Reservation").Activate

Window ("Flight Reservation").WinButton ("Update Order")

Check checkpoint(Update Order)

Window ("Flight Reservation").WinButton ("Update Order").Click

ANALYZING TEST RESULTS

After Running Test Scripts, we can examine the test results to pinpoint defects in our application build. The engineers examine test results to automate the coverage of our application build during testing.

REPORTING DEFECTS

We can report the detected defect to the point of contact by using an available tracking system. During test execution, test engineers are required to report defects identified to the development team in a defect report format. It is necessary to communicate the point of contact and send these defects profiles to the development team to resolve defects. Here, we would like to present the usual way of defect report submission process.

Required Steps/Processes in QTP Automation

  • Need to take additional care about deciding whether driver script should take data from its own datasheet or whether it should read data from the data table of the called action.
    Complete dry run for the Driver script. It is really a challenging task. Because most of the Actions within the Driver script will depend on each other and it will take very long time to complete the dry run if we start the dry run from starting point every time whenever the script fails in between the execution.

Examples

I will explain with one example-  Assume that your driver script calls three Tests. First Test will create a user account, second will test the Profile update feature, and the third one will test the user deletion feature. And, assume that the second Test will use the username created by the First test, and the third test deletes the account created by the first Test. In this scenario, if you face any difficulty while calling the second test we need not always start the dry run from the beginning. Since one user account is already created by the first Test successfully, we can just comment out the calling of the first Test and then continue the debugging of the second Test using the already created account.

EX:

  • Prepare .vbs script using Automation Object Model to run the QuickTestPro scripts in other environments also with same settings. Basically, it does easily by using “Generate script” option in QTP IDE.
  • Run the scripts in the desired environment.
  • Analyze the test results.
  • Report the bugs/defects in the application once after completing the analysis.
  • Once after completing functional testing, select few essential scripts and store them separately for the future Regression Testing.
  • The test case should be reviewed by QuickTestPro Developer and update it to specify which test cases can be automated and which cannot be automated. Because ideally, it is not possible to automate all the test cases. Difficulty in navigation or object identification issue or difficulty in verifying the result will prevent automation. If it can be possible the manual test cases, rearrange to have separate automation test cases.

Conclusion

Once, after reviewing all the test cases and after getting familiar with the application, we can design the automation framework for our need. It is necessary to choose a separate instance of application specifically for the purpose of developing automation scripts. It will avoid any unnecessary mess up with manual testing processes.

Recommended Posts
We Are Here to Help!
Name:
Phone:
Email:
Country:
Message:
 

Start typing and press Enter to search