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.
- Check with the Developer informally first.
Example:
"Expected result says X, but the application behaves as Y. Can you confirm the expected behavior?"
The developer may already know that the implementation follows the latest requirement.
Update the Test Case with proper traceability instead of logging an invalid 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.
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.
