10 Software Testing Interview Questions: Test Design, Defects, and Release Risk
Quick Overview
Practice software testing interview questions with worked boundaries, defect reports, test levels, automation trade-offs, and relevant QA practice links.
Software testing interview questions become practical when you explain what to test, what evidence would establish the result, and which risks remain. A definition is a starting point. A useful answer connects it to an input, an observable outcome, and a decision about the release.
Use these ten questions to practice that reasoning. The running example is a fictional batch-import feature: its batch_size must be an integer from 10 through 100, inclusive. The examples are original teaching scenarios, not reports of an interview or solutions to the linked questions.
For a broader preparation plan, use the QA and SDET interview guide. Answer aloud, identify an assumption, and explain what new evidence would change your recommendation.
1. How do verification and validation differ?
Verification asks whether specified requirements are satisfied. Validation asks whether the result meets the needs of its intended use. Reviewing a document versus executing software is a separate distinction: static and dynamic testing are not interchangeable labels for these objectives.
For the fictional importer, a requirements review could reveal that the upper batch limit is missing. Executing boundary checks could establish whether the implemented limit matches the agreed specification. Observing the intended operator's workflow could reveal that even a correctly enforced limit makes the nightly task impractical.
Do not silently convert an ambiguous requirement into a test expectation. Record the open question, agree on the rule with the responsible stakeholder, and connect the tests to that decision. Practice this review process in inspection in software testing.
2. What is the difference between defect severity and priority?
Severity describes a defect's impact; priority describes its relative urgency to fix. Impact includes stakeholder interests and requirements, not just crashes or technical damage.
Suppose an importer can expose another customer's records. That consequence matters even if the reproduction is unusual. Separately, a harmless label error on a demonstration screen might have an imminent deadline. Explain both assessments without assuming that rarity always makes a serious defect low priority.
For triage, state who is affected, what they can lose, how exposure occurs, whether a workaround exists, and what evidence supports the assessment. Recommend a fix order using the team's agreed scale. A tester can provide the evidence and recommendation without claiming that every organization assigns final priority to the same role.
3. How do black-box and white-box tests differ?
Black-box techniques derive cases from specified behavior. White-box techniques use internal structure. Having access to source code does not prevent a tester from designing a specification-based test.
For the importer, selecting 9, 10, 100, and 101 from its input contract is a black-box design. Inspecting the implementation to target an unexecuted error-handling branch is a white-box design. Either can produce useful tests, but they answer different coverage questions.
A coverage report identifies measured execution, not whether an assertion expresses the correct requirement. The coverage.py FAQ explains its execution-based measurements. A test that calls a function and ignores its result can exercise code while missing an incorrect outcome. Practice reviewing unit-test coverage and missing scenarios without treating a percentage as a release guarantee.
4. What are the levels of software testing?
The ISTQB Foundation Level syllabus v4.0.1, section 2.2.1, distinguishes five levels, separating component integration from system integration. Team terminology can differ, so describe the boundary you actually test.
| Level | Example in the fictional importer |
|---|---|
| Component or unit | Check the batch-size validator in isolation |
| Component integration | Check how the request parser passes a value to that validator |
| System | Exercise an import through the complete application |
| System integration | Check the application's interaction with an external file service |
| Acceptance | Assess whether the import supports the operator's agreed workflow |
A tool name does not determine the level. A test written with one framework could isolate a function or involve a real database. Explain which dependencies are real, which are substituted, and which failure the substitution could hide.
Use a focused lower-level test when it exposes the relevant failure clearly, and retain broader checks for risks that cross boundaries. The REST API interview guide helps connect request validation with externally observable responses.
5. How do smoke and sanity checks fit into a release?
Teams use these terms differently. Define the scope before relying on either label. A small smoke suite might establish whether a build can load the importer, submit a valid batch, and show its status. A targeted sanity check might examine a recently changed limit and nearby behavior.
For an interview, name the actual checks and their purpose. A green build check does not establish that every permission rule or failure-recovery path works. A focused check after a fix does not establish that unrelated workflows remain safe.
Describe what happens if a check fails: stop the affected release step, capture evidence, identify ownership, and investigate the failed behavior. Repeating a check until it passes changes the reported outcome without necessarily changing the risk.
6. How are confirmation and regression testing different?
Confirmation checks the reported fix. Regression testing looks for adverse effects of a change. The same change can justify both activities, at more than one level.
If batch_size=10 was incorrectly rejected, confirm that exact case on the fixed build. Then consider nearby boundaries, the default value, parsing, error messages, and other callers of the shared validator. Choose those checks from an impact analysis rather than rerunning every available test without an explanation.
When time is limited, identify the highest-consequence workflows and the affected boundaries first. State which evidence you collected and which scenarios remain unchecked. A release recommendation should make that residual risk understandable to the decision-maker.
7. How do equivalence partitions and boundary values produce test cases?
Start with the agreed input domain. In this fictional contract, batch_size is a JSON integer, booleans are not accepted, strings are not coerced, and the permitted range is 10 through 100 inclusive.
Within the integer domain, below-range, valid-range, and above-range inputs give three useful partitions. Probe each limit and its immediate neighbors:
| Input | Expected result | Reason for this case |
|---|---|---|
| 9 | Reject | Immediately below the minimum |
| 10 | Accept | Inclusive minimum |
| 11 | Accept | Immediately above the minimum |
| 50 | Accept | Interior representative |
| 99 | Accept | Immediately below the maximum |
| 100 | Accept | Inclusive maximum |
| 101 | Reject | Immediately above the maximum |
Test null, strings such as "10", fractional numbers such as 10.5, and true separately against the stated type rule. Decide explicitly whether 10.0 counts as an integer: JSON Schema's integer type accepts it, while Python's json module parses it as a float. A missing batch_size needs its own expectation: if a default applies (see question 6), omitting the field should succeed with that default rather than be rejected. Keep other inputs valid so one rejection does not mask another defect. If the real API deliberately performs coercion, change the contract and expectations together; do not assume this teaching example defines a universal API policy.
These cases do not cover concurrency, permissions, persistence, or every combination of fields. Continue with manual test design, boundaries, and coverage to extend the scenario systematically.
8. What does a useful defect lifecycle accomplish?
A workflow makes ownership, evidence, and the next action visible. One team might move an issue through New, Investigating, Ready for Verification, and Closed. Another may use different states or require an independent reviewer.
Ask what each transition means. A developer's completed code change and a tester's successful confirmation are different evidence. If the original failure persists, attach the tested build and fresh reproduction evidence to the existing issue according to the team's process. If the new symptom is distinct, explain why it needs separate tracking.
Deferred, duplicate, rejected, and cannot-reproduce outcomes should retain a reason. A status field is useful only when someone can determine what was checked and who owns the next step.
9. What should be automated, and how do you handle flaky tests?
Choose automation by repeatability, risk, feedback speed, and maintenance cost. The importer’s stable boundary contract is a useful candidate for frequent automated checks. Exploring an unfamiliar operator workflow can require observation and questions that a fixed assertion does not capture.
For UI automation, Playwright's best practices emphasize observable behavior and isolated tests. Prefer a meaningful visible outcome to assertions about incidental implementation details. Wait for the condition a test needs rather than assuming that an arbitrary delay establishes readiness.
If a test fails intermittently, preserve the failing evidence before rerunning. Compare isolated and full-suite runs, serial and parallel execution, shared data, timing, and dependency behavior. An intermittent failure can reveal a product defect; do not assume the test alone is wrong. The pytest flaky-test guide discusses state and isolation problems.
A temporary quarantine needs an owner, a reason, and a plan to restore coverage. Retries and longer timeouts are not substitutes for identifying the cause. Practice the public prompt on planning feature tests and handling flaky tests, then use the flaky-test debugging exercise to organize the investigation.
10. What makes a bug report actionable?
Give another person enough information to reproduce the behavior, assess its impact, and verify a correction. Separate observations from explanations you have not established.
Here is a fictional report for the running example:
| Field | Example evidence or expected detail |
|---|---|
| Title | Valid minimum batch size 10 is rejected |
| Environment | Exact staging build identifier and relevant configuration |
| Preconditions | Authorized test user; otherwise valid import data |
| Steps | Submit one import with numeric batch_size equal to 10 |
| Expected | Request accepted under the agreed inclusive 10–100 contract |
| Observed | Validation error reports that the batch size is too small |
| Impact | An operator cannot use a documented valid batch size |
| Evidence | Sanitized request/response, timestamp, and correlation identifier |
| Verification | Confirm 10 succeeds; check adjacent and shared-validator behavior |
A real report must replace placeholders with captured facts. Include the HTTP status only if observed, and do not infer that a database failed merely because a page showed an error. Remove credentials and unnecessary personal data from attached evidence.
For UI-specific practice, compare UI and backend testing and design UI-change cases. Explain which layer first demonstrates the problem and which additional layer is needed to establish user impact.
Turn the answers into a practice routine
For each question, give the distinction, work one example, and name a limitation. Then change an assumption: permit string coercion, remove access, make an external dependency unavailable, or let two imports run together. Explain which expectations must change and which risks need additional tests.
For historical research on testing roles, see Florea and Stray's 2019 study, The skills that employers look for in software testers, which analyzes historical job advertisements for testers; it does not measure what current QA interviews ask. Their 2018 paper, Software Tester, We Want to Hire You!, examines demand for soft skills. IDC's December 2024 survey spotlight, Opportunity to Increase Test Automation from Manual Adoption in Conjunction with DevOps Benefits, discusses test automation using results from IDC's 2024 DevOps survey; it is a paid market report, not evidence about which tests a particular team should automate.
Terminology reference: ISTQB's Foundation Level syllabus v4.0.1, authored by Renzo Cerquozzi and colleagues, with the authors and ISTQB acknowledged as its copyright holders. The scenarios and practice guidance here are original editorial examples, not official examination questions or an endorsement.
Comments (0)