Q4 of 17 · Framework design

What is a hybrid test automation framework?

Framework designMidframework-designhybridpombdddata-driven

Short answer

Short answer: A hybrid framework combines two or more framework types — most commonly POM + data-driven, or POM + keyword-driven + BDD. It uses each pattern where it provides value rather than forcing everything into one approach.

Detail

Pure framework types have trade-offs:

  • POM only — great for maintainability, poor for non-technical test authoring
  • Data-driven only — great for parameterisation, poor for complex multi-page flows
  • Keyword-driven only — non-technical authors can write tests, but keyword maintenance is heavy
  • BDD only — best stakeholder collaboration, but overhead for technical/API tests

Hybrid combinations in practice:

POM + Data-driven (most common):

  • Page Objects own locators and actions (POM)
  • Test data read from JSON/CSV (data-driven)
  • Tests are parameterised templates calling PO methods with external data

POM + BDD + Data-driven (full stack):

  • Gherkin feature files (BDD) describe behaviour scenarios
  • Step definitions call Page Objects (POM)
  • Scenario Outlines with Examples tables provide parameterisation (data-driven)

Example structure:

framework/
  pages/          ← POM layer
  step-defs/      ← BDD layer
  testData/       ← Data-driven layer
  features/       ← Gherkin
  utils/          ← Shared helpers
  config/         ← Environment config

The key principle: Use each pattern where it solves a real problem. Don't implement a keyword-driven layer "for completeness" if no non-technical stakeholders will write keywords.

Senior signal: Being able to explain which combination fits a given team's tech stack, test types, and stakeholder involvement — rather than prescribing one universal answer.

// WHAT INTERVIEWERS LOOK FOR

Definition of at least two combined patterns. A concrete example structure. The 'use each pattern where it adds value' principle rather than a dogmatic answer.