A framework is a combination of predefined process and components that can be used to write actual automation scripts.
Following are the critical features of any QTP framework Test GUI Object Repository - Any UI automation will have objects to interact with. These objects will have to be stored and retrieved in an efficient manner and used in automation scripts. Either Object repository or descriptive programming approaches can be used however it should be uniform across the automation project, otherwise you will have very troubled automation projects, where you can't find if you already have a certain object or if you have to create a new one. This will create confusion and duplicate objects.
Configuration - How are you going to do the configurations required for your tests, how are the people going to change these configuration settings? ini files or property files or xml files can be used whatever approach is used, certain conventions have to be formulated and communicated to the entire team.
Data parameterization & input data modifications - The main requirement of automation tests is that it can run for different sets of data without too much modification or fiddling. Typically data will be stored in excel files when it comes to QTP. However Certain wrapper functions need to be written so that bulk data required for tests can be read easily. For example, if all your tests need an address which consists of 10 fields, your framework should provide a quick way for people to read all 10 fields without having to write code for all ten fields. How will you maintain data for hundreds of tests? Are you going to maintain in one excel file? or are you going to create multiple xml files? How are you going to store common data? All these questions must be answered and necessary functions must be written before you can call your framework complete.
Test Dependencies & Order of execution - How does your framework solve the problem of running all prerequisite steps required for certain tests? Are there going to be dependencies between tests? In such a case , how will you ensure all tests can be run without duplicating the code? Your framework should take care of that. How will the tests be triggered?
Filtering of tests - Your framework should also take care of easy filtering of tests. If you want to run only 20 out of 100 tests you have, how will you do that? Some frameworks do that by making use of an extra column in your data file where you mention whether a certain test should run or not. There are other approaches as well.
Naming conventions - Naming conventions are very important for tracing tests. Especially if you don't use a test management tool and test automation tool from the same company. If your company writes all tests in excel but uses QTP to automate how will you ensure that your automation scripts are running all the tests? Naming conventions will help you there.
Error handling incase of exceptions - What happens when a test is stuck and couldn't continue, how does your framework ensure that you don't come back in the morning and find that your test execution is stuck in test number 2? Easy reporting of failures - How does your framework report failures? Is it always going to be reports that are generated by QTP? Is it easy for a project manager to see the QTP report and understand how many tests failed and how many passed? Try to solve each of these questions, you will be able to create a framework on your own by the end of implementation of solutions for all the above issues.
