Bug Management interview questions
Bug Management questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
You paste a screenshot into Slack and walk away. What did you skip?
The strongest answer: A ticket with steps, expected, actual, and a build — Slack is a ping, not a record
Why it works: Exactly. Chat is ephemeral. The bug lives in a system of record with the three parts.
- File a ticket.
- Keep Slack as the ping.
- Include build and steps.
- Do not leave evidence only in chat.
A developer says they cannot act on your bug. What was most likely missing?
The strongest answer: A short repro, what I expected, and what I actually saw — plus the build and environment — not a feeling that “it is broken”
Why it works: Exactly. Repro, expected, actual, and where. That is the job.
- Write steps, expected, actual.
- Name the build and environment.
- A screenshot supports; it does not replace.
- Do not substitute “urgent” for evidence.
You saw a crash once and cannot get it again. What do you file?
The strongest answer: What I did, what I saw, logs if I have them, and “could not reproduce a second time” — I do not file “crash” with no path, and I do not stay silent
Why it works: Exactly. Honest once-only reports still help. Silence and empty P0s do not.
- File the once, honestly.
- Attach logs.
- Say you could not repeat it.
- Do not inflate the priority to keep it alive.
What is the difference between severity and priority?
The strongest answer: Severity is how badly the product is hurt; priority is the order we fix it — a typo on the pay button can be low severity and high priority
Why it works: Exactly. Impact versus order. A good bug names both and does not confuse them.
- Severity = user / system impact.
- Priority = when we fix it.
- They can disagree on purpose.
- Write both; do not merge the fields.
A bug “works on my machine” and fails in staging. What do you write first?
The strongest answer: The environment, build, and the data I used — “staging, build 184, user with an empty cart” — not another screenshot of the same screen
Why it works: Exactly. Env + build + data is how “works on my machine” becomes a bug.
- Write env, build, data.
- Do not assume “the” environment.
- Staging ≠ local ≠ prod.
- Automation reports the same three.
You file “the page looks weird.” What should “expected” have been?
The strongest answer: A specific, checkable statement — “the price stays visible at the largest font” — not “it should look nice”
Why it works: Exactly. Expected is a claim someone can agree or disagree with.
- Expected must be checkable.
- Point at the spec or the last good build.
- Do not use “looks weird” as expected.
- Video supports the sentence.
A crash on a dead settings screen and a typo on Pay now both land. How do you talk priority?
The strongest answer: I say the crash may be higher severity, and the typo may still be higher priority if pay is today — I do not silently pick one number for both fields
Why it works: Exactly. Speak both fields. A dead screen can wait if pay is on fire in a different way.
- Separate severity and priority out loud.
- Pay-today can beat a rare crash.
- Do not use “always.”
- Do not let Slack volume triage.
A developer closes your bug as “works for me.” What do you do?
The strongest answer: I ask which build and data they used, I retry on that pair, and I reopen only with the gap — I do not reopen as a fight
Why it works: Exactly. Compare setups. Reopen with evidence. Leave the ego out.
- Compare env and data.
- Retry their pair.
- Reopen with the gap.
- Do not make it personal.
A bug needs to show a user’s order. What do you attach?
The strongest answer: A masked id, a test account, or a redacted shot — not a real name, card, or address in the ticket or the screenshot
Why it works: Exactly. Evidence without other people’s lives. Test accounts exist for this.
- Mask PII.
- Use a test account.
- Redact screenshots.
- Never attach a card or a real address.
Two people cannot agree if a bug is fixed. What field would have ended the argument?
The strongest answer: The build / version / commit on the report and on the “fixed” comment — “latest” is not a version
Why it works: Exactly. Versions end he-said-she-said. Latest is not a number.
- Put a build on the file.
- Put a build on the fix.
- Never say only “latest.”
- Then retest that pair.
What makes a bug “actionable” for a developer in this interview?
The strongest answer: They can start without a meeting: steps, expected, actual, build, env, and a hint at scope (one user / all users, one locale) — I do not make them play detective for an hour
Why it works: Exactly. Actionable means start now. Guessing their revert is not your job.
- All the fields, no meeting required.
- Scope the blast radius if you can.
- Attach evidence.
- Do not prescribe a revert you cannot defend.
A junior’s bug has a great video and no steps. How do you coach the rewrite?
The strongest answer: Numbered steps a stranger can follow, expected, actual, env/build, and then the video — I do not praise the video as a substitute
Why it works: Exactly. Teach the template. Video last, not instead.
- Steps a stranger can run.
- Expected and actual.
- Env and build.
- Video as attachment.
Which attachment actually helps a developer?
The strongest answer: The har / log / correlation id around the failure, a redacted screenshot, and the build — not a 4K screen recording of my whole desktop
Why it works: Exactly. Tight evidence. Desktop tours are how tickets get muted.
- Logs and an id.
- Redacted shot.
- Build number.
- No desktop documentaries.
The fix is on staging and the bug is still there. How do you reopen?
The strongest answer: On the same ticket, with the new build, the same steps, and what still fails — I do not open a duplicate “for visibility”
Why it works: Exactly. Same ticket, new evidence. Duplicates destroy history.
- Reopen, do not duplicate.
- New build + same steps.
- Keep the history.
- Do not escalate by clone.
Legal must fix a rare, ugly consent string this week. The crash-on-rare-screen waits. How do you record that?
The strongest answer: High priority, moderate severity for the string; high severity, lower priority for the rare crash — I write the why so nobody “corrects” the fields overnight
Why it works: Exactly. Disagreement is information. Write the why.
- Let the fields disagree.
- Write the reason.
- Do not P0 everything.
- Compliance bugs are bugs.
Your developers are eight hours away. What changes in the bug?
The strongest answer: It must be solvable without a meeting: data, logs, timezone, and a recording — I do not write “call me” as step 1
Why it works: Exactly. Async-actionable is the bar. Call-me is a luxury they do not have tonight.
- No “call me” as the repro.
- Attach what they will need at 2 a.m.
- Name timezone and data.
- Write for a stranger on their side.
You review a junior’s bug that will start a fight. What do you edit?
The strongest answer: Tone and missing fields — I keep their name on the ticket and I do not rewrite it as a dunk on the developer
Why it works: Exactly. Coach the fields and the tone. Credit stays with them.
- Fix fields and tone.
- Keep their name.
- No dunking.
- The goal is a fix, not a win.
Leadership wants “fewer bugs.” What do you show instead of a raw count?
The strongest answer: Escapes by severity, age of the pack, and whether we found them before the store / the customer — a count of tickets is how you punish reporting
Why it works: Exactly. Escapes and impact. Punishing volume is how you go blind.
- Show escapes, not filings.
- Keep severity on the escape.
- Do not reward silence.
- Do not set a “file less” target.
Prod is down for a subset of users. You are in the channel. What is QA’s job in the first hour?
The strongest answer: Scope: who, which build, which path, a reliable repro if we can, and I do not start a process argument about ticket fields
Why it works: Exactly. Scope and repro. Pedantry and “I told you so” wait.
- Who / build / path.
- Repro if you can.
- Help mitigate; do not lecture.
- Save the I-told-you-so.
Engineering says QA “throws bugs over the wall.” What do you change in the writing?
The strongest answer: I sit closer: a draft in the PR or the story, a severity that matches impact, and a question when I am unsure — I do not use the tracker as a scoreboard
Why it works: Exactly. Actionable, early, not a sport. The wall is a writing and timing problem.
- File early, close to the change.
- Match severity to impact.
- Ask when unsure.
- Do not keep score.
A severity-1 escaped. How do you run the learning?
The strongest answer: What oracle was missing, where a cheaper test could have lived, and one change to the road — I do not run a blame circle or a 40-page novel
Why it works: Exactly. Oracle, cheaper layer, one road change. Blame is not learning.
- Find the missing oracle.
- Put a cheaper test on the road.
- One change, owned.
- No blame circle.
The tracker is full of zombies: dupes, missing builds, “works for me.” What programme do you run?
The strongest answer: A writing bar, a weekly hygiene, and coaching — I do not buy a new tracker to flee the mess, and I do not mass-close to “clean the board”
Why it works: Exactly. The system is the writing. Tools and mass-close are how you lose history.
- Teach the writing bar.
- Hygiene with a human.
- Do not flee to a new tool.
- Do not mass-close.
After a customer-facing incident, what does QA change besides “add a case”?
The strongest answer: The oracle and the layer: a contract, a monitor, or a seam — a UI case alone is how we learn the same thing yearly
Why it works: Exactly. Cheaper layer, better oracle. A souvenir UI case is a souvenir.
- Move the check left or out (monitor).
- Improve the oracle.
- Do not souvenir a UI case only.
- Do not put customer names in the pack.