QA Automation Interview Questions

The test pyramid (by Mike Cohn) recommends writing many unit tests (base), fewer integration tests (middle), and fewest E2E tests (top). It matters because unit tests are fast/cheap while E2E tests are slow/expensive/flaky. A pyramid-shaped suite gives fast feedback and is cost-effective to maintain. The anti-pattern is the "ice cream cone" — mostly E2E with few unit tests — which is slow, brittle, and expensive.

Verification: "Are we building the product right?" — checking that the code meets specifications (unit tests, code reviews, static analysis). Validation: "Are we building the right product?" — checking that the product meets user needs (UAT, beta testing, usability studies). Both are part of QA — verification ensures correctness, validation ensures usefulness.

Regression testing verifies that previously working features still work after code changes. It catches unintended side effects. Run it: on every PR (automated in CI), after bug fixes (to ensure the fix doesn't break something else), before releases (full regression suite), and after refactoring (to verify behavior is preserved). Automation is essential — manual regression doesn't scale.

Smoke testing: A broad, shallow check of critical functionality — "does the app start? can users login? does the main page load?" Run after a new build/deploy. Sanity testing: A narrow, focused check of a specific feature or bug fix — "does the discount calculation work after the fix?" Both are quick, but smoke tests are wide and sanity tests are deep.

Black-box testing: Test the software from the outside — you know the inputs and expected outputs but not the internal code. E2E tests and UAT are black-box. White-box testing: Test with knowledge of the internal code structure — you design tests to cover specific branches, paths, and conditions. Unit tests are typically white-box. Most test strategies combine both approaches.

Unit testing: Test individual functions/methods in isolation. Integration testing: Test how modules work together (e.g., API + database). System testing: Test the complete application as a whole. Acceptance testing (UAT): Verify the system meets business requirements from the user's perspective. Each level catches different types of bugs — unit tests catch logic errors, integration tests catch interface mismatches, system tests catch workflow issues.

Automate: Repetitive tests (regression), tests that run frequently (CI), data-driven tests with many inputs, tests across multiple browsers/devices, and tests that require precise timing. Keep manual: Exploratory testing (discovering unknown bugs), usability testing (subjective), one-time tests, tests for features still changing rapidly, and visual/UX validation. The rule of thumb: if you'll run it more than 3 times, automate it.

POM is a design pattern that encapsulates UI elements and interactions for each page in a dedicated class. Test methods call page object methods instead of using selectors directly. It's important because: (1) when UI changes, you update one class instead of every test, (2) it makes tests more readable — loginPage.login(user, pass) vs raw selectors, (3) it reduces code duplication, and (4) it separates test logic from page structure.

Good tests are: (1) Independent — no dependency on other tests or execution order. (2) Deterministic — same result every time with same code. (3) Focused — test one thing, with a clear name that describes the scenario. (4) Fast — run in seconds (especially unit tests). (5) Maintainable — use setup/fixtures, avoid magic numbers, follow AAA pattern (Arrange-Act-Assert). A test that's flaky, slow, or hard to understand is worse than no test.

Boundary value analysis tests at the edges of input ranges — where bugs are most common. For a field accepting 1-100: test 0 (below min), 1 (min), 2 (just above min), 99 (just below max), 100 (max), and 101 (above max). This catches off-by-one errors and boundary mishandling with fewer test cases than testing every possible value.

Equivalence partitioning divides inputs into groups (partitions) where all values in a group should produce the same behavior. You test one value from each partition instead of exhaustive inputs. For a "valid age" field (18-65): partitions are {< 18}, {18-65}, {> 65}. Test one from each: 10, 30, 80. Combined with boundary values, this gives excellent coverage with minimal test cases.

Test data management ensures tests have predictable, isolated inputs. Challenges: (1) Shared data causes flaky tests when tests run in parallel or different order. (2) Production data may contain PII and can't be used directly. (3) Complex data relationships are hard to set up (e.g., user → orders → payments). Solutions: fixtures, factory libraries (Factory Boy, Faker), database transactions rolled back after each test, and test containers with fresh databases.

Selenium: Best for multi-language teams, legacy suites, and mobile testing (via Appium). Widest language support but requires explicit waits. Cypress: Best for JavaScript-heavy teams. Runs in-browser with great DX (time travel, auto-reload) but limited to JS and one browser tab. Playwright: Best for new projects — auto-wait, multi-browser, multi-language, built-in codegen and trace viewer. Default choice for modern browser testing.

Playwright automatically waits for elements to be visible, enabled, and stable before interacting. With Selenium, you must add explicit waits (WebDriverWait) — if you wait too little, the test fails because the element isn't ready; too much and the test is slow. Auto-wait eliminates this guesswork. It checks actionability in a retry loop, handling dynamic content, animations, and network delays without explicit timeout configuration.

pytest fixtures are dependency-injected setup functions. Unlike setUp (runs before every test in a class), fixtures are explicit — each test declares which fixtures it needs as parameters. Fixtures can depend on other fixtures, have scopes (function/class/module/session), and use yield for teardown. This is more flexible and readable: a test that needs only a database connection doesn't get a full user/API/browser setup.

Mocking replaces real dependencies with fake implementations that return predefined responses. Use it when: testing against external APIs (avoid real HTTP calls), testing error paths (mock a failure), isolating unit tests from databases/network, and testing time-dependent code (mock the clock). Don't overuse it — mocked tests can pass while the real integration fails. Integration tests should hit real services.

Strategies: (1) API login — call the auth endpoint directly to get tokens, faster than UI login. (2) Stored auth state — Playwright's storageState saves cookies/localStorage after one login and reuses across tests. (3) Test user accounts — dedicated accounts that don't expire or require MFA. (4) Auth bypass — test environment flag that skips auth for non-auth tests. Never hardcode credentials; use environment variables or secrets.

A test framework provides the structure for writing and running tests — assertions, test discovery, reporting (pytest, JUnit). A test harness is the broader infrastructure: test data setup, environment configuration, mock servers, database seeds, reporting dashboards, and CI integration. The framework is a library; the harness is everything you build around it to make testing work for your project.

Stages in order: (1) Lint/format check (~30s) — catch style issues early. (2) Unit tests (~1-2 min) — fast feedback on logic errors. (3) Integration tests (~3-5 min) — verify API/DB interactions with service containers. (4) E2E tests (~5-10 min, parallelized) — validate critical user flows. Each stage is a quality gate — failure stops the pipeline. Upload JUnit XML and failure artifacts. Configure branch protection to require all checks.

Quality gates are automated pass/fail checkpoints that block code from proceeding if it doesn't meet criteria: all tests pass, code coverage ≥ threshold, no new lint errors, no security vulnerabilities, performance budgets met. They're enforced via branch protection rules (GitHub) or pipeline conditions (Jenkins). Without them, broken code can merge to main and affect the whole team.

(1) Identify — track which tests fail intermittently (most CI tools have flaky test detection). (2) Retry — auto-retry failures 1-2 times; if it passes on retry, mark as flaky. (3) Quarantine — move persistently flaky tests to a non-blocking job. (4) Fix root cause — usually timing issues (add proper waits), shared state (isolate test data), or external dependencies (mock them). (5) Metrics — track flaky rate as a team KPI, aim for < 2%.

Cache dependencies (pip, npm, browsers) — saves 2-5 min. Parallelize tests — use pytest-xdist or matrix strategy to shard across workers. Run independent jobs concurrently — lint and unit tests don't depend on each other. Skip irrelevant tests — use path filters to only run affected test suites. Use faster runners — larger GitHub Actions runners or self-hosted with warm caches. Profile and optimize — find the slowest tests and improve or delete them.

Always: JUnit XML results (for CI dashboard), code coverage reports (for trend tracking). On failure: screenshots at failure point, Playwright traces (full replay), application logs. Optional: HTML reports (Allure for rich visualization), performance metrics, dependency audit results. Use if: always() for reports you always need and if: failure() for expensive debug artifacts.

Key metrics: (1) Defect escape rate — bugs found in production that tests should have caught (trending down = good). (2) Test pass rate — should be > 98%; lower indicates quality issues or flakiness. (3) Flaky test rate — < 2% target. (4) Time to feedback — how fast devs get test results. (5) Code coverage — 70-90% is healthy; 100% is counterproductive. (6) Mean time to detect (MTTD) — how quickly after a bug is introduced it's caught by tests.

Shift-left testing means moving testing earlier in the development lifecycle. Instead of testing after code is "done," test during and before development: static analysis in IDE, unit tests written alongside code (or TDD), code review for testability, integration tests in CI, and requirements review before coding. Earlier bugs are found, cheaper they are to fix — a bug caught in design costs 100x less than one found in production.

TDD follows a Red-Green-Refactor cycle: (1) Write a failing test first (Red). (2) Write minimal code to make it pass (Green). (3) Refactor while keeping tests green. Benefits: you always have tests (no "I'll add tests later"), tests drive better API design (you think about usage first), and you get a safety net for refactoring. Criticism: can be slow for exploratory/prototype work and may lead to over-testing trivial code.

BDD extends TDD by writing tests in natural language that stakeholders can read: "Given a logged-in user, When they click 'Add to Cart', Then the item count increases by 1." Tools like Cucumber/Behave translate these into executable tests. BDD focuses on business behavior while TDD focuses on technical correctness. BDD is great for bridging the gap between business and engineering but adds a translation layer that can be overhead for purely technical teams.

Microservice testing strategy: (1) Unit tests — within each service (standard). (2) Contract tests — verify that service A's expectations of service B's API match reality (Pact, Spring Cloud Contract). (3) Integration tests — test service + its database using TestContainers. (4) E2E tests — minimal, testing critical cross-service flows. (5) Consumer-driven contracts — each consumer defines what it needs; the provider verifies it can deliver. Contract tests are the key differentiator — they catch interface mismatches without running all services.

API testing sends HTTP requests directly to backend endpoints and validates responses (status codes, JSON structure, data). UI testing interacts with the application through the browser like a real user. API tests are faster (no browser overhead), more stable (no UI flakiness), and test business logic directly. UI tests validate the full user experience but are slower and more brittle. A good strategy: test most logic via API tests, and use UI tests only for critical user journeys.

Key components to estimate: (1) Framework setup — project structure, CI integration, reporting (1-2 weeks). (2) Core utilities — base page objects, API client, test data factory, config management (2-3 weeks). (3) First test suite — smoke tests for critical flows (1-2 weeks). (4) Team enablement — documentation, templates, pairing sessions (ongoing). Factor in: team's experience with chosen tools, application complexity, and environment setup needs. A realistic estimate for v1 is 4-8 weeks for an experienced SDET.

Visual regression testing takes screenshots of UI components and compares them pixel-by-pixel (or perceptually) against baseline images. It catches layout shifts, font changes, and styling regressions that functional tests miss. Tools: Playwright's screenshot comparison, Percy, Chromatic, BackstopJS. Challenge: pixel diffs are sensitive to rendering differences across OSes, so most tools use perceptual comparison with configurable thresholds.

Load testing: Can the system handle expected user load? (e.g., 1000 concurrent users). Stress testing: What happens beyond normal load? Find the breaking point. Spike testing: Can the system handle sudden traffic bursts? Soak testing: Does performance degrade over extended periods? (memory leaks, connection pool exhaustion). Benchmark testing: Measure baseline performance for comparison. Tools: k6, JMeter, Locust, Artillery.

Chaos engineering deliberately introduces failures (network latency, server crashes, disk full) to verify the system handles them gracefully. It goes beyond traditional QA by testing resilience, not just correctness. While QA asks "does it work?", chaos engineering asks "what happens when things break?" Tools: Chaos Monkey (Netflix), Gremlin, Litmus. QA teams increasingly own resilience testing as systems become more distributed.

Current applications: (1) Self-healing locators — tools like Testim use ML to update selectors when UI changes. (2) Test generation — AI analyzes code changes and suggests test cases. (3) Flaky test detection — ML models predict which tests are likely to be flaky. (4) Visual testing — AI-powered perceptual comparison ignores irrelevant rendering differences. (5) Test prioritization — ML ranks tests by likelihood of catching bugs in changed code. AI augments, not replaces, human testing judgment.

Contract testing verifies that two services (consumer and provider) agree on their API interface — request/response format, status codes, and data types. Used primarily in microservice architectures where E2E testing is impractical. The consumer writes a "contract" defining what it expects; the provider verifies it can fulfill it. Tools: Pact is the most popular. Contract tests are faster and more reliable than cross-service integration tests.

(1) Don't automate everything at once. Start with smoke tests for the most critical user flow (login, core feature). (2) Set up the framework and CI pipeline first — the infrastructure matters more than the first tests. (3) Add unit tests for new code (going forward) — don't try to backfill 100% coverage. (4) Identify the top 10 most-reported bugs and write regression tests for them. (5) Pair with developers to establish testing culture. (6) Track and share metrics to show progress. Quick wins build momentum.

(1) Write a failing test that reproduces the bug — before fixing. This ensures the fix actually addresses the issue. (2) Fix the bug and verify the test passes. (3) Root cause analysis: Why did existing tests miss it? Was it a gap in test coverage, wrong test data, untested edge case, or wrong assumptions? (4) Add similar tests for related edge cases in the same area. (5) Update test strategy if the gap reveals a systematic blind spot. Document the incident as a learning for the team.

(1) Show the data: track time spent on bug fixes vs. time to write tests. Teams without tests spend 40%+ of time on bugs. (2) Make it easy: provide test templates, clear examples, and CI that runs automatically. (3) Start small: require tests only for bug fixes (test that the bug is fixed) — this is low effort with clear value. (4) Lead by example: write tests for shared code and show how they catch regressions. (5) Quality gates: require tests for PRs, but make the bar achievable (new code must be tested, not legacy code).

Prioritize by: (1) Business criticality — automate tests for revenue-generating features first (checkout, payments, sign-up). (2) Frequency of execution — tests you run every day get more automation ROI than quarterly tests. (3) Stability of the feature — automate stable features; volatile features change too fast and tests break constantly. (4) Bug history — areas with frequent bugs benefit most from regression tests. (5) Effort vs. value — easy-to-automate tests with high value first. Don't automate complex edge cases before you have basics covered.