50 software testing interview questions, with short answers and where to read more

Every question below is one we'd expect in an interview for a QA, test or automation role, from junior to mid-level. Each gets a short answer you could say out loud, and a link to the post that explains it properly. Read the short answers to revise; follow the links for anything you couldn't explain to a colleague.

Fundamentals

1. What is software testing? Checking that software does what it should, and doesn't do what it shouldn't. A test has a starting point, an action and an expected result; a mismatch is a bug. (Part 1)

2. Can testing prove software is bug-free? No. Testing shows the presence of defects, never their absence. Its job is to find the important bugs before users do, and to report the risk that remains. (The 7 principles)

3. Why is exhaustive testing impossible? The number of possible inputs and paths is astronomically large; a ten-character field alone has quadrillions of values. So we choose tests by risk and by technique. (The 7 principles)

4. What are the levels of testing? Unit (one piece of code), integration (pieces together), system (the whole application, end to end) and acceptance (does it meet the real need). Each catches what the others miss. (Part 2)

5. Explain the testing pyramid. Many fast unit tests at the base, fewer integration tests, and a few slow end-to-end tests at the top. The inverted version, mostly end-to-end tests, is slow and flaky. (Part 2)

6. What is the difference between QA, QC and testing? QA improves the process to prevent defects; QC checks the product to find them; testing is the main QC activity. Job titles blur this, but the definitions don't. (Part 20)

7. Verification vs validation? Verification: are we building the product right, against its specification? Validation: are we building the right product, for its users? A product can pass one and fail the other. (Part 20)

Process and planning

8. What is the STLC? The software testing life cycle: requirement analysis, test planning, test case design, environment setup, execution and closure, each with entry and exit criteria. It runs alongside development, not after it. (Part 4)

9. What are entry and exit criteria? Entry: what must be true before a phase starts, such as "build deployed, smoke test passed". Exit: what must be true to finish, such as "all high-priority tests passed, no open critical bugs". They stop testing starting too early or never ending. (Part 4)

10. What goes in a test plan? Objective, scope in and out, approach, environment, entry and exit criteria, people, schedule, deliverables and risks. The most underrated line is "out of scope". (Part 8)

11. Test plan vs test strategy? A strategy is the organisation's long-term approach; a plan applies it to one release or project. (Part 8)

12. What is risk-based testing? Spending the most testing effort where failure is both likely and harmful. Score each area on likelihood and impact, and test the top-right of that grid first and deepest. (Part 8)

13. What does "shift left" mean? Moving testing earlier: reviewing requirements, writing tests before code, running checks on every commit. Bugs found earlier are cheaper to fix. (Part 23)

Test design

14. What is a test case, and what does a good one contain? A set of steps with specific data that checks one thing and states the expected result. It has an ID, a title, preconditions, test data, steps, an expected result and a link to its requirement. (Part 6)

15. Test scenario vs test case? A scenario is what to test, in one line; a test case is exactly how to test one part of it. One scenario becomes several cases. (Part 6)

16. What is boundary value analysis? Testing at and around the edges of a valid range, because bugs like < instead of <= only show at the boundary. For a 0 to 100 field: -1, 0, 1, 99, 100, 101. (Part 6)

17. What is equivalence partitioning? Grouping inputs the software should treat the same, and testing one value from each group instead of all of them. (Part 6)

18. Black-box vs white-box vs grey-box testing? Black-box tests from the outside, against requirements. White-box designs tests from the code's structure. Grey-box tests from outside with some knowledge of the inside, such as the database or the API. (Part 7)

19. Statement coverage vs branch coverage? Statement: did every line run? Branch: did every decision go both true and false? One test can give 100% statement and only 50% branch coverage. (Part 7)

Bugs and reporting

20. What makes a good bug report? A title that says where, what and when; the environment; the fewest steps to reproduce; expected vs actual result; severity and priority; and evidence. Test: could a stranger reproduce it without asking you anything? (Part 9)

21. Severity vs priority? Severity is how badly the bug breaks the software; priority is how soon it must be fixed. A misspelled brand name on the home page is low severity, high priority. (Part 9)

22. Describe the bug life cycle. New, assigned, open, fixed, ready to retest, retest, verified, closed; or reopened if the retest fails. Side exits: rejected, duplicate, deferred, can't reproduce. (Part 10)

23. Who should verify a fix? Ideally the person who found the bug. They know exactly what was wrong, and they retest on every platform the bug affected. (Part 10)

24. What do you do when a developer says "works on my machine"? Add what the report was missing: exact data, environment, a recording. "Can't reproduce" usually means the report lacked something, not that the bug isn't real. (Part 9)

Test types

25. Smoke vs sanity testing? Smoke: a wide, shallow check of every main feature on each new build, to decide whether it's worth testing at all. Sanity: a narrow, deeper check of one area after a change. (Part 14)

26. Regression testing vs re-testing? Re-testing confirms a specific bug is fixed by running the failed test again. Regression testing runs previously passing tests to check the change broke nothing else. Every fix needs both. (Part 15)

