Keyword-Driven Testing: Composing Keyword Test Cases

Keyword-Driven Testing: Composing Keyword Test Cases (ISTQB CTAL-TA)

Introduction
Keyword-Driven Testing (KDT) is a test design and automation-support technique covered in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. The Test Analyst identifies keywords, composes them into keyword-driven test cases and supplies test data. The Technical Test Analyst or test automation engineer implements the code (the keyword library) that executes them. This guide explains why KDT matters, what it is, how composing keyword test cases works and how to handle exam questions on the topic.

1. Why Keyword-Driven Testing Is Important
The main benefits are listed below.

• Separation of concerns: Business-level test design (what to test) is separated from technical implementation (how to execute it). Domain experts and Test Analysts can write tests without programming skills.
• Maintainability: When the system under test (SUT) changes, often only the keyword implementation (one script) needs updating, not hundreds of test cases.
• Reusability: One keyword, such as Login or CreateOrder, can be reused across many test cases and test suites.
• Readability: Keyword test cases read like business workflows, so they are easier to review with stakeholders and easier to trace to requirements.
• Early start: Test cases can be written from requirements or user stories before the SUT exists. They can be run manually first and automated later.
• Scalability of automation: KDT reduces the cost of building and maintaining large automated regression suites.
• Consistency: A controlled keyword vocabulary standardises how tests are described across teams.

2. What Keyword-Driven Testing Is
ISTQB defines keyword-driven testing as a scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. A keyword (also called an action word) represents a business-level interaction or verification. Each keyword is implemented once by a supporting script or library function.

Key terms:

• Keyword (action word): A word or phrase describing an action or check, e.g. OpenApplication, EnterCustomer, VerifyBalance.
• Arguments / parameters: The data a keyword needs, e.g. EnterCustomer | John | Smith | London.
• Keyword-driven test case: An ordered sequence of keywords with their arguments and expected results, usually stored in a table, spreadsheet or text file.
• Keyword library / supporting scripts: The code that interprets and executes each keyword against the SUT.
• Test execution engine / interpreter: Reads the keyword table and calls the matching implementation.
• High-level vs low-level keywords: High-level (business) keywords such as PlaceOrder can be composed from lower-level keywords such as ClickButton or EnterText. This creates a keyword hierarchy, sometimes called composite or user-defined keywords.

3. How It Works: Composing Keyword Test Cases
The Test Analyst's work typically follows these steps:

Step 1: Analyse the test basis. Review requirements, user stories, business processes and use cases. Identify the recurring business tasks users perform.

Step 2: Identify keywords. Derive keywords from business processes, not from GUI details. Good keywords are:

• Meaningful to business stakeholders (domain language).
• Of the right granularity, neither too broad nor too detailed.
• Reusable across many tests.
• Independent of the user interface where possible, so they survive UI changes.
• Unambiguous, with clearly defined parameters and a clear expected outcome.

Step 3: Define keyword parameters and documentation. For each keyword, specify:

• Its purpose.
• Its required and optional arguments.
• Its preconditions.
• Its expected behaviour or verification.

Maintain a keyword dictionary so all testers use the same vocabulary.

Step 4: Compose test cases. Arrange keywords in a logical sequence to form a scenario, then add test data and expected results. Example in table form (Keyword | Arg1 | Arg2 | Expected):
Login | user01 | Pass123 | Home page displayed
SearchProduct | Laptop | | Results listed
AddToBasket | Laptop X1 | 1 | Basket count = 1
Checkout | VISA | | Order confirmation shown
VerifyOrderStatus | | | Status = Confirmed
Logout | | | Login page displayed

Step 5: Combine with data-driven techniques. Keyword tests often take data from external tables. One keyword sequence can then run with many data sets, covering equivalence partitions, boundary values or decision table rules.

Step 6: Apply test techniques. Keywords are a format, not a technique. The Test Analyst still uses black-box techniques (equivalence partitioning, BVA, decision tables, state transition, use-case testing) to decide which scenarios and data to include. For example, the transitions of a state model can be mapped to keyword sequences.

Step 7: Hand over and collaborate. The Technical Test Analyst or automation engineer implements the keywords in the test automation framework. Test cases can also be executed manually, because keywords are human-readable.

Step 8: Maintain. When requirements change, update the keyword sequences. When the UI or technology changes, update only the keyword implementation.

Roles

