Risk Based Testing Scenarios and Answers
Testing Under Constraints: No Requirements, Late Builds & Limited Time
Three situations come up in almost every QA and SDET interview — and in almost every real project: no documented requirements, a build that arrives the day before release, and more test cases than time. Interviewers aren't looking for a perfect process; they want to see how you prioritise, communicate risk and still protect the business. Each scenario below has the approach, the follow-up questions with answers, and a spoken answer you can adapt.
Scenario 1: Testing Without Documented Requirements
The situation
Development is finished, but there are no detailed requirements — common in fast-moving Agile teams.
The approach
- Gather what exists: the user story, mockups, API contracts, the demo, similar existing features and the current production behaviour.
- Write down your understanding as a short list of expected behaviours and questions, and confirm it with the product owner or BA.
- Explore with time-boxed exploratory sessions focused on business-critical flows.
- Cover positive, negative and edge cases, prioritised by business impact.
- Record assumptions in the ticket until they're confirmed — they become the acceptance criteria.
Follow-up questions
What do you test first?
Business-critical flows, the behaviour users depend on most, and anything similar to features that have had defects before.
Which testing techniques help most?
Exploratory testing and risk-based testing, supported by equivalence partitioning and boundary values once expected behaviour is agreed.
How do you decide what "correct" looks like?
Compare with existing behaviour and similar modules, check with the product owner, and document assumptions until clarified.
What's the biggest risk?
Misunderstanding the business rule and missing a critical scenario — which is why confirming your understanding early matters more than writing many test cases.
Spoken answer
"If the requirements aren't documented but development is done, I first gather whatever exists — the story, mockups and similar features — and explore the feature. I write down my understanding as a list of expected behaviours and questions and confirm it with the product owner. Then I test the business-critical flows first with exploratory and risk-based testing, covering positive, negative and edge cases, and I record any assumptions in the ticket so they become acceptance criteria."
Scenario 2: The Build Arrives Late, Release Is Tomorrow
The situation
The build lands late in the sprint and the release is scheduled for the next day.
The approach
- Smoke test immediately. If the build is unstable, reject it right away with evidence — that's a release risk the business must hear about now.
- Test in risk order: core business flows, the fixes and changes in this build, then high-risk and defect-prone modules.
- Run the automated smoke and critical regression suites in parallel while testing new changes manually.
- Share progress during the day, not only at the end.
- End with a clear summary: what was tested, what wasn't, open defects and the risks.
Follow-up questions
What do you test first?
Smoke, then the functionality with the biggest business and user impact, then this build's changes.
Smoke or sanity?
Both: smoke for build stability, sanity for the specific fixes and changes.
Do you run the full regression?
No — targeted regression on critical functionality and the areas affected by the changes, ideally through automation.
What if you find a critical defect?
Tell the developer immediately, explain the business impact to the product owner, help verify the fix quickly, and make the release risk explicit.
Who decides whether to release?
The product owner or release manager — your job is to give them an accurate picture of coverage and risk.
Spoken answer
"I'd start with a smoke test straight away, and if the build isn't stable I'd reject it with evidence. If it is, I'd test the core business flows and this build's changes first, run our automated smoke and critical regression in parallel, and keep the product owner updated during the day. Before release I'd share what was tested, what wasn't and the open risks, so the go/no-go decision is informed."
Scenario 3: Limited Time, Too Many Test Cases
The situation
Release is close and there isn't time to run every test case.
The approach — risk-based prioritisation
Score each test by impact (how bad a failure would be for the business) and likelihood (how likely it is to fail — recent changes, complexity, defect history). Run the highest-risk tests first, and report what you deferred.
A runnable example
This small Java program scores tests as impact × likelihood (each 1–5), sorts them, and fills a 45-minute time budget in strict risk order:
import java.util.*;
public class RiskPriority {
record TestCase(String name, int impact, int likelihood, int minutes) {
int risk() { return impact * likelihood; } // 1–5 each → 1–25
}
public static void main(String[] args) {
List<TestCase> tests = new ArrayList<>(List.of(
new TestCase("Checkout with card payment", 5, 4, 20),
new TestCase("Login and logout", 5, 2, 5),
new TestCase("Apply discount coupon (changed this sprint)", 4, 5, 15),
new TestCase("Update profile picture", 2, 2, 10),
new TestCase("Order history export", 3, 2, 15),
new TestCase("Footer links", 1, 1, 5)));
tests.sort(Comparator.comparingInt(TestCase::risk).reversed());
int budget = 45, used = 0; // minutes available
boolean full = false;
System.out.printf("%-45s %4s %s%n", "Test", "Risk", "Decision");
for (TestCase t : tests) {
boolean run = !full && used + t.minutes() <= budget;
if (run) used += t.minutes(); else full = true; // keep strict risk order
System.out.printf("%-45s %4d %s%n", t.name(), t.risk(), run ? "RUN" : "DEFER (report as risk)");
}
System.out.println("Time used: " + used + " of " + budget + " minutes");
}
}
Real output
Test Risk Decision
Checkout with card payment 20 RUN
Apply discount coupon (changed this sprint) 20 RUN
Login and logout 10 RUN
Order history export 6 DEFER (report as risk)
Update profile picture 4 DEFER (report as risk)
Footer links 1 DEFER (report as risk)
Time used: 40 of 45 minutes
In real projects this is usually a spreadsheet column or a priority field in your test management tool, and in automation it maps to TestNG groups — run mvn test -Dgroups=critical first.
The point is the same: the decision is explicit, and the deferred list becomes the risk you report.
Follow-up questions
How do you decide priority?
Business-critical functionality, high-risk and complex modules, defect-prone areas and recently changed code.
Do you skip regression?
Never entirely. Run critical and high-risk regression; defer only non-critical cases when there's no alternative.
How do you communicate what was skipped?
A short list of deferred tests, the areas they cover and the business risk — shared with the product owner or project manager before the release decision.
Do tools help?
Yes — priority fields and filters in test management tools, coverage reports, and tagged automation suites make prioritisation fast and repeatable.
What if a skipped test would have caught a production bug?
Review why it was deprioritised, whether the risk scoring was right, add it to the critical suite if needed, and improve the process — without blame.
Does risk-based testing guarantee zero defects?
No. It focuses effort where failures would hurt most; it reduces risk, it doesn't remove it.
Principles That Apply to All Three
- Prioritise by business risk — the highest-impact functionality first.
- Smoke and sanity first — confirm the build is worth testing.
- Targeted regression over full regression when time is short.
- Automation earns its keep here — a reliable smoke and critical-regression suite is what makes tight deadlines survivable. See how a UI test drives the browser in the Selenium WebDriver Visualizer.
- Communicate transparently — coverage, gaps and risks, so stakeholders decide with full information.
More scenarios: Top 25 Scenario-Based Testing Questions.
From Real Projects
On Apkope, Canolog and Testsigma I took part in Agile ceremonies — daily stand-ups, sprint planning, sprint reviews and retrospectives. The tester's voice matters in each: raising testing effort in planning, blockers in stand-up, and quality issues in the retrospective. Testing works best when it starts with the requirement, not after development finishes. When time is short, test by risk: the flows customers use most and the areas that changed.
📚 Official documentation: Selenium documentation · ISTQB Glossary of testing terms
FAQs
How do you test when there are no documented requirements?
Gather what exists, explore the feature, confirm your understanding with the product owner, test business-critical flows first with exploratory and risk-based testing, and document assumptions.
What do you do when a build arrives late before release?
Smoke test immediately, test core flows and this build's changes, run automated critical regression in parallel, and report coverage and risks before the release decision.
How do you prioritise when time is limited?
Risk-based testing: score by impact and likelihood, run the highest-risk tests first, and report what was deferred.
Do you skip regression under time pressure?
Never entirely — run critical and high-risk regression, and defer only non-critical cases when unavoidable.
Does risk-based testing guarantee zero defects?
No — it concentrates effort where failures would hurt most, but it can't guarantee defect-free software.
