Defect-handling questions test how you behave when things go wrong: bugs rejected, bugs you can't reproduce, critical bugs found during release, bugs that escape to production. These defect-handling scenario interview questions come up for manual and automation roles alike. Each answer shows the steps and the attitude interviewers look for: evidence, clear communication, and ownership without blame.
1. The developer rejects your bug. What do you do?
Re-check the requirement and reproduce the bug, then add clearer evidence (exact steps, test data, environment, screenshots or video, logs). Discuss it calmly with the developer, focusing on expected versus actual behaviour against the requirement. If you still disagree, involve the product owner or BA to decide; don't argue in comments.
2. The developer says it's not a bug, it's a feature.
Check whether the behaviour is documented. If the requirement is silent or ambiguous, raise it with the product owner as a requirement question rather than a defect; if it contradicts the requirement, keep the bug open with the reference. Either way, the decision should be recorded so it doesn't come up again.
3. A bug reappears after it was fixed.
Reopen it (or raise a new linked bug if it's a different cause) with the build number where it reappeared, and ask whether the fix was merged to this branch. Recurring bugs are a strong case for an automated regression test.
4. You can't reproduce a defect someone else found.
Get the exact environment, build, data, browser and device, user role and timing from the reporter; check logs and monitoring for the time it happened; try the same data and network conditions. If it's still not reproducible, mark it as such with your investigation notes and keep monitoring rather than closing it silently.
5. How do you decide severity and priority?
Severity is technical impact (a crash or data loss is critical; a typo is minor). Priority is business urgency, decided with the product owner. A typo in the company name on the home page is low severity but high priority; a crash in a rarely used admin report can be high severity but lower priority.
6. You find a critical bug during release.
Inform the release owner immediately with clear evidence and impact, check whether it exists in production already, and propose options: fix and retest, release with the feature disabled (feature flag), or release with a documented workaround. The decision belongs to the stakeholders; your job is to make the risk clear quickly.
7. How do you handle duplicate defects?
Search the tracker before logging (by keywords, component and error message). If you find a duplicate after logging, link it to the original, add any new information to the original, and close yours as a duplicate.
8. A bug occurs only in production.
Compare production and test environments: configuration, data volume and quality, integrations, feature flags, caching, browser and device mix, and load. Use production logs and monitoring to find the exact conditions, reproduce them in a lower environment with similar data, and add a test so the gap is closed.
9. A bug happens only in one browser (for example Safari).
Confirm the browser version and OS, check the console for errors, and compare rendering and JavaScript support; often it's an unsupported API, a CSS difference or date parsing. Log it with the browser details and add that browser to the regression matrix if it's supported.
10. A customer reports a bug you can't reproduce.
Collect details through support (account, time, device, screenshots), check production logs for that user and time, and try with production-like data. Keep the customer updated through the support team, and record what was checked.
11. How do you verify a bug is fixed?
Retest the original steps with the original data on the build containing the fix, test closely related scenarios and edge cases, run the relevant regression tests, then close it with the build number and evidence.
12. What makes a good bug report?
A clear title, environment and build, preconditions and test data, numbered steps, expected and actual results, severity and priority, and evidence: screenshots, video, console and network logs, API responses. Anyone should be able to reproduce it without asking you.
13. How do you handle intermittent (flaky) bugs?
Record every occurrence with time and conditions, look for patterns (timing, data, concurrency, network), capture logs and video, and try to raise the failure rate (slow network, parallel users) to reproduce it. Log it with the frequency, for example "3 of 20 attempts".
14. The developer marks your bug Won't Fix or Deferred.
Make sure the impact is understood and the decision is made by the product owner, not just the developer. Accept the decision once it's documented, keep the bug linked to the release notes or backlog, and re-raise it if its impact grows.
15. A bug you missed reached production. How do you handle it?
Own it without blame: help reproduce and verify the hotfix, then do a root-cause analysis on why testing missed it (missing scenario, data, environment difference, time pressure) and add the test or process change that prevents it next time.
16. How do you do root cause analysis for a defect?
Ask "why" until you reach a process cause (the 5 whys): for example the bug happened because a rule was misunderstood, because the acceptance criteria were ambiguous, because refinement didn't include QA. Classify causes (requirement, design, code, test, environment) to find patterns across releases.
17. How do you track defects in Jira?
Log bugs with the agreed fields and components, link them to the story and test case, use filters and dashboards for open defects by priority and status, and review them in triage meetings. See working with Jira issues.
FAQs
What do interviewers look for in defect scenario answers?
Evidence-based reporting, calm communication with developers and product owners, clear escalation of risk, and ownership with a focus on prevention rather than blame.
