Before starting actual automation task, we should do tool evaluation and feasibility study to make sure QTP is the appropriate tool for automating test cases of our application. It can be done by selecting few sample modules/screens/flow from the application/test cases and create simple QTP scripts to make sure QTP will recognize the objects in our application
As part of Test driven development, we can ask the application development team to give proper name or any other identification properties for the objects, if our feasibility study reveals some difficulty for QTP to recognize the objects.
As I mentioned earlier, we should start our actual automation work only after completing some basic manual testing to make sure the application is stable and in working condition.
QTP developers should review the Test cases and update it to specify which test cases can be automated and which can not 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 possible, the manual test cases can be rearranged to have separate automation test cases.
Once after reviewing all the test cases and after getting familiar with the application we can design the automation frame work for our need.
Keep separate instance of application specifically for the purpose of developing automation scripts. It will avoid any unnecessary mess up with manual testing processes.
Set up proper QTP development environment with required Add-in and with any add-in extensibility. If many people are going to involve in the development activities then we need to clearly document the responsibility of each person and the approach for sharing the scripts. If application is installed in remote machine then QTP also should be installed in remote machine. Because QTP will not recognize the objects of application in remote session.
Set up proper object identification properties in QTP IDE.
Once after completing all the above basic steps, the first development task should be adding all the required Test Objects/properties to the Object repository. It can be done by recording or by manually adding the objects to Object repository. If you specify any object using DP (Descriptive Programming) remember to document it.
Once after adding all the objects, rename them to have unambiguous/meaningful name. Doing renaming from object repository will automatically change the name of the object in the script also. But reverse is not true. I-e Renaming a object from script won’t automatically change it in Object repository.
Based on your design of automation framework, create reusable actions and vbscript functions using step generator or keyword view or expert view or using Active screen.
Using these reusable actions prepare a sample/base script for executing few test cases. And then test it to make it error free.
Once after completing the above mentioned sample script, do parameterization (data driven testing) for executing multiple iterations. Parametrization can be easily done from both keyword view and expert view.
Add checkpoints to verify the expected results. Make sure that your checkpoints will work with different data. i-e use regular expressions if some part of expected value will change based on the input data during each iteration of test execution. And, editing checkpoint in QTP is having some issues. So, take care when editing the checkpoint. Mostly changing checkpoint in one place will affect the other checkpoints also. Or, you can create your own functions for creating checkpoints.
Use appropriate Regular expression to make sure the script runs in all scenarios even when some properties are getting changed dynamically in particular pattern. For example if your screen page title changes based on the username of the logged in user, the script will not work correctly for all users. (By assuming that the script uses the page title for identifying the screen). You can refer the QTP help files if you don’t know how to add Regular expression.
Add the Recovery scenarios to handle any unexpected behavior of the application. Recovery scenario manager and wizards.
Use Environment variables to avoid any hard coded values in the script.
Do dry run for this sample script and debug the issues in the automation script and fix them.
Do the above steps for all the test cases.
Create a Driver script which will call all the test scripts. Need to take additional care about deciding whether driver script should take data from its own datasheet or whether it should read data from datatable 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 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. 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 third one will test the user deletion feature. And, assume that the second Test will use the user name created by First test, and the third test deletes the account created by first Test. In this scenario, if you face any difficulty while calling second test we need not always start the dry run from beginning. Since one user account was already created by first Test successfully, we can just comment out the calling of first Test and then continue the debugging of second Test using the already created account.
Prepare .vbs script using Automation Object Model to run the QTP scripts in other environments also with same settings. It can be easily done by using “Generate script” option in QTP IDE.
Run the scripts in 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.