The short answer: QA interviews test four things: whether you know the fundamentals (the vocabulary of testing, test levels and types), whether you can design good tests (boundary values, equivalence classes, edge cases), whether you can report and prioritize bugs clearly, and how you think when you can’t test everything. Below are 40 questions with short answers, the scenario questions interviewers love (“how would you test a login page?”), and the behavioral questions to prepare.
What QA interviews cover
Most of the vocabulary interviewers use comes from ISTQB, the International Software Testing Qualifications Board, and its Certified Tester Foundation Level syllabus (CTFL, version 4.0). You don’t need the certificate to use its terms, and interviewers will recognize them.
What changes with the role:
| Role | What they focus on |
|---|---|
| Manual / QA tester | Fundamentals, test cases, bug reports, exploratory testing |
| QA analyst | Requirements, test planning, risk, coverage |
| QA engineer / SDET | Automation, API testing, CI pipelines, code |
| QA lead / manager | Strategy, metrics, process, people |
For automation-heavy roles, also read our QA automation engineer questions.
Fundamentals
1. What’s the difference between QA, QC and testing?
Quality assurance is about the process: preventing defects by improving how software is built. Quality control is about the product: finding defects in what was built. Testing is the main QC activity. In job titles, “QA” usually covers all three.
2. What’s the difference between an error, a defect and a failure?
A person makes an error (a mistake), which introduces a defect (a bug or fault) in the code or a document. When the defective code runs, it may cause a failure: the system doing something it shouldn’t.
3. Verification or validation?
Verification checks that the product meets its specification (“did we build it right?”). Validation checks that it meets the users’ real needs (“did we build the right thing?”).
4. What are the seven testing principles?
ISTQB’s Foundation syllabus lists them:
- Testing shows the presence, not the absence, of defects.
- Exhaustive testing is impossible.
- Early testing saves time and money.
- Defects cluster together.
- Tests wear out: the same tests repeated find fewer new defects.
- Testing is context dependent.
- The absence-of-defects fallacy: a bug-free system can still fail to meet users’ needs.
5. What are the test levels?
Component (unit) testing, component integration testing, system testing, system integration testing, and acceptance testing, including user acceptance testing (UAT).
6. What’s the difference between functional and non-functional testing?
Functional testing checks what the system does (features, business rules). Non-functional testing checks how well: performance, security, usability, reliability, compatibility.
7. Black-box or white-box testing?
Black-box testing designs tests from the requirements, without looking at the code. White-box testing designs tests from the code’s structure, for example to cover every branch. Gray-box mixes the two.
8. What’s the difference between retesting and regression testing?
Retesting (confirmation testing) checks that a specific bug is fixed. Regression testing checks that the change didn’t break anything else. Regression suites are the first candidates for automation.
9. Smoke testing or sanity testing?
A smoke test is a quick, broad check that a new build works well enough to test at all: it launches, you can log in, the main pages load. A sanity test is a narrow check that a specific fix or feature works before deeper testing.
10. What’s the difference between a test plan and a test strategy?
A test strategy is the general approach, often organization-wide: levels, types, tools, environments. A test plan applies it to one project or release: scope, schedule, responsibilities, risks, entry and exit criteria.
11. Test scenario, test case or test script?
A scenario is what to test (“user resets password”). A test case gives the preconditions, steps, data and expected result. A test script is the automated version.
12. What are entry and exit criteria?
Entry criteria must be met before testing starts (a stable build deployed, test data ready). Exit criteria say when it’s done (all critical tests passed, no open blocker bugs, agreed coverage reached).
Test design techniques
13. What is equivalence partitioning?
Dividing inputs into groups the system should treat the same way, then testing one value from each. For an age field that accepts 18 to 65, the partitions are below 18, 18 to 65, and above 65 (plus invalid inputs such as letters).
14. What is boundary value analysis? Give an example.
Defects cluster at the edges of partitions, so test the boundaries. For 18 to 65: test 17, 18, 65 and 66 (two-value BVA), or add 19 and 64 for three-value BVA.
15. When would you use a decision table?
When the result depends on combinations of conditions, such as a discount that depends on membership, order size and a coupon. The table lists every combination and its expected outcome, so none are missed.
16. What is state transition testing?
Testing a system that behaves differently depending on its state, such as an account that locks after three failed logins. You test valid transitions, invalid ones and the sequence that leads to each state.
17. What is exploratory testing, and when is it useful?
Designing and running tests at the same time, guided by what you learn as you go, usually in time-boxed sessions with a charter. It’s useful when specifications are thin, time is short, or you want to find what scripted tests miss.
18. What is risk-based testing?
Prioritizing testing by the likelihood and impact of failure: the payment flow before the “about” page. It’s the honest answer to “you can’t test everything; what do you test first?”
Bugs and reporting
19. What makes a good bug report?
A clear title; the environment (build, browser, device); exact steps to reproduce; expected versus actual result; evidence (screenshot, video, logs); and severity. A developer should be able to reproduce it without asking you anything.
20. What’s the difference between severity and priority? Give an example.
Severity is the impact on the system; priority is how soon it must be fixed. A typo in the company name on the home page is low severity but high priority. A crash in a rarely used admin report is high severity but may be lower priority.
21. Describe the bug lifecycle.
New, then assigned, open or in progress, fixed, ready for retest, then verified and closed, or reopened if the fix fails. Bugs can also be rejected, marked duplicate or deferred. The exact states depend on the team’s tracker.
22. A developer says your bug “works on my machine”. What do you do?
Check the differences: environment, build version, data, browser, account permissions. Reproduce it again, attach evidence and logs, and if needed reproduce it together on a call. Stay factual: the goal is the fix, not being right.
Automation
23. Which tests should you automate?
Tests that run often and are stable: regression, smoke, data-driven tests with many inputs, API tests. Don’t automate one-off tests, features that change weekly, or checks that need human judgment, such as whether a design looks right.
24. What is the test pyramid?
A guide to the balance of automated tests: many fast unit tests at the base, fewer integration or API tests in the middle, and few slow end-to-end UI tests at the top. Teams with mostly UI tests (an “ice cream cone”) get slow, flaky suites.
25. What is a flaky test, and how do you deal with it?
A test that passes and fails on the same code. Common causes are timing (fixed waits instead of waiting for a condition), shared test data, test order dependencies and unstable environments. Quarantine it so it doesn’t block the pipeline, find the cause, fix it, and don’t just rerun until green.
26. Which automation tools do you know?
Name what you’ve actually used and what you did with it: Selenium, Playwright or Cypress for web UI, Appium for mobile, Postman or REST Assured for APIs, JUnit, TestNG or pytest as runners, and a CI tool such as Jenkins or GitHub Actions. Depth beats a long list.
27. What is the Page Object Model?
A design pattern for UI automation: each page gets a class that holds its locators and actions, and tests call those methods. When the UI changes, you update one class instead of every test.
API, performance and security testing
28. How do you test an API?
Check status codes, response body and schema, headers, and response time. Test valid requests, invalid and missing inputs, authentication and permissions, and boundary values. Chain requests for full workflows, such as create, read, update and delete.
29. Which HTTP status codes should a tester know?
200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found, 409 Conflict, 500 Internal Server Error, 503 Service Unavailable.
30. What types of performance testing are there?
Load testing (expected traffic), stress testing (beyond expected, to find the breaking point), spike testing (sudden bursts), and endurance or soak testing (steady load for hours, to find memory leaks and slow degradation).
31. Which security issues can a QA tester check for?
Input validation (SQL injection, cross-site scripting), authentication and session handling, access control (can user A see user B’s data by changing an ID in the URL?), and sensitive data exposed in responses or logs. The OWASP Top 10 is the standard reference list.
Process and Agile
32. What does QA do in an Agile team?
Testing starts with the story, not after it: clarifying acceptance criteria in refinement, testing during the sprint, automating regression, and taking part in the team’s definition of done.
33. What does “shift left” mean?
Moving testing earlier: reviewing requirements, testing APIs before the UI exists, running automated tests on every commit. It follows the principle that early testing saves time and money.
34. Which QA metrics are useful?
Defects found in production (escaped defects), defect trends by area, test pass rate per build, automation coverage of critical paths, and time to detect and fix. Be careful with bug counts per tester: they reward the wrong behavior.
Scenario questions
Interviewers use these to see how you think. Structure your answer: clarify requirements, then cover functional, negative, boundary, UI, security, performance and accessibility tests.
35. “How would you test a login page?”
Valid login; wrong password; unknown user; empty fields; boundary lengths for inputs; case sensitivity; password masking; account lockout after repeated failures; “forgot password” flow; session timeout and logout; login over HTTPS only; SQL injection in the fields; keyboard-only use and screen reader labels; behavior on different browsers and devices; response time under load.
36. “How would you test a pen (or an elevator, or a vending machine)?”
Ask questions first: who is it for, what are the requirements? Then cover function (does it write, how long), usability (grip, cap), durability (drops, temperature), safety (materials, cap for children) and edge cases. The interviewer is testing whether you ask before you test.
37. “You have one day to test a release that needs a week. What do you do?”
Agree on the risks with the team, test the most critical and most changed areas first, run the automated regression suite, and report clearly what was tested, what wasn’t, and the risk of shipping. The release decision belongs to the team, based on your information.
Behavioral questions
Answer these with a real story in STAR order (Situation, Task, Action, Result):
38. “Tell me about the most important bug you found.”
Explain how you found it (the thinking, not luck), its impact, and what changed afterward, such as a new test in the regression suite.
39. “Tell me about a bug that reached production on your watch.”
Own it, explain the cause, and focus on what you changed so it couldn’t happen again. Interviewers are checking honesty and learning.
40. “Tell me about a disagreement with a developer.”
Show that you stayed factual, used evidence, and kept the relationship. Our guide to conflict and collaboration questions covers the structure.
Frequently asked questions
What are the most common QA interview questions?
How do I prepare for a QA interview?
What is the difference between severity and priority?
Do I need ISTQB certification to get a QA job?
How do I answer "How would you test a login page?"
What is the difference between retesting and regression testing?
Sources
- ASTQB (the US board of ISTQB), ISTQB Foundation Level v4.0: 1.3 Testing Principles. Read on 29 September 2026.
- IETF, RFC 9110: HTTP Semantics (status codes).
- OWASP, Top 10.
