Framework Design Interview Questions

Data-driven frameworks run the same test logic against many input rows. Keyword-driven frameworks describe steps as reusable keywords, often in tables. BDD writes behaviour as Given/When/Then scenarios shared with the business. Most real frameworks are hybrids: code-first tests, parameterized data and page objects.

Separate concerns: tests that read like scenarios, a domain or flow layer, interaction layers (page or component objects, API clients), core utilities (driver lifecycle, config, data builders, waits), and reporting. Dependencies point downward only, so a UI change touches one page object, not hundreds of tests.

Prefer each test creating the data it needs through APIs or builders, with unique values so tests can run in parallel and in any order. Keep shared seed data read-only, clean up or use disposable environments, never rely on production copies with real personal data, and keep data creation out of the UI.

Keep one typed config object loaded in a clear precedence order: defaults, then an environment file selected by a single variable, then environment variables or CLI overrides. Never commit secrets; inject them from the CI secret store or a vault at runtime, mask them in logs, and fail fast on missing values.

First reduce what must run as UI tests by pushing checks down to API and component level. Then make every test independent with API-based setup and reused auth state, shard across many parallel workers on scalable infrastructure, balance shards by historical duration, and track flaky and slow tests as defects.

Start with a clear reason and a measured baseline, prove value with a pilot, then migrate incrementally while both suites run. Prioritise high-value and flaky tests, rewrite rather than transliterate (auto-waiting locators, fixtures, API setup), delete low-value tests, and retire the old suite in planned stages.