• Test Analyst: Identifies business keywords, composes test cases, provides data and expected results, and validates coverage.
• Technical Test Analyst / Test Automation Engineer: Implements keywords, builds the framework, and handles low-level technical keywords.

Advantages

• Non-technical staff can design automated tests.
• Lower maintenance and high reuse.
• Tests serve as readable documentation.
• Tests can be developed in parallel with the SUT.

Drawbacks and risks

• High initial investment in framework and keyword implementation.
• Poor keyword granularity causes problems. Too fine-grained turns into low-level scripting. Too coarse loses flexibility.
• Keyword proliferation and duplication without governance.
• Requires discipline in naming, documentation and version control.
• Debugging failures can be harder because of the abstraction layers.

4. Comparison with Other Scripting Approaches

• Capture/playback: Recorded scripts are brittle and have high maintenance.
• Linear scripting: Has little reuse.
• Structured scripting: Uses reusable functions but still needs programming.
• Data-driven: Separates data from script, but the script logic is fixed.
• Keyword-driven: Separates both data and actions from the implementation. It has the highest abstraction and suits business users best.

5. Exam Tips: Answering Questions on Keyword-Driven Testing: Composing Keyword Test Cases

• Know the role split. Questions often ask who does what. The Test Analyst identifies keywords and composes test cases from business processes. The Technical Test Analyst implements the keyword scripts. Avoid answers that make the Test Analyst write automation code.
• Keywords should be business-oriented. When asked to choose the best keyword set, pick keywords that reflect business actions (RegisterCustomer, TransferFunds) over GUI actions (ClickOK, TypeField3). GUI-level keywords tie tests to the interface.
• Watch granularity. Prefer keywords that are reusable and meaningful. Reject options where one keyword covers an entire end-to-end test (too coarse) or where each mouse click is a keyword (too fine).
• Composing scenario questions. You may be given a business flow and asked for the correct keyword sequence. Check the following:
  • Preconditions come first (e.g. Login before PlaceOrder).
  • Verification keywords or expected results are included.
  • The correct parameters are passed.
  • The test leaves the system in a defined state (e.g. Logout).
• Missing step detection. A common question type shows a keyword table with an error. Look for missing verification, wrong order, missing data, or a keyword used with the wrong arguments.
• Main benefit = maintainability and separation. If asked for the primary advantage, choose the answer about separating test design from implementation, reducing maintenance, or enabling non-programmers. Do not choose answers that say it finds more defects or removes the need for test techniques.
• Keywords are not a test technique. KDT does not replace equivalence partitioning, boundary value analysis and similar techniques. Those still determine the test conditions and data.
• Manual and automated. Keyword test cases can be run manually as well as automatically. Options saying KDT is only for automation are usually incorrect.
• Data-driven vs keyword-driven. Data-driven separates data only. Keyword-driven also separates the actions. Expect distractors that confuse the two.
• Pitfalls. Expect questions on the high initial effort, the need for a keyword dictionary, and the risk of uncontrolled keyword growth.
• K-level awareness. This topic is often tested at K3 (apply). Practise turning a short requirement into a keyword table with parameters and expected results.
• Eliminate absolutes. Answers with always, never or eliminates (e.g. eliminates maintenance) are usually wrong.
• Read the scenario context. If the scenario mentions frequent UI changes and non-technical testers, KDT is likely the recommended approach. If the project is small and short-term, the investment may not pay off.

6. Quick Worked Example
Requirement: A bank customer can transfer money between their own accounts if the balance is sufficient.

Keywords identified: Login, SelectAccount, TransferFunds, VerifyBalance, VerifyMessage, Logout.

Test case 1 (valid transfer):
Login | cust01 | pw
TransferFunds | ACC1 | ACC2 | 100
VerifyBalance | ACC1 | 400
VerifyBalance | ACC2 | 600
Logout

Test case 2 (insufficient funds, boundary):
Login | cust01 | pw
TransferFunds | ACC1 | ACC2 | 500.01
VerifyMessage | Insufficient funds
VerifyBalance | ACC1 | 500
Logout

Both tests reuse the same keywords with different data, chosen by boundary value analysis.

Summary
Keyword-driven testing lets Test Analysts express tests in a business vocabulary of reusable action words. These words are composed into sequences with data and expected results, while technical staff implement the keywords. For the exam, remember:

• The role separation.
• Business-level keyword selection.
• The right granularity.
• Correct sequencing with verifications.
• The benefits (maintainability, reuse, readability) and the costs (initial investment, governance).