Keyword-Driven Testing
Keyword-Driven Testing (KDT) abstracts automation actions behind human-readable keywords — enabling non-programmers to write and maintain test cases. The test is a sequence of keywords like 'OPEN_BROWSER', 'CLICK', 'VERIFY_TEXT' stored in Excel or CSV. KDT is the architectural foundation of Robot Framework, the most popular keyword-driven test tool in enterprise automation.
KDT Architecture and Robot Framework
# ══════════════════════════════════════════════════════════════
# ROBOT FRAMEWORK (most popular KDT tool)
# pip install robotframework robotframework-seleniumlibrary
# ══════════════════════════════════════════════════════════════
# ── Test file: login_tests.robot ─────────────────────────────
*** Settings ***
Library SeleniumLibrary
Resource keywords/common_keywords.robot
Resource keywords/login_keywords.robot
*** Variables ***
${BASE_URL} https://staging.myapp.com
${BROWSER} headlesschrome
*** Test Cases ***
Valid Login Navigates To Dashboard
[Documentation] TC-AUTH-001: Login with valid credentials
[Tags] smoke auth
Open Browser And Navigate ${BASE_URL}/login ${BROWSER}
Enter Login Credentials alice@test.com Test@1234
Submit Login Form
Verify Dashboard Is Loaded
[Teardown] Close Browser
Invalid Password Shows Error Message
[Documentation] TC-AUTH-002: Invalid password shows error
[Tags] regression auth
Open Browser And Navigate ${BASE_URL}/login ${BROWSER}
Enter Login Credentials alice@test.com wrongpass
Submit Login Form
Verify Error Message Invalid email or password
[Teardown] Close Browser
*** Keywords ***
Open Browser And Navigate
[Arguments] ${url} ${browser}
Open Browser ${url} ${browser}
Maximize Browser Window
Enter Login Credentials
[Arguments] ${email} ${password}
Input Text data-testid=email-input ${email}
Input Password data-testid=password-input ${password}
Submit Login Form
Click Button data-testid=login-btn
Verify Dashboard Is Loaded
Wait Until Location Contains /dashboard
Element Should Be Visible data-testid=welcome-message
Verify Error Message
[Arguments] ${expected_text}
Wait Until Element Is Visible data-testid=error-message
Element Text Should Be data-testid=error-message ${expected_text}
# ── Running Robot Framework ────────────────────────────────────
# robot login_tests.robot ← Run tests
# robot -d results/ login_tests.robot ← Save results
# robot -i smoke login_tests.robot ← Run tagged tests only
# ── Output: robot generates ────────────────────────────────────
# log.html ← Detailed test log with screenshots
# report.html ← Summary report with pass/fail stats
# output.xml ← Machine-readable results for CICommon Mistakes
- Keywords that are too granular — 'Click Something' is not a useful keyword; 'Submit Login Form' is. Keywords should represent meaningful actions
- Not building a shared keyword library — common actions (open browser, login, navigate) must be in shared resource files, not duplicated per test suite
- Ignoring Robot Framework's built-in keywords — SeleniumLibrary already has 200+ keywords for common actions; don't rewrite what already exists
- Using KDT for everything — KDT shines when non-technical users write tests; if only developers write tests, POM + pytest is simpler and more powerful
Tip
Tip
Practice KeywordDriven Testing in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Parameterize with external data.
Practice Task
Note
Practice Task — (1) Write a working example of KeywordDriven Testing from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with KeywordDriven Testing is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Keyword-Driven Testing (KDT) abstracts automation actions behind human-readable keywords — enabling non-programmers to write and maintain test cases.
- Keywords that are too granular — 'Click Something' is not a useful keyword; 'Submit Login Form' is. Keywords should represent meaningful actions
- Not building a shared keyword library — common actions (open browser, login, navigate) must be in shared resource files, not duplicated per test suite
- Ignoring Robot Framework's built-in keywords — SeleniumLibrary already has 200+ keywords for common actions; don't rewrite what already exists