Keyword-Driven Testing: Specifying Keywords and Abstraction Layers (ISTQB CTAL-TA Guide)
Introduction
Keyword-driven testing (KDT) is a key topic in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. It sits in the area that describes how the Test Analyst contributes to the test process, particularly during test design and test implementation. The ISO/IEC/IEEE 29119-5 standard formalises the approach. For the exam, you need to know what keywords are, how they are specified at different levels of abstraction, and what the Test Analyst does compared with the Technical Test Analyst or test automation engineer.
Why Keyword-Driven Testing Is Important
KDT matters for several reasons.
1. It separates test design from test implementation. Domain experts and Test Analysts can write tests in business language. Technical specialists build the code that makes those keywords executable.
2. It improves maintainability. If the user interface or technical implementation changes, often only the implementation of a keyword needs updating. The many test cases that use the keyword can stay as they are.
3. It enables reuse. Keywords such as Login, Create Customer or Verify Balance can be reused across many test cases and test suites.
4. It brings in non-technical stakeholders. Business analysts, users and domain experts can read, review and even write test cases without programming skills.
5. It supports both manual and automated execution. Keyword-driven test cases can be run manually by a tester or automatically by a framework. This makes the transition to automation smoother.
6. It reduces cost over time. The upfront investment pays back through lower maintenance effort and faster creation of new tests.
What Is Keyword-Driven Testing?
Keyword-driven testing is a scripting technique. Test cases are expressed as a sequence of keywords (also called action words) together with the test data (parameters) each keyword needs. A keyword represents an action or a set of actions that a user, or the test, performs against the system under test (SUT).
Example of a keyword-driven test case:
Login | user=jsmith | password=Secret1
Open Account | type=Savings
Deposit | amount=500
Verify Balance | expected=500
Logout
Each line is one keyword with its arguments. The test case reads like business language, while the technical details are hidden inside the keyword implementation.
Key Terminology
Keyword: one or more words that refer to an action or set of actions to be performed, with the data needed.
Simple (atomic) keyword: a keyword that cannot be broken down further and maps directly to an executable action, for example Click Button or Enter Text.
Composite keyword: a keyword built from other keywords (simple or composite), for example Login made up of Enter Username, Enter Password and Click Login.
Keyword library / dictionary: the managed collection of defined keywords with their descriptions and parameters.
Keyword implementation (script): the executable code, or the manual instructions, behind a keyword.
Test execution framework / keyword interpreter: the tool component that reads the keyword-driven tests and calls the corresponding implementations.
Abstraction Layers
A central idea in KDT is that keywords exist at different levels of abstraction. ISO/IEC/IEEE 29119-5 and the ISTQB syllabus describe a layered approach.
1. Business / domain layer (high-level keywords)
These keywords describe business processes or user goals in the language of the domain, for example Purchase Product, Approve Loan or Register New Patient. They are independent of the user interface and the technology. This is the layer where Test Analysts and domain experts mainly work.
2. Intermediate / functional layer (mid-level keywords)
These keywords represent functional steps that make up business processes, for example Search Product, Add To Cart or Enter Payment Details. They are usually composite keywords made of lower-level keywords.
3. Technical / interface layer (low-level keywords)
These keywords interact directly with the SUT interface, for example Click, Type Text, Select From List or Call API. They are generally simple or atomic and are implemented by technical specialists.
Higher-level keywords are composed of lower-level ones. This creates a hierarchy that hides technical detail from business-focused tests.
Some frameworks also make a further split between domain-specific keywords and test-interface (technical) keywords. Another distinction is framework support keywords, such as setup, teardown and logging.
How Keyword-Driven Testing Works: Specifying Keywords
The Test Analyst plays a major role in identifying and specifying keywords. A typical process looks like this.
Step 1: Analyse the test basis. Review requirements, user stories, business processes and use cases. Find the recurring actions and business tasks.
Step 2: Identify candidate keywords. Pick actions that are meaningful to stakeholders and likely to be reused. Name them clearly using domain vocabulary, typically as verb + object (for example Create Order).
Step 3: Decide on the level of abstraction. Decide whether each keyword is a high-level business keyword or a lower-level functional keyword. Avoid mixing levels inside the same test case, since this hurts readability and maintenance.
Step 4: Define parameters. Specify what data each keyword needs (input and expected values). Well-chosen parameters make keywords flexible and reusable.
Step 5: Document each keyword. A good keyword specification includes:
- a unique, meaningful name
- a description of its purpose
- its parameters (name, type, mandatory or optional, valid values)
- preconditions and postconditions
- expected results or verification behaviour
- the lower-level keywords it consists of, if it is composite
Step 6: Build test cases from keywords. Combine keywords into test procedures, often in tables or spreadsheets, and supply the test data.
Step 7: Implement the keywords. Technical Test Analysts or automation engineers write the scripts behind the low-level keywords. Alternatively, they write manual instructions if execution is manual.
Step 8: Maintain the keyword library. Manage keywords under configuration control. Avoid duplicates and synonyms, and refactor when needed.
Roles
Test Analyst: identifies business-level keywords, specifies keywords and their parameters, designs test cases using keywords, and works with domain experts.
Technical Test Analyst / Test Automation Engineer: implements low-level keywords, builds and maintains the framework, and ensures technical robustness.
Domain experts: help define and validate business keywords and may write test cases.
Benefits Summary
- Tests are readable by non-technical stakeholders
- Test case design is separated from implementation
- Maintenance is reduced, because changes are localised in keyword implementations
- Reuse of keywords is high
- Test case development can start before the SUT is available
- Both manual and automated execution are supported
Challenges and Risks
- Initial investment in framework and keyword design is high
- There is a risk of too many keywords, duplicates or poor naming (keyword explosion)
- Choosing the right granularity is difficult: keywords that are too fine make tests long, and keywords that are too coarse limit reuse
- Keyword libraries need governance and configuration management
- Test Analysts and technical staff must coordinate closely
Good Practice for Specifying Keywords
- Use consistent naming conventions in domain language
- Keep each keyword focused on a single purpose
- Keep the abstraction level consistent within a test case
- Make keywords independent and reusable
- Use parameters instead of hard-coded data
- Document every keyword in a central dictionary
- Review keywords with stakeholders
Exam Tips: Answering Questions on Keyword-Driven Testing: Specifying Keywords and Abstraction Layers
Tip 1: Know the main benefit. When asked for the main advantage, look for answers about separating test design from technical implementation, maintainability or enabling non-technical stakeholders to create tests. Be careful with answers claiming KDT removes all maintenance or needs no technical skills at all.
Tip 2: Distinguish the roles. The Test Analyst specifies keywords from a business or domain perspective and designs keyword-driven test cases. Implementing the scripts behind keywords is usually the Technical Test Analyst's or automation engineer's job. If an option says the Test Analyst writes the low-level automation code, it is likely wrong.
Tip 3: Recognise abstraction levels. Be ready to classify a keyword as high-level (business process), mid-level (functional step) or low-level (UI/technical interaction). Approve Insurance Claim is high-level. Click OK Button is low-level.
Tip 4: Composite vs simple keywords. Composite keywords are made of other keywords. Simple or atomic keywords cannot be broken down further and map directly to implementation code.
Tip 5: Scenario questions. If a scenario describes frequent UI changes breaking many tests, the best answer often involves keyword-driven testing with layered keywords. With that structure, only low-level keyword implementations need updating.
Tip 6: Watch for mixing levels. A test case that mixes business keywords with low-level UI actions is poor practice. Questions about the quality of a keyword-driven test often target this.
Tip 7: Remember what goes into a keyword specification. Name, description, parameters, preconditions, expected results and composition are typical. Implementation code details are not part of the Test Analyst's business-level specification.
Tip 8: Link to the test process. Keyword identification happens during test analysis and design. Building test procedures from keywords happens in test implementation. Running them happens in test execution, either manually or automatically.
Tip 9: Remember ISO/IEC/IEEE 29119-5. This is the standard for keyword-driven testing. Recognising it may help with knowledge-level questions.
Tip 10: Eliminate absolute statements. Options containing words like always, never, eliminates or no maintenance are usually incorrect. KDT reduces effort but does not remove it.
Tip 11: Choose granularity wisely. When asked how to define good keywords, prefer answers that balance reuse and readability. Keywords should be meaningful to stakeholders, reusable and parameterised.
Tip 12: Differentiate from data-driven testing. Data-driven testing separates test data from scripts, so the same script runs with many data sets. Keyword-driven testing separates both actions (keywords) and data from implementation. KDT often includes data-driven elements, but its defining feature is the use of keywords.
Sample Question Approach
Question: A team wants business analysts to create automated tests without programming. They also want to minimise maintenance when the UI changes. Which approach best supports this?
Reasoning: Look for keyword-driven testing with business-level keywords. Their low-level implementations should be maintained by technical staff. Reject capture/replay, which is brittle, and pure linear scripting, which is hard to maintain.
Summary
Keyword-driven testing lets Test Analysts express tests in business language using reusable keywords. These keywords are arranged in abstraction layers, from high-level business keywords to low-level technical actions. Specifying keywords well means clear naming, parameters, documentation and consistent abstraction levels. For the exam, focus on the benefits, the abstraction layers, simple vs composite keywords, the separation of roles between Test Analyst and Technical Test Analyst, and scenario-based reasoning about maintainability and stakeholder involvement.
