100 Software Testing Interview Questions & Answers
Testing interviews mix technical depth (test design techniques, automation frameworks, the test pyramid) with the behavioral and situational rounds that catch people off guard — "how would you test an ATM as an end-user" isn't a trick question, it's checking whether you can think systematically about coverage on the spot. This covers all 100 questions, organized by topic, with code, diagrams, and a mock test at the end.
Testing Fundamentals
Q1. What is software testing, and why is it important?
Software testing is the process of evaluating a system to find defects and verify it behaves as intended — important because catching a bug before release is dramatically cheaper (in cost, reputation, and user trust) than catching it in production, and because testing is the primary evidence that software actually does what it's supposed to do, not just that it compiles.
Q2. Define the difference between verification and validation in software testing.
| Verification | Validation | |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| Checks against | Specifications, design documents | Actual user needs and requirements |
| Typical methods | Reviews, walkthroughs, static analysis | Actual testing — running the software |
Q3. Explain the software development life cycle and the role testing plays in each phase.
| SDLC phase | Testing activity |
|---|---|
| Requirements | Review requirements for testability and ambiguity |
| Design | Review design, begin test planning |
| Development | Unit testing, static analysis, code review |
| Testing | Integration, system, and acceptance testing |
| Deployment | Smoke testing, production monitoring |
| Maintenance | Regression testing on every subsequent change |
Q4. What are the different levels of software testing?
The testing levels, roughly narrowest to broadest scope
Unit testing
One function/class in isolation
Integration testing
Multiple units working together
System testing
The whole application end-to-end
Acceptance testing
Does it meet the business/user's actual needs?
Q5. Describe the difference between static and dynamic testing.
| Static testing | Dynamic testing | |
|---|---|---|
| Executes the code? | No — reviews, walkthroughs, static analysis | Yes — actually runs the software |
| Finds | Design flaws, style issues, potential bugs before runtime | Actual runtime behavior defects |
| Example | A code review, a linter | Running a test case and checking the output |
Q6. What is a test case, and what elements should it contain?
| Element | Purpose |
|---|---|
| Test case ID | Unique identifier |
| Preconditions | What state the system must be in before running it |
| Steps | The exact actions to perform, in order |
| Expected result | What should happen if the software is correct |
| Actual result / status | What actually happened, and pass/fail |
Q7. Explain the concept of coverage in testing and the main types of coverage (e.g., line, branch, path, statement).
| Coverage type | Measures whether every… |
|---|---|
| Statement/line coverage | Line of code has been executed at least once |
| Branch coverage | Branch (if/else, each case) has been executed |
| Path coverage | Possible execution path through the code has been exercised |
| Condition coverage | Boolean sub-expression has evaluated to both true and false |
Coverage measures how much of the code your tests actually exercise — but 100% line coverage doesn't guarantee correctness, since a line can execute without its result ever being properly asserted on; coverage is a useful signal for finding untested code, not a proof of quality by itself.
Q8. What is the difference between white-box, black-box, and grey-box testing?
| Black-box | White-box | Grey-box | |
|---|---|---|---|
| Knowledge of internals | None — tests only inputs/outputs | Full — tests internal logic/code paths | Partial — some internal knowledge |
| Typical tester | QA, end users | Developers | A mix of both roles |
| Example technique | Equivalence partitioning | Branch coverage analysis | Integration testing with some architecture knowledge |
Q9. What is regression testing, and why is it performed?
Regression testing re-runs existing tests after a code change to verify that change didn't break anything that previously worked — performed because even a small, seemingly isolated change can have unexpected ripple effects elsewhere in the system, and manually re-checking everything by hand doesn't scale past a trivial codebase.
Q10. Explain unit testing and which tools you might use for it.
| Language/ecosystem | Common tool |
|---|---|
| .NET / C# | xUnit, NUnit, MSTest |
| JavaScript | Jest, Vitest |
| Python | pytest, unittest |
| Java | JUnit |
Unit testing verifies one small unit of code (a function, a class method) in isolation, typically with its dependencies mocked — the fastest, cheapest tests to run and the foundation of the test pyramid, covered further in this blog's language-specific interview posts (.NET Core, C#, JavaScript).
Enjoyed this?
Let's talk about building something together.