QA Engineer Interview Question

What makes a good bug report, and what is the difference between severity and priority?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

A good report lets someone else reproduce the issue without asking you anything: a specific title, exact steps from a known starting state, expected versus actual result, environment and build, and evidence such as a video, logs, or a network trace. Severity is the technical impact of the defect; priority is how soon it gets fixed. A cosmetic bug can be low severity and high priority.

Why interviewers ask this

Bug reports are a tester's main written output, so this is a direct check on craft. Interviewers want the reproduction focus and the evidence, and they specifically want the severity and priority distinction with an example where the two diverge, because candidates who conflate them tend to argue with product managers about triage instead of describing impact and letting the business prioritize.

How to structure your answer

  • State the goal: reproducible without a conversation.
  • List the required elements in order.
  • Define severity and priority separately.
  • Give an example where they diverge in each direction.
  • Note that you describe impact and the business sets priority.

Example answer

Spoken example, first person

My test for a bug report is whether a developer who has never spoken to me can reproduce it from the report alone. So the title says what breaks and where, specifically, not something like checkout broken. Then preconditions, meaning the exact starting state and account type, numbered steps someone can follow literally, expected result, actual result, and the environment and build number, because a bug filed against last week's build wastes everyone's afternoon. Evidence goes in every time: screen recording, the network request and response, and the relevant log lines with timestamps. On severity versus priority, severity is how badly the system is broken and priority is how soon we fix it, and they are set by different people for different reasons. A data corruption bug in a feature two people use is high severity and low priority. A typo spelling the company name wrong on the landing page is trivial severity and gets fixed this morning. I make sure I describe impact accurately, how many users, whether there is a workaround, whether money or data is at risk, then let the product owner set priority, because that is their call.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • How would you write the title for a bug you cannot yet reproduce reliably?
  • What would you do if a high severity bug keeps getting deprioritized?
  • How much investigation should a tester do before filing?

Related qa engineer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot