A Requirement Is Unclear and the BA Is Not Available
The Situation
Requirements are usually explained by the BA, but sometimes the requirement is ambiguous, acceptance criteria are missing, the flow isn't clearly defined, or the BA is on leave, busy, or unreachable.
This is very common in Agile projects.
The Problem
- Risk of misunderstanding the requirement.
- Testing the wrong functionality.
- Raising invalid defects.
- Wasting time on rework.
Step-by-Step Approach
- Analyze the requirement carefully.
- Read it multiple times.
- Separate what is clear and unclear.
- Identify whether the confusion is in logic, validation, UI, or data.
- Check available project documents.
- Jira User Story
- Acceptance Criteria
- BRD/FSD
- UI Mockups/Wireframes
- Confluence
- Previous Sprint Stories
- Check the existing application behavior.
- Compare with similar modules.
- Verify existing validations.
- Discuss with Developers or Senior QA.
- Developers may already know the expected behavior.
- Senior QA or Lead may have clarification.
- Product Owner may provide partial information.
- Document your assumptions and proceed with the safest interpretation until the BA becomes available.
You Find a Blocker on the First Test Case Itself
The Situation
A blocker defect means further test cases depend on this functionality or the environment itself is unavailable.
Step-by-Step Approach
- Confirm it is truly a blocker.
- Re-execute the test case.
- Verify in another browser or environment.
- Analyze impact and dependency.
- Identify dependent test cases.
- Check whether independent scenarios can still be executed.
- Raise a Blocker defect immediately.
- Severity: Blocker
- Include clear steps.
- Attach screenshots or videos.
- Inform the Lead and Development Team immediately.
- Continue executing independent test cases while waiting for the blocker to be resolved.
The Expected Result in the Test Case Is Wrong
The Situation
The expected result written in the Test Case or Requirement is incorrect.
Usually caused by:
- Requirement changes.
- Miscommunication.
- Outdated documentation.
Step-by-Step Approach
- Do NOT raise a defect immediately.
- Re-analyze the requirement carefully.
- Validate against business logic.
- Ask the developer what they built, then confirm the intended behavior with the BA or Product Owner.
Example:
"Expected result says X, but the application behaves as Y. Can you confirm the expected behavior?"
The developer may know the implementation follows a newer requirement — but the developer describes what the code does, not what it should do. The BA or Product Owner decides the correct behavior. If they confirm the test case is outdated, update the test case (and the requirement or story) with a note of who confirmed the change; if they confirm the original expectation, it's a genuine defect.
A Bug in UAT That Dev Says Isn't Reproducible
The Situation
QA can reproduce the bug in UAT, but Developers cannot.
This is common because of:
- Environment mismatch.
- Configuration differences.
- Timing or sequence issues.
Step-by-Step Approach
- Stay calm and professional.
- Reproduce the issue again in the same environment.
- Compare environments carefully.
Check:
- Environment (QA/UAT)
- Build Version
- Configuration
- Database
- Browser
- Provide complete evidence.
Include:
- Screenshots
- Screen recordings
- Logs
- Exact steps
- Build number
- Pair with the Developer and reproduce the issue together.
New Build, but Smoke Testing Itself Is Failing
The Situation
Smoke testing starts on a new build, but the smoke test cases fail.
A smoke failure is a STOP SIGNAL.
Step-by-Step Approach
- Confirm the smoke failure.
- Re-run the failed cases.
- Verify on another supported browser.
- Identify the nature of the issue.
- Environment issue?
- Functional issue?
- If the core functionality is broken:
- Reject the build.
- Attach evidence.
- Inform the team immediately.
Do not continue detailed testing on an unstable build.
100 Test Cases and Only 3 Hours Left
The Situation
This is a classic Risk-Based Testing scenario.
Step-by-Step Approach
- Understand the release context.
- Identify critical business functionality.
- Execute:
- High-risk test cases.
- High-impact functionality.
- Critical business flows.
- Prioritize using:
- Severity
- Priority
- Ensure Smoke and Sanity coverage.
- Clearly communicate:
- What was tested.
- What wasn't tested.
- Associated risks.
This helps stakeholders make an informed release decision.
Client Wants to Release Today, but You Found a High-Severity Bug
This is a release decision scenario.
Determine the actual business impact of the bug, communicate it clearly with evidence, and allow stakeholders to balance business urgency against product quality.
The tester's responsibility is to present the risk—not to independently approve or reject the release.
This scenario is covered in detail in the Production Incidents pillar.
A Critical Defect Is Found in Production
This is a Production Defect scenario.
The complete approach includes:
- Reproducing the issue.
- Assessing business impact.
- Root Cause Analysis.
- Communication with stakeholders.
This topic is covered completely in the Production Incidents & RCA pillar.
It Works on Your System but Fails on Others
The Situation
The application works correctly on one system but fails on another.
Usually caused by:
- Environment differences.
- Browser differences.
- OS differences.
- Cache/Cookies.
Step-by-Step Approach
- Do NOT jump to conclusions.
- Reproduce the issue together.
- Compare environment details.
Check:
- QA/UAT environment
- Browser
- Browser version
- Operating System
- Device
- Clear cache and cookies if required.
Requirements Change at the Last Minute
The Situation
Requirement changes are common in Agile projects.
Step-by-Step Approach
- Do NOT panic.
- Understand the requirement change completely.
- Perform impact analysis.
This is the most important activity because it identifies:
- Existing functionality affected.
- Regression scope.
- Risk.
- Update the Test Cases.
- Communicate:
- Updated scope.
- Timeline changes.
- Regression impact.
Test Data Isn't Available on the Day of Execution
- Check whether the data can be created through the application itself, an API, or a SQL script in the test environment.
- Ask the team that owns the data (developers, DBA, another QA team) — and log the dependency so it's visible in the stand-up.
- Execute the test cases that don't need it; mark the others Blocked with the reason, not Failed.
- Afterwards, add the data setup to the test plan or automate it so it doesn't block the next cycle.
Quick Reference: Which Status and Who to Tell
| Situation | Test case status | Tell |
|---|---|---|
| Behavior differs from a confirmed requirement | Failed + defect | Developer via the bug; lead if severe |
| Can't run because of another defect or the environment | Blocked | Lead and developers, immediately for blockers |
| Expected result may be outdated | On hold until confirmed | BA / Product Owner |
| Requirement unclear | Not run (or run against a documented assumption) | BA / Product Owner; note the question on the story |
| Test data missing | Blocked | Data owner and lead |
Practice these decisions on realistic situations in the Manual Testing Simulator. More scenarios: Requirement Changes & Release Pressure.
From Real Projects
Before any automation, my work on each project started with the requirement: understanding the business flow, identifying scenarios, writing test cases and getting them reviewed. On Canolog, where sales, inventory, finance, service and parts all connect, that analysis is what found the gaps between modules. Execution was tracked in TestRail and defects in Jira. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. When a requirement is unclear, write down your assumption and confirm it with the business analyst.
📚 Official documentation: ISTQB Glossary of testing terms
FAQs
What Do You Do When a Requirement Is Unclear and the BA Is Unavailable?
Analyze the requirement carefully, review all available documentation (User Story, Acceptance Criteria, BRD, Mockups, Confluence), verify existing application behavior, discuss with Developers or Senior QA, and document your assumptions.
How Do You Handle a Blocker on the Very First Test Case?
Confirm it is a genuine blocker, analyze dependencies, raise a Blocker-severity defect with proper evidence, and continue executing independent test cases.
What If the Expected Result in the Test Case Is Wrong?
Don't raise a defect immediately.
Re-analyze the requirement, validate business logic, confirm with the Developer, and update the Test Case accordingly.
What If a UAT Bug Isn't Reproducible for Developers?
Reproduce the issue again, compare environments carefully, gather screenshots, logs, build details, and work together with the Developer to reproduce it.
What If Smoke Testing Fails on a New Build?
Verify that it isn't an environment issue.
If core functionality is genuinely broken, reject the build with proper evidence.
Smoke failure is a stop signal.
How Do You Handle 100 Test Cases in Only 3 Hours?
Apply Risk-Based Testing.
Prioritize critical business functionality, high-risk and high-impact scenarios, ensure Smoke and Sanity coverage, and clearly communicate executed and pending test cases. A closely related topic: Top 25 Scenario-Based Testing Interview Questions & Answers.
