| Tests can be created in QTP with the help of | | | | can lay their focus on the maintenance of design |
| Recording or by using Keyword-driven methodology or | | | | & test structure, while the automation engineers |
| by a combination of both of them. | | | | can concentrate on maintenance of functions and |
| Following are some of the situations wherein each one | | | | objects. |
| of these approaches are beneficial. Accordingly we | | | | 4) We keep on adding new objects in the local object |
| can decide as to whether to go in for Keyword-driven | | | | repositories while recording the tests. This way there is |
| testing or recording for our application. | | | | great probability that different testers will create their |
| Recording is beneficial especially in situations like: | | | | own local object repositories having multiple copies of |
| 1) Recording is quite helpful to the beginners. Due to its | | | | the same object. The advantage of keyword-driven |
| simplicity, even a novice user is able to understand the | | | | methodology is that we pick up the desired objects |
| mechanism as to how QTP understands various set | | | | from an already existing object repository for inclusion |
| of operations performed by the user on the application | | | | in our steps. In case of need, we can add any new |
| and how it converts them to its objects and its own | | | | object to the local object repository on a temporary |
| operations. | | | | basis & the same can be transferred to the |
| 2) Not only the beginners, even the advanced users | | | | shared object repository for use later on. |
| find recording quite beneficial while handling some new | | | | 5) During recording a test, the desired objects, |
| features added to an application or managing a new | | | | methods & arguments are automatically added by |
| application altogether. With recording we can easily | | | | QTP. This way QTP helps us in test creation with |
| develop functions using built-in keywords of QTP. | | | | great ease & with lesser planning & |
| 3) We can exploit the recording feature of QTP when | | | | preparations. Though we are able to quickly create |
| there is an urgent need for creating some tests aimed | | | | tests with this approach, but these tests are |
| at testing some application or its feature especially | | | | cumbersome to maintain in case changes take place in |
| when there is no necessity of its maintenance on a | | | | the application. In such case fresh recording of major |
| long-term. | | | | portions of the test become necessary. |
| Keyword-driven methodology is advantageous in | | | | Whereas already existing operation keywords & |
| situations like: | | | | objects are chosen while using keyword-driven testing. |
| 1) Using keyword-driven methodology instead of | | | | Hence the tester needs to be fully conversant with |
| creating tests at the object level, we can create them | | | | already available inventory of function libraries as well |
| at a business level. | | | | as object repositories. Moreover the tester is required |
| For instance, in an application, QTP would recognize a | | | | to have good understanding of his requirements from |
| single option selection, as many individual steps like - | | | | the test prior to the process of adding steps. |
| clicking an object like a button, operation of mouse | | | | This is the reason that well-planned, nicely structured |
| over a list or input from the keyboard on a sub-item of | | | | & easily maintainable tests emerge out of |
| the list. Here we can easily create a function, with | | | | keyword-driven testing. |
| easily identifiable name, which would cover all such | | | | 6) While following keyword-driven methodology, based |
| operations of lower level clubbed in one keyword at | | | | upon the detailed product specifications, the automation |
| the business-level. | | | | engineers are able to add objects and functions even |
| 2) With the help of keyword-driven methodology, we | | | | before the inclusion of a particular feature in the |
| can use specialized operations like synchronization | | | | product. |
| statement for higher level keywords, say in a case, | | | | 7) By using keyword-driven methodology we can start |
| where the system is made to wait till the | | | | the development of tests for a new product or its |
| communications of client-server finishes. Such tests | | | | features much earlier in its development cycle. |
| become quite easy for execution & interpretation | | | | Conclusion: As compared to recording, the |
| by even less skilled testers & even the | | | | keyword-driven testing is generally more time |
| maintenance becomes easy when changes take | | | | consuming & resource consuming. However once |
| place in the application. | | | | all the tests for some particular application are created, |
| 3) We can easily bifurcate test maintenance and | | | | they can be managed & maintained with more |
| resource maintenance with the help of keyword-driven | | | | flexibility and efficiency as compared to the recorded |
| testing. With such a separation, the application testers | | | | tests. |