USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. How do you decide what to automate?
Short answer: Automate stable, repetitive, high-value regression tests; not everything.
Strong answer: Automate high-value, repetitive, stable scenarios — core regression, smoke, data-driven and cross-browser flows — where ROI is clear. Skip highly volatile UI, one-off exploratory checks, and things cheaper to test manually. Follow the test pyramid: many unit, fewer integration, fewest UI tests.
Likely follow-up: Why keep UI tests at the top (fewest) of the pyramid?
What the interviewer is checking: Strategy over blind automation.
Common mistake: Automating everything through the slow, brittle UI layer.
Q2. What is the test automation pyramid?
Short answer: Many fast unit tests, some integration tests, few end-to-end UI tests.
Strong answer: The pyramid recommends a large base of fast, cheap unit tests, a middle layer of integration/API tests, and a small top of slow, brittle end-to-end UI tests. Inverting it (mostly UI tests) yields slow, flaky suites. Push coverage down to the lowest layer that can validate the behavior.
Likely follow-up: What’s the "ice-cream cone" anti-pattern?
What the interviewer is checking: Test-strategy understanding.
Common mistake: Relying mostly on UI automation.
Q3. How do you design a maintainable automation framework?
Short answer: Use Page Object Model, clear structure, reusable utilities and stable locators.
Strong answer: Separate test logic from page interaction (Page Object Model or screenplay), centralize configuration and utilities, use stable locators, avoid hard waits, make tests independent and data-driven, and integrate with CI. Maintainability comes from good structure and no duplication, so UI changes touch one place.
Likely follow-up: How does POM reduce maintenance when the UI changes?
What the interviewer is checking: Framework design.
Common mistake: Duplicating locators and logic across tests.
Q4. How do you handle flaky tests?
Short answer: Fix root causes — waits, test data, isolation — rather than blind retries.
Strong answer: Flakiness usually comes from timing (use explicit/auto waits, not sleeps), shared or dirty test data, order dependence, or environment instability. Diagnose with logs/traces/videos, isolate tests, control test data, and stabilize the environment. Retries can mask but shouldn’t replace fixing the cause.
Likely follow-up: Why are hard-coded sleeps a common cause of flakiness?
What the interviewer is checking: Reliability engineering for tests.
Common mistake: Papering over flakiness with automatic retries only.
Q5. How do you integrate automation into CI/CD?
Short answer: Run tests on every change, fast smoke first, full regression on schedule/pipeline gates.
Strong answer: Trigger tests on commits/PRs: fast unit/smoke tests as gates, broader regression on merge or nightly. Run in parallel and in containers for consistency, publish reports and fail the pipeline on regressions. Keep the fast feedback loop tight so tests actually get run.
Likely follow-up: Why split smoke tests from full regression in CI?
What the interviewer is checking: CI integration knowledge.
Common mistake: Running a huge slow suite on every commit, so people skip it.
Q6. How do you approach API test automation?
Short answer: Test endpoints directly for speed and stability, covering contracts and edge cases.
Strong answer: API tests hit endpoints directly (REST/GraphQL), validating status codes, schemas/contracts, data correctness, auth, and error/edge cases — faster and less brittle than UI tests. Use them to cover business logic, reserving UI tests for critical user journeys. Include contract testing between services.
Likely follow-up: Why are API tests less brittle than UI tests?
What the interviewer is checking: Layered testing understanding.
Common mistake: Testing business logic only through the UI.