QA and SDET interview questions with short answers you can say aloud
QA and SDET interviews test whether you can think about risk and then turn that thinking into reliable checks. The strong answer names what could go wrong, picks the cheapest layer to test it, and says how you would keep the test trustworthy. This guide gives twenty questions with short answers and follows the public guidance in the Playwright best practices and the pytest fixtures guide.
How QA and SDET questions appear in a live interview
Expect a mix: a test-design case for a simple feature, a review of a flaky test, a small coding task, and questions about your automation and CI choices. Say your assumptions aloud and ask what the risk is. The same habit helps in a live coding interview and a technical phone screen.
Junior QA and SDET interview questions
1. What is the difference between QA, testing and SDET?
QA is the whole effort to prevent defects, including process and reviews. Testing is checking the product for defects. An SDET (software development engineer in test) is an engineer who builds test tooling, frameworks and automation as code. Say which of these the role actually asks for.
2. What is the difference between verification and validation?
Verification asks whether we built the thing right, against the spec or design. Validation asks whether we built the right thing for the user. A feature can pass every spec check and still fail validation because the spec misread the need.
3. What makes a good bug report?
A clear title, exact steps to reproduce, expected versus actual result, environment and version, and evidence such as logs or a screenshot. Add severity and impact, but leave blame out. A report another person can reproduce in two minutes is the goal.
4. What is the difference between severity and priority?
Severity is how badly the defect harms the product. Priority is how soon it should be fixed, which depends on business context. A typo on the home page can be low severity but high priority; a crash in a rarely used export can be the opposite.
5. What is the test pyramid?
Many fast unit tests, fewer integration or API tests, and a small number of slow end-to-end UI tests. The shape is a cost argument: lower layers are quicker and less flaky. Mention that it is a guide, and that some teams deliberately use other shapes.
6. What is exploratory testing?
Unscripted, time-boxed testing where you learn the product and design tests as you go, guided by a charter such as 'try to break checkout with unusual input'. It finds problems scripted checks miss. Keep notes so findings can be reproduced and turned into automated tests.
7. What is the difference between smoke, sanity and regression testing?
Smoke tests check that the build is basically alive. Sanity tests check a narrow area after a change. Regression tests check that existing behaviour still works. Definitions vary between teams, so state yours before using the words.
Mid-level QA and SDET interview questions
8. How do you design test cases for a feature?
Start from requirements and risks, then apply techniques: equivalence partitions, boundary values, decision tables and state transitions. Add negative and error cases. For a field accepting 1 to 100, test 0, 1, 100 and 101 plus a non-number, rather than random values.
9. What do you automate and what do you leave manual?
Automate stable, repeatable, high-value checks that run often, such as regression and API checks. Keep exploratory testing, usability and one-off checks manual. Weigh the cost of writing and maintaining a test against how often it runs and how much a failure matters.
10. Why are UI tests flaky and how do you reduce it?
Common causes are timing, shared data, unstable selectors and dependence on external services. Use tools that wait for conditions rather than fixed sleeps, keep each test independent, prefer user-facing locators, and control data. Quarantine a flaky test and fix its cause instead of rerunning it until green.
11. How do you choose locators?
Prefer locators tied to what the user sees or to explicit test contracts, such as roles, labels or a dedicated test id, over long CSS or XPath chains that mirror page structure. The Playwright best practices make the same recommendation.
12. What is the Page Object Model?
A pattern where each page or component is a class that exposes actions and hides locators. When the UI changes, you edit one class instead of every test. The risk is bloated page objects, so keep assertions in the tests and the objects small.
13. How do you test an API?
Check status codes, response body and schema, headers, error handling, authentication and authorisation, and idempotency of retries. In Postman, scripts written with pm.test and pm.expect assert on the response, as the Postman documentation describes. Code-based suites do the same in CI.
14. How do pytest fixtures help?
A fixture prepares data or state and passes it to the tests that name it as an argument. Scope controls reuse: the default is per test, broader scopes share an instance. Code after yield performs teardown. Use a narrow scope by default so tests stay independent; see the pytest fixtures guide.
Senior QA and SDET interview questions
15. How would you design a test automation framework from scratch?
Start with what to test and at which layer, then pick tools the team can maintain. Provide clean setup and teardown, test data management, parallel execution, readable reports and CI integration. Keep tests independent and the framework thin. Explain how a new teammate adds a test on day one.
16. How do you integrate tests into CI/CD?
Run fast checks on every commit, broader suites on merge or nightly, and gate deployment on results people trust. Split and parallelise to keep feedback short, publish failure artefacts such as traces and logs, and track flaky tests as a metric, not an annoyance.
17. How do you handle test data and environments?
Create the data each test needs through an API or fixture, and clean it up, instead of relying on a shared database that drifts. Mock or stub external services you do not own, as Selenium's encouraged practices advise, and keep a small set of contract or smoke tests against the real thing.
18. What metrics tell you whether testing is working?
Defects escaping to production, time to detect and fix, flaky-test rate, suite duration and the share of failures that are real bugs. Coverage numbers are a weak signal alone: they show what ran, not what was asserted. Avoid targets that reward test count.
19. How do you decide whether a release is ready?
Look at open defects by risk, test results on critical paths, known gaps and rollback options, then give a recommendation with reasons instead of a bare yes. Testing informs the decision; the product owner or team owns it.
20. Tell me about a bug that escaped to production.
Pick a real one. Describe the impact, how you found it, the root cause, why testing missed it and what you changed, such as a new test, a monitor or a review step. The answer is judged on ownership and learning. The STAR method keeps it short.
A concise answer shape
For most QA questions, say the risk you are protecting against, the layer where you would test it, the trade-off in cost or speed, and how you would know it works. Example: for a payment endpoint, I would cover the rules in unit and API tests and keep one end-to-end happy path, accepting slower feedback for that single check.
Before any live assessment, ask the recruiter which tools and documentation are permitted. Knowing the material is useful; using unapproved tools during an assessment is a separate policy question. If you want a quiet prompt while you practise, a free plan exists, and the same rules apply to it. Related guides: technical interview preparation, code review interview questions, Python interview questions.
Sources
- Playwright: best practices, locators, isolation and web-first assertions
- Selenium: encouraged test practices
- pytest: how to use fixtures
- Postman: writing test scripts
Checked 12 November 2026.
FAQ
What are common QA interview questions?
Test design techniques, bug reporting, severity versus priority, the test pyramid, automation choices, flaky tests, API testing and how you decide a release is ready. Expect a practical case, such as designing tests for a login form.
What is the difference between a QA engineer and an SDET?
A QA engineer focuses on quality across the process and often tests manually and with tools. An SDET is expected to write code for frameworks, tooling and automation. Job ads use the titles loosely, so read the responsibilities.
Which automation tool should I know: Selenium or Playwright?
Learn the concepts first: locators, waiting, isolation and reporting. Both Selenium and Playwright are documented with best-practice guides. Know the one in the job ad, and be able to explain how the ideas transfer.
How do I answer test case design questions?
Ask clarifying questions, list inputs and rules, then apply equivalence partitions and boundary values, add negative and error cases, and say which you would automate. Structure matters more than the number of cases.
Do I need to code in a QA interview?
For SDET roles, usually yes: a small function, a data-structure task or writing a test. For manual QA roles it is less common. Ask the recruiter about the format and which tools are allowed.