QA / SDET Interview Questions

The testing pyramid has unit tests at the base (many, fast, cheap), integration tests in the middle (fewer, test component interactions), and E2E tests at the top (few, slow, expensive). More tests at the base means faster feedback and cheaper maintenance. Teams that invert the pyramid (mostly E2E) end up with slow, flaky CI and high maintenance cost. The pyramid is a heuristic — adjust for your product, but always bias toward lower, faster tests.

Functional testing verifies what the system does — features, business logic, APIs (unit, integration, E2E, regression, smoke tests). Non-functional testing verifies how well it does it — performance/load testing, security testing, accessibility testing, usability testing, and reliability/chaos testing. Both are necessary; functional is usually higher priority early in a project, non-functional as the product matures.

Playwright is a modern E2E framework from Microsoft that controls browsers via the CDP/WebDriver BiDi protocol. It has auto-wait (no explicit waits needed), built-in support for multiple browsers (Chromium, Firefox, WebKit), network interception, and parallel test execution out of the box. Selenium is older, uses the WebDriver protocol, requires explicit waits, and needs extra setup for parallelism — but has a larger ecosystem and more language bindings. For new projects, Playwright is the better choice.

POM is a design pattern for UI test automation that represents each page (or component) as a class encapsulating its locators and actions. Tests interact with page objects, not raw selectors. Benefits: locators change in one place, tests are readable and DRY, and page logic is reusable. Use it with Playwright or Selenium to keep large test suites maintainable.

Manually explore with Postman or curl. Automate with tools like REST-assured (Java), requests + pytest (Python), or supertest (Node). Verify: status codes, response body schema (use JSON Schema or Pydantic), response time, error handling (4xx/5xx), authentication, and edge cases (empty input, large payloads, invalid types). Also test contract with consumer-driven contract tests (Pact) in microservice architectures.

A flaky test sometimes passes and sometimes fails with no code change — caused by timing issues (explicit sleeps, animations), test isolation failures (shared state between tests), environment differences (network calls, random data, time zones), or order dependencies. Fix by using proper async waiting (waitFor, not sleep), mocking external dependencies, using independent test data, running tests in isolation, and quarantining known flaky tests while fixing them.

Regression testing re-runs the full (or relevant) test suite after a change to ensure nothing broke. Smoke testing is a quick, shallow check that the most critical paths work after a deployment (is the app even up?). Sanity testing is a focused check on a specific bug fix or feature to confirm it works as expected before deeper testing. Smoke and sanity are subset checks; regression is comprehensive.

Run fast unit tests on every commit/PR (seconds). Run integration tests on PR merge or schedule (minutes). Run E2E/smoke tests on deployment to staging (minutes). Gate deployments on test passage. Use parallelism (pytest-xdist, Playwright sharding) to keep pipelines fast. Report results with JUnit XML for CI dashboards. Fail fast — put the fastest tests first so developers get feedback quickly.

Test data management ensures each test has the data it needs to run independently and predictably. Strategies: create data in test setup and clean up after (factory pattern), use a dedicated test database seeded at build time, generate realistic data with libraries like Faker, and avoid sharing mutable state between tests. Poor test data is the #1 cause of test flakiness and environment dependency.

Start with requirements and acceptance criteria — ask 'what does done look like?' Identify happy-path scenarios first, then edge cases (empty input, max limits, invalid data), error scenarios, permission boundaries, and non-functional concerns (performance under load, accessibility). Explore manually to find unexpected behaviour, then automate the most important scenarios. Prioritise by risk: what's the worst thing that could go wrong?

Black-box testing tests behaviour without knowledge of internal implementation — the tester knows inputs and expected outputs only (most E2E and acceptance tests). White-box testing tests internal logic — the tester knows the code and writes tests to cover specific paths and branches (unit tests). Grey-box is in between — partial knowledge of internals, used for integration and API testing. Choose based on what layer you're testing and your access to the codebase.