Test Framework Architecture

A crisp, ordered walkthrough (goal/scope -> layers -> POM -> config/env -> fixtures -> data -> patterns -> reporting -> CI -> scale -> trade-offs) that frames you as the framework OWNER, not a script-adder.

Asked 'How would you design a test automation framework from scratch?' / 'Walk me through YOUR framework.' (near-guaranteed anchor question)

named in the job descriptions

The central pytest config: registered markers, addopts, testpaths, log_cli, and plugin settings.

Asked 'Where do you register markers / set default options?' / live-coding a config file

asked in interviews, not named in any job description

Standard folders (tests/ pages/ api/ utils/ config/ testdata/ reports/ + conftest.py + pytest.ini/pyproject.toml) each with a single responsibility so a UI change touches one layer.

Asked 'How is your framework structured / organised?' / 'Where does test logic vs page logic vs infra live?'

named in the job descriptions

Encapsulation, inheritance, composition, polymorphism as used in a framework (BasePage inheritance, encapsulated locators).

Asked 'Explain OOP concepts with a testing example' (frequent warm-up)

named in the job descriptions

One class per page/component; locators are class attributes, business actions are methods (login(user,pw) not raw fills) so tests read like business steps and a UI change is fixed in one place.

Asked 'How do you structure UI tests?' / 'What is POM and why use it?' / live-code a page object

named in the job descriptions

A shared BasePage (common waits/actions), methods that return the next page object (fluent chaining), and component objects (header, modal) vs full-page objects.

Asked 'How do you avoid duplication across pages?' / 'What's a fluent page object?'

named in the job descriptions

One shared instance with a global access point; classic framework use = single config/logger (and, in Selenium, one WebDriver).

Asked 'What is the Singleton pattern and why do you need it in a framework?' (most-asked pattern question)

asked in interviews, not named in any job description

Create an object (browser/driver, API client) from config behind one interface without the caller naming the concrete class.

Asked 'What is the Factory pattern - give a framework use case?' / 'How do you add cross-browser support without rewriting tests?'

asked in interviews, not named in any job description

POM is itself the canonical test design pattern; encapsulate UI so change is localized.

Asked 'Which design patterns have you used in your framework?'

named in the job descriptions

Swap behavior at runtime selected from config - e.g. auth strategy (token vs cookie vs SSO) or data-source strategy.

Asked 'How would you support multiple auth mechanisms / environments cleanly?'

asked in interviews, not named in any job description

Fluent construction of complex objects (UserBuilder().with_role('admin').with_kyc(False).build()) instead of giant dict literals.

Asked 'How do you construct complex test data?' / 'name a pattern beyond POM'

asked in interviews, not named in any job description

conftest.py shares fixtures with no import; scopes (function/class/module/package/session) control lifetime; browser/page lifecycle lives here.

Asked 'Difference between conftest.py and a normal fixture file?' / 'Explain fixture scopes' / live-code a fixture with teardown

named in the job descriptions

autouse fixtures run without request; yield/addfinalizer handle finalization; nested conftest.py files override/extend parent ones.

Asked 'How does teardown work?' / 'What is autouse?' / 'How do fixtures compose across dirs?'

asked in interviews, not named in any job description

pytest-playwright ships page/context/browser fixtures; each test gets an isolated browser context (clean state), distinct from a shared Selenium driver.

Asked 'How does Playwright isolate tests?' / 'How do you reuse login state?'

asked in interviews, not named in any job description

Extend pytest: add CLI flags (--env/--browser), dynamically parametrize from a flag, and screenshot/trace-on-fail via the makereport hook.

Asked 'Have you written a custom pytest plugin/hook?' / live-code a --browser option via pytest_addoption

asked in interviews, not named in any job description

No hardcoded URLs/creds; config in JSON/YAML/.env; one suite runs any environment by flipping a flag.

Asked 'How do you manage running in different environments?' / 'Where do base URLs/timeouts live?'

named in the job descriptions

Credentials via env vars / CI secrets / a vault - never committed to the repo.

Asked 'How do you manage credentials/secrets inside your framework?' (named question)

asked in interviews, not named in any job description

@pytest.mark.parametrize and external JSON/CSV: one test, many data rows; know its limits (data explosion, readability).

Asked 'How do you handle test data / run one test over many inputs?' / live-code parametrization from JSON

asked in interviews, not named in any job description

Keyword-driven = actions abstracted as keywords (Robot Framework); hybrid = data+POM(+BDD) combined = what most real frameworks are.

Asked 'Data-driven vs keyword-driven vs hybrid - differences and when to use each?'

named in the job descriptions

Given/When/Then business-readable specs mapped to step defs; pros (stakeholder readability) vs cons (ceremony/overhead).

Asked 'Have you used BDD/Cucumber?' / 'When is BDD worth it?'

named in the job descriptions

Load JSON/CSV via a util; generate volume with faker/factories; make data unique per worker so parallel runs don't collide; DB seed/cleanup.

Asked 'How do you handle test data?' / 'How do you keep data safe under parallel runs?'

named in the job descriptions

Custom explicit waits (not sleep), a thin requests/API-client wrapper (base URL + auth injection + response validation), logging config, custom/soft assertions.

Asked 'What reusable utilities does your framework provide?' / 'How do you handle waits?'

named in the job descriptions

Rich reports (Allure steps/attachments/trends or pytest-html), JUnit XML for CI, screenshot + Playwright trace attached on failure.

Asked 'What kind of reports do you generate?' / 'How do you capture evidence on failure?'

named in the job descriptions

Explicit waits over sleeps, test isolation, deterministic data, idempotent setup/teardown; pytest-rerunfailures sparingly WITH root-cause culture.

Asked 'How do you handle flaky tests?' (very common)

named in the job descriptions

collection -> fixture/setup -> test -> teardown -> report/exit-code; the lifecycle pytest drives.

Asked 'Tell me about the execution flow of your framework.'

asked in interviews, not named in any job description

@pytest.mark.smoke/regression/sanity, -m selection, markers registered in config; CI triggers the right subset.

Asked 'How do you select which tests run in which pipeline?'

asked in interviews, not named in any job description

Tests run on push/PR: checkout -> deps -> run -> upload artifacts -> exit code gates the pipeline; smoke on every push, regression nightly, selected via marks.

Asked 'What's your CI strategy?' / 'How does your suite run automatically?' / 'Smoke vs regression triggers?'

named in the job descriptions

pytest -n auto (xdist), --dist loadscope/loadgroup; requires independent tests, no shared mutable state, isolated Playwright contexts, unique data per worker.

Asked 'How do you run tests in parallel? What breaks when you do?' / 'How did you cut regression time?'

named in the job descriptions

AI/LLM-driven test generation, self-healing locators (Healenium/Mabl), and agent-based test creation as maintainability/coverage multipliers - a 2026 framework theme and this candidate's genuine edge.

Asked 'How could AI improve/maintain your framework?' / 'Have you used AI-assisted testing tools?' (rising in 2026)

named in the job descriptions

Framework as a versioned pip-installable package reused across teams, and a real pytest plugin distributed via entry points (not just conftest hooks).

Asked 'How would you make the framework reusable across multiple teams?'

named in the job descriptions

Dockerized runs, Selenium Grid / Playwright grid / BrowserStack-LambdaTest, and matrix/sharded parallelism across CI runners.

Asked 'How do you scale cross-browser at high volume?'

named in the job descriptions

Consumer-driven contract tests and mock servers to isolate services in API testing.

Asked 'How do you test a service whose dependencies aren't ready?'

named in the job descriptions