Data-driven vs keyword-driven vs BDD vs hybrid frameworks: what is the difference?

These are ways of organising how test logic and test data are expressed. They are not mutually exclusive, and most production frameworks combine them, so the useful answer explains what each one optimises for.

Data-driven

The test logic is written once and executed against many data sets. The data lives in parameters, CSV, JSON or a database rather than being hard-coded.

@ParameterizedTest
@CsvSource({
    "standard_user, secret_sauce, true",
    "locked_out_user, secret_sauce, false",
    "standard_user, wrong_password, false"
})
void login(String user, String password, boolean shouldSucceed) {
    LoginPage page = new LoginPage(driver).open();
    page.loginAs(user, password);
    assertEquals(shouldSucceed, page.isLoggedIn());
}

Good for: validation rules, boundary values, permission combinations, calculations. Watch out for: giant spreadsheets nobody owns, and rows so different that they really need different assertions.

Keyword-driven

Steps are expressed as keywords such as Open Browser, Login As, Verify Order Total, implemented once in code and composed into tests, often in tables. Robot Framework is the best-known example. The idea is that people who do not write code can assemble tests from a keyword library.

Good for: teams where many testers do not program and the domain has stable, reusable actions. Watch out for: keyword libraries that grow into a poorly designed programming language without IDE support, refactoring tools or type checking.

Behaviour-driven development (BDD)

BDD is a collaboration practice first and a test format second. Product, development and QA agree on examples before building, written in Gherkin:

Feature: Checkout discounts
  Scenario: Loyalty members get 10% off orders over 50
    Given a loyalty member with 60.00 in their basket
    When they check out
    Then the order total is 54.00

Tools like Cucumber map each step to code. Good for: shared understanding when business stakeholders actually read and review the scenarios. Watch out for: using Gherkin with no collaboration, which adds a step-definition layer, regex glue and a second place for logic without any benefit. If nobody outside QA reads the feature files, plain code with good names is usually cheaper.

Hybrid

Most real frameworks are hybrids: tests written in code, page objects or API clients for interaction, parameterized data for variations, and sometimes BDD for the subset of scenarios the business cares to review. That is a sensible default.

How I would choose

• Who writes and reads the tests? Developers and SDETs favour code-first; mixed-skill teams may benefit from keywords.
• Is there a business audience for the specifications? If yes, BDD can pay off.
• How much data variation is there? Lots of variation means data-driven techniques.

What interviewers look for

• Clear, correct definitions of each approach.
• An honest view of trade-offs, especially BDD overhead without collaboration.
• Recognition that hybrids are normal and that the choice depends on the team.

Common mistakes

• Calling any Cucumber project “BDD” regardless of how scenarios are written.
• Assuming keyword-driven means no programming is needed at all; someone still has to build and maintain the keyword library.