27. What is integration testing, and what are stubs and drivers? Testing that separately built parts work together. A stub stands in for a part that is called; a driver stands in for a part that calls. Top-down integration uses stubs, bottom-up uses drivers. (Part 12)

28. System testing vs end-to-end testing? End-to-end follows one complete user journey; system testing covers those journeys plus non-functional checks of the whole system, in a production-like environment. (Part 13)

29. Name the types of performance testing. Load (expected peak), stress (past the peak, to the breaking point), spike (sudden rush), soak (hours, for leaks), volume (large data), scalability (does adding servers add capacity). (Part 16)

30. Why use percentiles instead of the average response time? The average hides the slow tail. A p95 of 1.8 s means one in twenty users waits that long, even if the average looks fine. (Part 16)

31. What is static testing? Finding defects without running the software: reviews, walkthroughs, inspections and static analysis tools. It catches missing requirements and design flaws that no executed test can. (Part 21)

Runs, coverage and traceability

32. Test case vs test run vs test result? A test case is written once; a run executes a set of cases on a specific build and environment; a result is what happened to one case in one run. (Part 17)

33. What do blocked and skipped mean, and why not count them as failed? Blocked: the test couldn't run because something else is broken. Skipped: deliberately not run. Neither tells you anything about the feature, so they're reported separately. (Part 17)

34. How do you calculate pass rate? Of executed tests: passed ÷ (passed + failed). Of planned tests: passed ÷ all planned. Report both; the gap is the blocked and skipped tests. (Part 17)

35. What is a requirements traceability matrix? A table linking each requirement to its test cases, results and bugs. It shows requirements with no tests, failing requirements, and tests that cover nothing. (Part 11)

36. What kinds of test coverage are there? Requirement coverage, execution coverage, code coverage (line, branch, function) and platform coverage. Each has a formula and none of them means bug-free at 100%. (Part 18)

Automation and tools

37. How do you decide what to automate? Three questions: will it run again and again, is the feature stable, is pass/fail clear? Yes to all three, automate; any no, keep it manual for now. (Part 3)

38. What is a flaky test, and why is it dangerous? One that passes and fails on different runs with no code change. Once people re-run red tests until they pass, real failures get re-run away too. (Hands-On 1)

39. What's the best way to locate elements in a UI test? By role and accessible name first, then test IDs, then visible text; CSS tied to styling and positional XPath last. The locator decides whether the test survives a redesign. (Hands-On 1)

40. Selenium vs Playwright vs Cypress? Selenium: the standard, most languages, widest browser and device coverage, manual waiting. Playwright: fast, auto-waiting, all three browser engines, best debugging. Cypress: best developer experience for JavaScript front-end teams. New projects usually pick Playwright. (Hands-On 1)

41. What is TDD? Write a failing test first, write just enough code to pass it, then clean up. The failing test proves the test can catch the bug. (Part 23)

API and security

42. Why test the API before the UI? API tests run in milliseconds, are stable, start before the screens exist, pinpoint the failing endpoint and cover every client at once. Test the business rules there; keep a few UI tests for journeys. (Hands-On 3)

43. 401 vs 403 vs 404? 401: not authenticated, who are you? 403: authenticated but not allowed. 404: not found. Assert the exact one; an API that returns 404 for someone else's record leaks that it exists. (Hands-On 4)

44. What is the most common serious API security bug? Broken access control: a user reading or changing another user's data. The test is four lines: sign in as one user, request another's record, expect 403. (Hands-On 5)

45. What is the OWASP Top 10? The ten most serious web application risks, updated from real-world data. The 2025 edition leads with broken access control and misconfiguration, and adds supply chain failures. (Hands-On 5)

46. SAST vs DAST? SAST reads the source code without running it, on every commit. DAST attacks the running application from outside, nightly or before release. They find different things. (Hands-On 6)

Agile, CI/CD and you

47. How does testing work in an agile team? Quality is the whole team's job, testing happens inside the sprint, acceptance criteria are the test cases, and regression is automated so people can explore. (Part 23)

48. What runs at each stage of a CI/CD pipeline? Every commit: static analysis and unit tests. Every pull request: integration and API tests. Merge: build and smoke test. Nightly: full regression and performance. Release candidate: system and exploratory testing. Production: smoke test and monitoring. (Part 23)

49. Tell me about a bug you found that the tests missed. Pick one that came from exploring beyond the script: an unusual sequence, an edge case, a state nobody considered. Explain how you found it, how you reported it, and what test you added so it stays fixed. (Part 22)

50. How do you decide testing is done? Against the exit criteria agreed in the plan, never against the deadline alone. Report what was tested, what wasn't, what's still open and the risk that remains. (Part 4)

How to use this before an interview

1. Read the short answers once. Mark any you couldn't explain to a colleague.
2. Follow the link for each marked one; every post is a ten-minute read.
3. For questions 7, 21, 25, 26 and 43, the pairs people confuse, practise saying the difference out loud.
4. Prepare one real story for question 49. Interviewers remember stories, not definitions.

Good luck. The whole Testing Basics series and the Hands-On Testing series are free, and every code sample in them actually runs.