Interview Drills — Bug Reporting & Quality

Open-ended interview questions. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). Bug reporting is the core daily skill of QA, so interviewers probe it hard — practice thinking aloud, and always anchor on reproducibility, clear expected-vs-actual, and the right severity/priority call. The app can role-play these as mock interviews (see mock-interview.md).

The universal bug-quality structure: State the goal (a developer fixes it fast, with no back-and-forth) → make it reproducible (exact steps from a known start) → show expected vs. actual + evidence + environment → classify severity and priority → place it in the life cycle and say what happens next. Use it on almost any "report/triage this bug" question.

D1

difficulty: easy
concept: bug-reporting What makes a bug report good? Walk me through the fields you'd include.
Framework: Lead with the #1 quality (reproducibility) → list the anatomy (title, steps to reproduce, expected, actual, environment, evidence, severity/priority) → say why each earns its place → close on the habit that ties them together (write for the developer who has to fix it).
Model answer: "The single most important quality is reproducibility — clear steps that let a developer hit the bug on their own machine. So my report has a specific title ('Checkout crashes when the promo-code field is left empty', not 'checkout broken'), numbered steps from a known starting point, the expected result, the actual result, the environment (device, OS, browser/version, build — because many bugs are condition-specific), evidence like a screenshot or recording plus any console error, and a severity/priority. Each field exists to remove a round-trip: environment so they reproduce it, evidence so they believe it, expected-vs-actual so they know what 'fixed' means."
Rubric: Strong answers name reproducibility as the top priority, recite the full anatomy, and justify fields by how they save developer time. Weak answers list fields mechanically with no 'why', forget environment or evidence, or give a vague title as their example.

D2

difficulty: easy
concept: severity-vs-priority What's the difference between severity and priority? Give an example where they diverge.
Framework: Define both crisply (severity = how bad the impact; priority = how urgently to fix) → stress they're set on different axes by different owners → give one example where they diverge in each direction → note who decides priority.
Model answer: "Severity is the technical impact of the bug; priority is the business urgency of fixing it. They often diverge. A crash in a rarely-used admin export is high severity but low priority — it's bad behavior, but almost no one hits it. The company's name misspelled on the homepage is low severity (nothing breaks) but high priority because it's on every visitor's first impression before launch. Severity I can usually assess from the impact; priority is a call the team or PM makes by weighing reach, timing, and business cost."
Rubric: Strong answers define the two on distinct axes and give divergent examples in both directions, showing priority is a business call. Weak answers treat the terms as synonyms, only give a high/high example, or can't explain who owns priority.

D3

difficulty: medium
concept: reproducibility-and-step-reduction You found a bug after a long, messy session of clicking around. How do you turn that into a report a developer can act on?
Framework: Confirm it's real (reproduce it a second time) → find the shortest path that still triggers it (reduce steps, drop irrelevant actions) → pin the trigger (which input/sequence/state/device) → capture evidence and environment → check it's not a duplicate → write it up blamelessly, one bug per report.
Model answer: "First I reproduce it again to confirm it's real and not a fluke. Then I reduce: I retrace and strip out every step that isn't needed until I have the shortest sequence that still breaks it — that bisecting often reveals the actual trigger, say 'only fails when the cart has 0 items'. I capture a screen recording, the console error, and the environment (build, browser/version). I search the tracker for duplicates. Then I write one clear report: specific title, the minimal numbered steps, expected vs. actual. Reduced steps mean the developer can pinpoint the cause instead of replaying my whole session."
Rubric: Strong answers reproduce-to-confirm, actively reduce steps to isolate the trigger, capture evidence/environment, and check for duplicates. Weak answers just paste the long click-trail, skip confirming it's real, or never try to minimize the repro.

D4

difficulty: medium
concept: cannot-reproduce A developer marks your bug 'Cannot Reproduce' and bounces it back. What do you do?
Framework: Treat it as an information gap, not a fight (blameless) → diff your environment/data/state against theirs (build, OS, browser, account, feature flags, seeded data) → reproduce again yourself and capture stronger evidence (recording + exact build + console/network) → tighten and re-share the steps → if it's genuinely intermittent, say so and gather frequency/conditions; pair live if needed.
Model answer: "'Cannot Reproduce' usually means the report was missing a condition, so I close that gap rather than push back. I reproduce it again on my side and note exactly what differs — build number, browser/version, OS, the specific account or data, any feature flag. Often the trigger is environmental: it only happens on a logged-in account with existing orders, or only on the staging build they don't have. I attach a screen recording plus the console/network error, rewrite the steps to include that missing precondition, and reassign. If it's truly intermittent I label it as such, note how often and under what conditions, and offer to repro together on a call."
Rubric: Strong answers stay blameless, hunt for the missing precondition (environment/data/state/flags), and come back with stronger evidence and a clear repro. Weak answers get defensive, just re-send the same steps, or accept the close without investigating.

D5

difficulty: medium
concept: duplicates-and-triage While triaging, you suspect a new bug is a duplicate of an existing ticket. How do you handle it — and what if you're wrong?
Framework: Search before filing/triaging (keywords, error text, component, area) → compare on root cause and behavior, not just symptoms → if it's a true duplicate, link it to the original and carry over any new info (extra repro steps, environment, evidence) → if you're unsure, keep it open and note the suspected link → recognize when similar symptoms are actually two different bugs.
Model answer: "I search the tracker by the error message, the component, and a few symptom keywords. The key check is whether it's the same cause and behavior, not just a similar-looking symptom — two different bugs can both produce a blank screen. If it's clearly the same defect, I mark it Duplicate, link it to the original, and merge anything new I have: an additional repro path, a cleaner recording, another affected environment. If I'm not sure, I leave it open and add a comment 'possibly related to #123' so we don't lose a real bug by collapsing it too early. Over-merging hides distinct issues; that's worse than a quick second look."
Rubric: Strong answers search first, compare on root cause vs. surface symptom, link and carry over new info, and flag the risk of wrongly merging distinct bugs. Weak answers dedupe on symptoms alone, discard the new ticket's extra detail, or never consider that look-alikes can be separate defects.

D6

difficulty: hard
concept: bug-life-cycle Walk a bug through its full life cycle, from the moment you find it to closed — and name the places it can branch off.
Framework: New/Open (you report it well) → Assigned (a developer picks it up) → In Progress/Fixed (they fix and mark it) → Re-test/Verified (you confirm on the right build) → Closed; then the branches — Reopened if your re-test fails, plus Won't Fix, Duplicate, and Cannot Reproduce — and tie each branch back to report quality and a regression check.
Model answer: "It starts New/Open when I file a clear, reproducible report. It moves to Assigned when a developer takes it, then In Progress and Fixed when they ship the change. Now it's my job again: I Re-test on the build that contains the fix, using my original steps, and I also run a quick regression around it to make sure the fix didn't break something nearby. If it's genuinely fixed I mark it Verified and Closed; if it still repros, I Reopen with fresh evidence. Off the main path: the team may mark it Won't Fix (a real but low-priority issue we choose to live with), Duplicate (link to the original), or Cannot Reproduce — and that last one usually points back at a thin original report, so I'd strengthen the steps. The thread throughout is that good reporting up front and disciplined re-testing at the end keep the cycle short."
Rubric: Strong answers narrate the full path in order, place the QA re-test + regression at the end, and explain each branch (Reopened, Won't Fix, Duplicate, Cannot Reproduce) — ideally tying Cannot Reproduce back to report quality. Weak answers garble the order, forget QA re-tests the fix, or can't name the branches and what triggers them.