Scenario-based QA interview questions

Answer scenario questions in four steps: clarify what you do not know, assess impact and risk, act on what is in your control, communicate to the people who decide. The wording changes; the method does not.

1. You find a critical bug one hour before release.

Clarify: can I reproduce it every time, and what exactly breaks? Assess: how many users hit it, is there a workaround, is data lost or money wrong? Act: write the report with steps and evidence now. Communicate: tell the developer and product owner immediately, in person or on a call, not only in a ticket. Offer options (fix and retest, ship with the feature switched off, delay) and let the owner decide. Afterwards: ask why it was found so late and add a test.

2. The requirement is unclear or missing.

Ask the product owner or business analyst specific questions in writing. If nobody knows, state your assumption ("I will test it as X") and ask for confirmation. Explore the feature to learn its behaviour and note differences from similar features. Do not wait; unclear requirements are themselves a defect to report.

3. A bug is found in production that your testing missed.

First help fix it: reproduce, find the scope, support the hotfix and test it. Then do a blameless review: why was it missed? Was it untested, tested in the wrong environment, or a data difference? Add a regression test and, if needed, a check in the pipeline. Admit it plainly. Interviewers trust candidates who can describe a miss.

4. Developers say "it works on my machine".

Compare environments: build version, configuration, data, browser. Reproduce on a shared environment and attach evidence (video, logs, network trace). Offer to pair for ten minutes to look at it together. It is usually a difference in data or configuration.

5. You are asked to test a feature with two days left and four days of work.

Ask what matters most. Do a risk-based plan: critical paths and the riskiest changes first, smoke on the rest. Tell the owner in writing what you will not be able to cover and the risk. Ask for developer help on unit tests or a second tester. Do not silently squeeze quality.

6. A test fails randomly in the pipeline.

Look at the failure message and logs, then check timing, data and environment. Run it ten times locally and in CI to measure how often it fails. Quarantine if it blocks the team while you investigate. Fix the root cause (a missing wait, shared data), never just rerun.

7. The developer cannot reproduce your bug.

Check your steps and data, add the exact build, environment, account and time, record the screen and capture network logs. Reproduce together. If it is intermittent, say how often, and add logging to catch it next time.

8. Two stakeholders disagree on a bug's priority.

Present the facts: user impact, frequency, risk to data or revenue, workaround. Priority is a business decision, so involve the product owner and record the outcome on the ticket. Keep your role as the provider of evidence.

9. How would you test an app you have never seen?

Learn it first: read any documentation, talk to the people who use it, walk the main flow. Make a map of features. Run a time-boxed exploratory session with a note-taking sheet. Prioritise by risk (money, data, security, volume). Turn what you learn into test cases and a checklist.

10. A new joiner's tests keep failing because they use your shared test account.

The tests are coupled through data. Create data per test through the API or a seeding script and clean it afterwards. For now, give each person their own account. Fix it as a framework issue, not a person issue.

11. You are the only tester and the team wants everything automated.

Agree on a priority order: automate the stable, high-value smoke and regression paths first and API checks where possible, and keep exploratory testing for new features. Show the plan and what percentage it covers. Add the effort to the sprint as real work, not after-hours work.

12. You think the release should not go ahead but the manager wants to ship.

State your concern with evidence and the specific risk, ask for the decision to be recorded, and offer mitigations (feature flag, monitoring, rollback plan, a quick patch). You advise; you do not veto. Then support the decision and watch the release closely.

13. A requirement changes in the middle of the sprint.

Find out what changed and why, assess which tests, data and automation are affected, tell the team the testing impact (including the risk if the date does not move), and update the acceptance criteria in writing. Do not silently absorb a change: make the cost visible so the product owner can decide.

14. The test environment is down on the day testing must finish.

Find out the cause and the expected time to recover, and tell the team now. Use the time for work that needs no environment: review test cases, prepare data, write automation, analyse earlier defects. If the delay is real, show the effect on the plan and let the stakeholders choose between moving the date and reducing scope.

15. You found a bug, but the developer says the fix is risky and wants to delay it.

Ask what the risk is, and what the bug costs if left. Offer options: a smaller fix, a feature flag, a workaround, or a documented known issue with monitoring. The decision belongs to the product owner with both risks in front of them. Make sure what was decided and why is recorded in the ticket.

16. Two testers report the same bug differently.

Link or merge the duplicates, keep the report with the best steps and evidence, and add the missing detail from the other. Then agree a bug report template so it happens less.

17. A manager asks you for the number of test cases executed today.

Give the number, then add what it means: how many passed, failed or are blocked, and the main risks. A count alone invites gaming. Offer a better measure, such as risk areas covered or defects found per area.

18. A client reports a bug in production that you tested in staging.

Compare the two environments: version, configuration, data, third-party services, volume. Reproduce it with production-like data. Often the difference is data or configuration; if so, add that case to your tests and to the release checklist.

19. You are asked to sign off on a release you did not test.

Say that you cannot sign off on what you did not test, and say what you can: share the evidence you have and the risks, or do a short risk-based session first. Never give a verbal "it is fine".

20. A teammate keeps marking failures as flaky and re-running.

Look at the data together: how often each test fails and why. Agree that a flaky label needs a ticket with an owner and a date, quarantine tests that block others, and show the cost (build time, lost trust). It is a team habit to change, not an individual to blame.

21. How do you test a feature when the developer changes the code during testing?

Ask for a build number per test cycle and test only against it; record the build in every report. If changes arrive continuously, use feature branches or a staging environment per change, and re-run your smoke and regression set whenever the build changes.

22. A new joiner asks you how to start testing the app on day one.

Give them a guided path: the main user journey, the list of known problem areas, the environment and test accounts, the bug tracker and the template, and one small defined task with a reviewer. Pair on the first hour.

23. You are the only tester and three features arrive on the last day.

Ask for the priority order, test the riskiest in depth and the rest with smoke checks, say clearly what was not covered, and propose that features are delivered earlier next sprint. See also scenario 5.

24. How would you handle a stakeholder who wants zero bugs?

Explain, with respect, that testing reduces risk but cannot prove absence of bugs. Agree on the quality bar instead: no open critical or high defects, the main journeys covered, known issues documented, and monitoring in place after release.

Practise it

Pick three of these and answer them aloud in under a minute each. Record it. Anything you stumble on is where to prepare next.