Software Testing interview questions & answers

1. 1.How would you test a checkout flow?mid

   I would start with risks: wrong totals, duplicate orders, inventory changes and payment failures. Unit tests cover pricing rules and boundary values. Integration tests cover persistence, service contracts and idempotency. A small set of end-to-end tests covers important customer journeys with controlled test data. I would include timeout and retry scenarios, verify observable outcomes and avoid using real payment details. The goal is confidence in behavior, not merely a coverage percentage.

   What interviewers listen for

   • Prioritize business risks
   • Use multiple test levels
   • Cover failure paths and boundaries
   • Keep data and dependencies controlled

   Likely follow-up: How would you test a successful payment followed by a failed response?

   answer it out loud →
2. 2.How do you investigate a flaky test?mid

   First capture the failing seed, logs, environment and execution order. I would look for shared mutable data, real network dependencies, wall-clock assumptions and asynchronous work that the test does not await. Reproduce with repetition and isolation, then replace arbitrary sleeps with observable readiness conditions. Control clocks and randomness when appropriate. Temporary quarantine may protect delivery, but it should have an owner and a tracked fix rather than silently hiding a regression.

   What interviewers listen for

   • Capture failure evidence
   • Inspect timing and shared state
   • Wait for observable conditions
   • Track the underlying fix

   Likely follow-up: Why can retrying every failed test conceal defects?

   answer it out loud →
3. 3.When should you use a mock instead of a real dependency?mid

   Use a test double when the dependency is slow, costly, nondeterministic or difficult to drive into a failure state. A stub provides canned responses, while a mock can verify interactions. Prefer assertions on observable behavior unless the interaction itself is the contract. Too many mocks can reproduce implementation details and miss real incompatibilities, so complement isolated tests with integration or contract checks using realistic boundaries.

   What interviewers listen for

   • Control external dependencies
   • Distinguish stubs from interaction checks
   • Assert behavior
   • Complement doubles with integration tests

   Likely follow-up: What can an in-memory database hide compared with production?

   answer it out loud →
4. 4.What would you include in API contract tests?mid

   Check the observable agreement between consumer and provider: required fields, types, status codes, headers and relevant error formats. Include missing or optional data and compatibility expectations. Avoid asserting undocumented incidental ordering or internal implementation details. Run provider verification against the expectations consumers actually rely on. Contract tests help catch incompatible changes, but they do not replace full integration checks for authentication, networking or real data behavior.

   What interviewers listen for

   • Test the observable interface
   • Include success and error shapes
   • Make compatibility expectations explicit
   • Complement contracts with integration coverage

   Likely follow-up: How would you evolve a response without breaking existing clients?

   answer it out loud →
5. 5.How do you write reliable tests for asynchronous code?mid

   Await the operation and ensure the test runner observes rejected promises or callback failures. Control external dependencies and wait for a meaningful state change rather than an arbitrary sleep. For time-based behavior, a controlled clock can make tests fast and deterministic, but account for how the runtime schedules pending work. Include success, failure and cancellation where relevant. Clean up timers, listeners and background work so they do not affect later tests.

   What interviewers listen for

   • Await completion and propagate failures
   • Wait for observable state
   • Control time and external dependencies
   • Clean up background work

   Likely follow-up: How can a test accidentally pass before an asynchronous assertion runs?

   answer it out loud →
6. 6.How would you turn a production bug report into a regression test?easy

   Gather the relevant input, expected outcome and actual behavior, then reproduce the failure in a controlled environment. Reduce it to the smallest case that still shows the defect. Write a test at the lowest useful boundary that captures the broken behavior, and verify that it fails before the fix. After the change, confirm it passes and consider nearby edge cases. Remove sensitive production details from fixtures while preserving the properties needed to reproduce the issue.

   What interviewers listen for

   • Capture expected and actual behavior
   • Minimize the reproducer
   • Observe failure before the fix
   • Protect sensitive data and check nearby cases

   Likely follow-up: When would you need an integration test rather than a unit test?

   answer it out loud →
7. 7.How would you design a useful performance test for an API?hard

   Start with a workload model: request mix, arrival rate, payloads and data size. Set explicit latency and error-rate objectives and include warmup and steady-state periods. Observe tail latency, throughput, saturation and dependency behavior rather than only averages. Ensure the load generator is not the bottleneck. Separate normal-load validation from stress testing, and document environment differences so results are interpreted correctly. Repeat measurements to distinguish changes from noise.

   What interviewers listen for

   • Model representative traffic and data
   • Set latency and error objectives
   • Measure tail latency and saturation
   • Validate the generator and environment

   Likely follow-up: Why can average latency hide a serious user experience problem?

   answer it out loud →
8. 8.If time is limited before a release, how would you prioritize testing?mid

   Identify what changed, the user journeys affected and the consequences of failure. Prioritize high-impact paths such as access control, data integrity and core transactions, including important failure cases. Reuse reliable automated checks and target exploratory testing at uncertainty. Communicate what was covered, what remains untested and the residual risk to the release owner. Do not claim that a passing smoke suite proves the whole release is safe.

   What interviewers listen for

   • Use change impact and failure severity
   • Cover critical success and failure paths
   • Combine automation with targeted exploration
   • Communicate remaining uncertainty

   Likely follow-up: How would a change to a shared library alter your priorities?

   answer it out loud →

No questions match that filter.

Prefer multiple choice? All 11 Software Testing MCQs with answers →