Bug-Handling Scenarios: When a Developer Rejects Your Bug (Answered)

A Developer Rejects Your Bug

Step-by-Step Approach

• Start with calm communication.
  • Don't argue immediately.
  • Recheck that the bug is valid and reproducible.
• Validate your testing.
  • Re-test the same scenario.
  • Use proper test data and preconditions.
  • Verify configuration and environment.
• Provide evidence.
  • Screenshots.
  • Logs.
  • Screen recordings.
  • Exact steps to reproduce.
  • Clear Expected vs Actual Result in Jira.
• Discuss with the Developer.
  • Have a quick call.
  • Discuss during the Daily Stand-up.
  • Many issues turn out to be misunderstandings or environment mismatches.
• Involve Leads if required.
  • QA Lead.
  • BA.
  • Product Owner.

The goal is not to win an argument—it is to ensure product quality.

Professional Conclusion

Sometimes the Developer is correct.

In that case:

• Update the defect status to Rejected or Not a Bug.
• Add proper comments for traceability.

"It's Not a Bug, It's a Feature"

Step-by-Step Approach

• Stay calm and professional.
• Verify the requirement.

Cross-check against:

• Requirement Document
• User Story
• Acceptance Criteria
• Jira
• Confluence

If the behavior does not match the documented requirement, it is a valid defect.

• Gather evidence.

Include:

• Screenshots
• Test Data
• Build Version
• Collaborate with the team.

Discuss with:

• Business Analyst
• Product Owner

Sometimes requirement changes or communication gaps cause confusion.

Final Resolution

Once the BA or PO confirms:

• If it's a bug → Developer fixes it.
• If it's a feature → Close the defect with comments and update the Test Case.

Key Principle

Clarify the requirement rather than debate.

The objective is delivering the expected business behavior—not proving who is right.

A Bug Reappears After a Fix

Step-by-Step Approach

• Verify the issue again.

Use:

• Same environment.
• Same steps.
• Same test data.
• Same preconditions.
• Check for regression.

Determine whether:

• It's a regression caused by a new code change.
• The previous fix was incomplete.
• Document complete evidence.

Include:

• Screenshots
• Logs
• Build Version
• Steps
• Communicate with the Developer.

Report it as a Recurrent Defect.

• Perform Root Cause Analysis if needed.

Look for recurring patterns or dependencies.

• Strengthen Regression Testing.

Once fixed again, include the scenario in the Regression Suite.

You Can't Reproduce Someone Else's Defect

Step-by-Step Approach

• Verify the reported steps.
• Match:
  • Environment
  • Build
  • Test Data
• Check:
  • Browser
  • Configuration
  • Dependencies
• Document your observations.
• Collaborate with the original Tester or Developer.

Compare:

• Environment
• Data
• Steps

Determine whether the issue is:

• Environment-specific
• Browser-specific
• Intermittent
• If required:
  • Log the findings.
  • Escalate for further investigation.
  • Involve the QA Lead or BA.

Professional Conclusion

Always remain objective and evidence-driven.

What Evidence to Include When Logging a Bug

A good bug report should include:

Screenshots

Highlight the exact issue.

Screen Recording

Useful for multi-step scenarios.

Logs

Examples:

• Application Logs
• Browser Console
• API Response Logs

Test Data

Include:

• Username
• Input values
• Steps
• Environment

Environment Details

Include:

• Browser
• Browser Version
• Operating System
• Build Number

URL / Configuration

Mention:

• Application URL
• Environment
• Configuration details

Providing complete evidence helps Developers reproduce and fix issues faster with minimal back-and-forth.

A Bug Is Marked "Won't Fix" or "Deferred"

Step-by-Step Approach

• Understand the reason.

Common reasons:

• Low business impact.
• Complexity.
• Upcoming release.
• Low priority.
• Evaluate business impact.

Assess:

• User impact.
• Business impact.
• Discuss if the issue is critical.

Collaborate with:

• Developer
• BA
• Product Owner

Present supporting evidence.

Sometimes priorities can change.

• Document the final decision.

Record the reason for:

• Won't Fix
• Deferred

This ensures future traceability.

Professional Conclusion

Respect the final prioritization decision once it has been made with complete information.

Justifying a Rejected Bug

When a Developer rejects your defect, justify it professionally—not emotionally.

Step-by-Step Approach

• Stay calm.
• Re-verify the defect.
• Collect solid evidence.

Most important:

• Screenshots
• Screen recordings
• Console logs
• Network logs
• Backend logs (if available)

Evidence makes the discussion factual rather than emotional.

• Validate against:
  • Requirement Document
  • Acceptance Criteria
  • User Story
• Share a detailed explanation with the Developer.
• If the issue remains unresolved:
  • Involve the QA Lead.
  • Involve the BA.

The Developer Disagrees With Your Severity

Often the bug is accepted, but the developer says it's "not really critical". Separate the two questions: severity is the technical impact, which you describe with evidence; priority is a business decision the product owner makes in triage. Explain the impact in user terms ("customers who apply a coupon twice are charged the wrong total"), include how many users or orders are affected if you can measure it, and let triage set the priority. See Severity vs Priority. Further reading: Top 25 Scenario-Based Testing Interview Questions & Answers.

A Rejection Comment That Works

How you respond in the ticket matters as much as the evidence. Compare:

Sample Interview Answer (STAR)

• Situation: A developer rejected my bug that order totals were wrong when two coupons were applied, saying only one coupon could be used.
• Task: Find out whether it was a real defect without damaging the working relationship.
• Action: I re-tested on the latest build, recorded a video, and checked the story — the acceptance criteria allowed two coupons but not on sale items. I shared both in a short call; the difference was a requirement change the developer hadn't seen. The product owner confirmed the new rule.
• Result: The bug was fixed in the same sprint, the story was updated, and we added the case to the regression suite. Replace this with your own example.

Rehearse answers like this under time pressure, with follow-up questions, in the Selenium Interview Simulator. More defect handling: Defect Bug Management.

📚 Official documentation: ISTQB Glossary of testing terms

FAQs

What Do You Do First When a Developer Rejects Your Bug?

Do not argue.

Re-test the issue with proper data and environment, confirm reproducibility, and present evidence instead of opinions.

How Do You Handle "It's Not a Bug, It's a Feature"?

Verify the behavior against the Requirement Document, User Story, and Acceptance Criteria.

If the implementation doesn't match, collect evidence and confirm with the BA or Product Owner.

What Do You Do When a Bug Reappears After a Fix?

Reproduce the issue again, determine whether it's a regression or an incomplete fix, report it as a recurrent defect, and include it in future regression testing.

What If You Can't Reproduce Someone Else's Defect?

Verify the environment, build, browser, configuration, and test data.

Collaborate with the original reporter to identify environment-specific or intermittent behavior.

What Evidence Should a Good Bug Report Include?

• Screenshots
• Screen Recording
• Logs
• API Responses
• Test Data
• Exact Steps
• Environment Details
• Build Number
• URL / Configuration

How Do You Respond to "Won't Fix" or "Deferred"?

Understand the business reason, evaluate the impact, discuss it if it's critical, and document the final decision for future traceability.