Keyword-Driven or Table-Driven Testing
Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords which are independent of the test automation tool used to execute them, and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.
There are 2 basis components in Keyword Driven Framework viz. Keyword, Application Map.
What is a Keyword or Action?
Keyword is an Action that can be performed on a GUI Component. Ex. For GUI Component Textbox, some Keywords (Action) would be InputText, VerifyValue, and VerifyProperty and so on.
What is Application Map or Control?
An Application Map provides Named References for GUI Components. Application Maps are nothing but ‘Object Repository’.
Example: The following table represents Keyword driven framework for ‘Calculator’ application. The "Window" column contains the name of the application window where we're performing the mouse action (in this case, they all happen to be in the Calculator window). The "Control" column names the type of control the mouse is clicking. The "Action" column lists the actions taken with the mouse (or by the tester). And the "Arguments" column names a specific control (1, 2, 3, 5, +, -, and so on).
Window | Control | Action | Arguments |
Calculator | Menu | View, Standard | |
Calculator | Pushbutton | Click | 1 |
Calculator | Pushbutton | Click | + |
Calculator | Pushbutton | Click | 3 |
Calculator | Pushbutton | Click | = |
Calculator | Verify Result | 4 | |
Calculator | Clear | ||
Calculator | Pushbutton | Click | 6 |
Calculator | Pushbutton | Click | - |
Calculator | Pushbutton | Click | 3 |
Calculator | Pushbutton | Click | = |
Calculator | Verify Result | 3 |
Advantages:
§ Detail Test Plan can be written in Spreadsheet format containing all input and verification data.
§ Prior to the Detail Test Plan being written, if "utility" scripts are created by people who are well versed with the automated tool’s and Scripting language, then the tester can use the Automated Test Tool immediately via the "spreadsheet-input" method, without needing to learn the Scripting language.
§ The tester needs to learn only the "Key Words" required, and the specific format to use within the Test Plan. This allows the tester to be productive with the test tool very quickly, and allows more extensive training in the test tool to be scheduled at a more convenient time.
Disadvantages:
§ Development of "customized" (Application-Specific) Functions and Utilities requires proficiency in the tool’s Scripting language.
§ If application requires more than a few "customized" Utilities, the tester has to learn a number of "Key Words" and special formats. This can be time-consuming, and may have an initial impact on Test Plan Development. Once the testers get used to this, however, the time required to produce a test case will be greatly improved.
