QA Engineer interview question
What makes a high-quality bug report?
A strong bug report has a precise title, environment and build, minimal reproducible steps, expected and actual behavior, frequency and impact, evidence such as logs or video, relevant data, and no unsupported diagnosis.
Direct answer
What a strong answer covers
How it works
A good report lets someone who has never seen the bug reproduce it in minutes and judge its importance without asking questions. The title states the symptom and the condition. The environment section gives build number, platform, browser or device, and account type. The steps are minimal and numbered, starting from a known state, with the exact data used. Expected and actual behaviour are separate sentences. Frequency and impact say how often it happens and who it affects. Evidence includes logs, a screenshot or recording, request IDs, and console errors. Diagnosis is offered only when supported by evidence and clearly marked as a hypothesis.
Example
Title: Checkout returns 500 when the shipping address contains an apostrophe. Environment: web build 4.12.3, Chrome 128, standard account. Steps: add any item, proceed to checkout, enter the address line O’Connor Street, submit. Expected: order confirmation. Actual: error page, request ID 7f3a-… in the footer. Frequency: every time; affects any customer with an apostrophe in the address, roughly 2 percent per the address dataset. Evidence: HAR file and server log excerpt attached. Hypothesis: unescaped quote in a query, based on the log line.
Common mistakes
- Writing does not work as the description.
- Listing twenty steps that include unrelated navigation.
- Asserting the root cause with no evidence and sending developers down the wrong path.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.