Keyword Driven Framwork

Keyword-driven testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can be maintained  repeatedly whenever required with only minor updates, even though when the application or testing needs changes dynamically. The Keyword-driven automation infrastructure usually includes one or more shared object repositories and one or more function libraries. Once the test automation infrastructure is ready, the application testers can begin designing their keyword-driven tests by selecting objects and operation keywords in the Keyword View.

The keyword-driven testing methodology divides test creation into two stages:

Preparing a set of testing resources or test automation infrastructure:  Preparing the test automation infrastructure includes a planning stage and an implementation stage.

Creating tests in the QTP Keyword View: By selecting the keywords (objects and/or operations) that represent the application functionality which we want to test.

Advantages of keyword-driven testing methodology:

• It enables us to design our tests at a business level rather than at the object level. 
• For example, QTP may recognize a single option selection in our application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. 
• We can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.
• By incorporating technical operations, like a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are made easier to read and are made easier for less technical application testers to maintain when the application changes.
• Keyword-driven testing leads to a more efficient separation between resource maintenance and test maintenance.  This enables the automation experts to focus completely on maintaining objects and functions while application testers focus on maintaining the test structure and design.
• When recording tests, we may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, we select the objects for our steps from the existing object repository. When we need a new object, we can add it to our local object repository temporarily, but we are also aware that we need to add it to the shared object repository for future use.
• When we record a test, QTP enters the correct object methods, and argument values for us.  Hence it is possible to create a test with little preparation or planning. 

Repercussions: Although we can easily create our tests quickly, But

# Such tests are harder to maintain when the application changes and often require re-recording large parts of the test.

• While using keyword-driven methodology, we select from existing objects and operation keywords. Hence we must need to be familiar with both the object repositories and the function libraries that are available. 

We must also have a good idea of what we want our test to look like before we begin inserting steps. 

This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance.  Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product.