Manual Testing Scenario Interview Questions
Scenario questions test judgement, not definitions: "Requirements change every week — how do you manage testing?", "You find a critical bug the night before release — what do you do?". A strong answer shows a process, a worked example and good communication. This guide covers the requirement and release-pressure scenarios asked most, each with the approach, a concrete example and a spoken answer you can adapt.
How to Structure Any Scenario Answer
- Clarify and assess — what changed or broke, and what is the risk?
- Plan — what will you test first, and what will you skip or defer?
- Act — the concrete steps and artefacts (RTM, test cases, defect report).
- Communicate — who you inform, and what decision you ask for.
Interviewers are listening for prioritisation by risk and transparent communication — not "I will re-run all the test cases".
1. Requirements Change Every Week — How Do You Manage Testing?
Why it happens
In Agile projects, changes come from customer feedback, market or regulatory changes, new stakeholders, and discoveries during development. Change is normal; unmanaged change is the problem.
Approach
- Impact analysis — which features, test cases, test data, automation scripts and integrations does the change touch?
- Update the RTM — the requirements traceability matrix maps each requirement to its test cases, so it shows exactly what to update, add or retire.
- Re-prioritise by risk — the changed area and high-impact neighbours first; unaffected, low-risk areas later.
- Lean on ready suites — keep smoke and regression suites (ideally automated) current, so re-testing the untouched parts is fast.
- Flag the cost — if the change adds effort, tell the Scrum Master or Product Owner, with options (move the date, reduce scope, accept risk).
Worked example
Change: the coupon rule changes from "one coupon per order" to "up to two coupons, but not on sale items".
| Requirement | Test cases | Impact | Action |
|---|---|---|---|
| REQ-12 Apply coupon | TC-41 to TC-46 | Directly changed | Update TC-43 (limit 1 → 2); add TCs for two coupons and for sale items |
| REQ-15 Order total and tax | TC-52 to TC-55 | Indirect — totals change | Re-run; add a two-coupon total case |
| REQ-20 Order confirmation email | TC-70 | Indirect — shows discounts | Re-run |
| REQ-30 Product search | TC-80 to TC-95 | Not affected | Covered by automated regression |
That table is the impact analysis — and it's what makes the answer credible. More on traceability and test documentation: Test Plan, Strategy & Test Cases.
Spoken answer
"When a requirement changes, I first do an impact analysis and update the RTM to see exactly which test cases, data and automation scripts are affected. I update or add those cases, test the changed area and its dependencies first, and rely on our smoke and regression suites for the rest. If the change adds effort that doesn't fit the sprint, I raise it with the Product Owner early, with options, rather than silently testing less."
2. The Requirement Changes Mid-Sprint, After Testing Started
- Stop and confirm the change in writing (updated story or acceptance criteria) — never test against a verbal update alone.
- Mark affected test cases and any executed results as outdated; don't report a pass that was against the old behaviour.
- Re-estimate the remaining work and raise it in the daily scrum.
- If the change is large, the Product Owner may move it to the next sprint as a new story — a legitimate outcome worth suggesting.
3. Requirements Are Unclear — What Do You Do?
Why it happens
Missing acceptance criteria, vague wording ("fast", "user-friendly"), undocumented business rules, conflicting sources, or rushed stories.
Approach
- Analyse what exists — the story, acceptance criteria, designs, API specs, older versions of the feature.
- List questions — gaps, ambiguities, edge cases, error handling.
- Clarify with the Business Analyst or Product Owner (and developers for technical behaviour), ideally in backlog refinement before development starts.
- Get it in writing — updated acceptance criteria or a comment on the ticket.
- Update test cases and the RTM.
Example questions for "users can reset their password"
- How long is the reset link valid, and can it be used twice?
- What password rules apply, and can the new password match the old one?
- What happens for an email address that isn't registered — and should the message reveal that?
- Are other sessions logged out after the reset?
Questions like these are how testers prevent defects before code is written — the "shift-left" value of testing.
Follow-ups
"Should you test based on assumptions?" No — if you must continue, record each assumption on the ticket and get it confirmed as soon as possible.
"What if the BA or PO isn't available?" Test the clear parts first, document the open questions and assumptions, and escalate through the Scrum Master if they block progress.
4. A Critical Bug Is Found Just Before Release
Approach
- Reproduce and gather evidence — steps, environment, screenshots or video, logs, and whether it's new or existed in production already.
- Assess impact — how many users, which business flow, data or money at risk, security implications, and whether a workaround exists.
- Report immediately with severity and business impact, and notify the release stakeholders — don't wait for the next stand-up.
- Support the decision — the release decision belongs to the Product Owner/release manager with the team; the tester supplies facts and risk.
The options the team weighs
| Option | When it fits |
|---|---|
| Fix, re-test and release | Quick, low-risk fix; time for targeted regression |
| Release with the feature switched off (feature flag) | The bug is isolated to one new feature |
| Release with a known issue and workaround | Low impact, workaround exists, documented in release notes |
| Delay the release | Critical flow broken, data or security risk, no workaround |
After a fix, re-test the defect and run targeted regression around it — late fixes are a common source of new bugs. See Severity vs Priority.
Spoken answer
"I reproduce it, collect evidence and assess the impact — users affected, business flow, workaround. I raise it immediately with severity and impact to the Product Owner and release manager. I don't decide alone whether to release; I give the facts and risks, and we choose between fixing and re-testing, switching the feature off, releasing with a documented workaround, or delaying. If it's fixed, I retest and run focused regression before sign-off."
5. The Deadline Is Cut but the Scope Isn't
- Risk-based testing — rank features by business impact and likelihood of failure; test the top of the list deeply and the rest at smoke level.
- Make the trade-off visible — share what will and won't be tested, and what risk that leaves.
- Use automation for regression so manual time goes to new and risky areas.
- Ask for a decision — reduced scope, more people, or accepted risk — in writing.
More: Testing Under Constraints.
6. A Developer Says "It's Not a Bug"
Point to the requirement or acceptance criterion the behaviour violates, show the evidence, and discuss it calmly. If the requirement is ambiguous, bring in the Product Owner to decide — the goal is the right behaviour for users, not winning the argument.
If it's agreed as intended behaviour, close it and update the test case; if it's a gap in the requirement, log it as a change request.
More Scenarios to Practise
- Test planning: no test plan exists; estimating with unclear scope; testing without documentation.
- Test data: no production-like data; data shared between testers; masking personal data.
- Execution: environment down on the last day; a build breaks smoke tests; a fix breaks another module.
- Defects: a bug you can't reproduce; duplicate defects; a production bug your tests missed.
- Agile: a story isn't testable by sprint end; acceptance criteria missing at planning.
More scenario answers: Top 25 Scenario-Based Testing Questions. Practise making these decisions on realistic situations in the Manual Testing Simulator.
From Real Projects
Understanding requirements, writing test cases and reviewing them with the team were the foundation of my work on Apkope, Canolog and Testsigma. I performed smoke, sanity, functional, integration, system and regression testing, tracked execution in TestRail and reported and retested defects in Jira. Solid manual testing is what makes automation worthwhile — you can only automate well what you understand well. Update the test cases as soon as a requirement changes, and note who confirmed it.
📚 Official documentation: ISTQB Glossary of testing terms
Frequently Asked Questions
How do you manage testing when requirements change every week?
Do an impact analysis, update the RTM and affected test cases, test the changed and dependent areas first, rely on ready smoke/regression suites, and raise extra effort early with the Product Owner.
What is the role of the RTM when requirements change?
It maps requirements to test cases, so it shows exactly which tests to update, add or retire — and proves nothing was missed.
What do you do when requirements are unclear?
Analyse what exists, list questions, clarify with the BA or Product Owner, get the answers in writing, then update test cases.
Can you test based on assumptions?
Only as a temporary measure — record each assumption on the ticket and confirm it quickly.
Who decides whether to release with a known bug?
The Product Owner or release manager with the team. The tester provides the evidence, impact and risk that inform the decision.
What do you do if the deadline is cut?
Use risk-based testing, make the untested areas and remaining risk visible, and ask stakeholders to decide on scope or risk.
