How would you design an automation framework from scratch for a new product?
60-second answer
I'd start with context, not tools: the product's architecture, tech stack, team skills, release cadence, risks and what's already tested at unit level. Then I'd define a strategy with the test pyramid, deciding what to cover at API, UI and contract levels. I'd choose tools that fit the stack and team, for example Playwright with TypeScript for a React app and its APIs. I'd build a thin vertical slice first, a few critical tests running in CI with reporting, show value, then grow it with conventions, code reviews and documentation, measuring speed, stability and coverage.
Explanation
Steps:
- Discover: architecture, environments, deployment process, pain points, stakeholders.
- Strategy: scope, levels, ownership (devs write unit/component, SDETs drive API/E2E/contract).
- Tool selection: language aligned with developers, community, CI fit, licensing, PoC with 2–3 options.
- Foundations: project structure, config, data strategy, auth shortcut, reporting, parallelism, linting.
- CI first: run on every PR from day one.
- Scale: templates, docs, pairing, contribution guidelines.
- Measure: run time, flaky rate, escaped defects, coverage of critical journeys.
Example
For a fintech startup: Playwright TS for UI and API in the same repo as the frontend, Pact for service contracts, k6 for performance. The first week delivered 10 critical journey tests in GitHub Actions with traces; by month three, 300 tests ran in 12 minutes on every PR.
Sample code
ADR-001 UI/E2E tool
Context : React SPA + Node BFF, devs use TypeScript, deploy 10x/day
Options : Selenium+Java, Cypress, Playwright
Decision: Playwright (TS) - same language as devs, multi-browser, API testing,
tracing, parallel/sharding built in
Consequences: Safari covered via WebKit; real-device mobile stays on Appium/BrowserStack