Bug Report Writing

Practice writing clear, reproducible bug reports for a set of observed defects — covering severity vs. priority, environment details, steps to reproduce, and evidence notes to developer-actionable standard.

Role

Manual QA engineer

Difficulty

Beginner

Time limit

60 min

Scenario

You are a QA engineer doing exploratory testing on a new e-commerce platform before it goes to staging. During your session you observe four defects: (1) The checkout order summary shows the item subtotal but omits the 10% sales tax that is enabled in site settings. (2) Clicking 'Forgot Password' and submitting a registered email address never delivers a reset email. (3) On iOS Safari the hamburger navigation menu opens but overlaps the page body content, making links underneath it unclickable. (4) The flight-booking date picker allows the user to select yesterday's date as a departure date and proceeds without an error. Your task is to file a clear, developer-actionable bug report for each defect.

Requirements

1.Write one bug report per defect — four reports total, each covering a single issue
2.Each report must include: Bug ID, Title/Summary, Environment (OS, browser/app version, device), Steps to Reproduce, Actual Result, Expected Result, Severity, and Priority
3.Assign Severity (impact on the system/user) and Priority (urgency to fix) independently — at least two reports must have Severity ≠ Priority, with a one-sentence justification for each discrepancy
4.Write bug titles that are concise and specific: describe the symptom, component, and context in 15 words or fewer
5.Identify the component or module each bug belongs to (e.g. Checkout / Tax Calculation, Auth / Email, Navigation / Mobile) and note it as a label or field
6.For each report, note the evidence you would attach (screenshot, screen recording, network log, console output) and explain in one sentence why that evidence is diagnostic
7.Include at least one each of Critical, High, Medium, and Low severity across the four reports

Starter data

›App: ShopFlow — a demo e-commerce platform with cart, checkout, account, and booking modules
›Tax setting: 10% sales tax is enabled globally under Settings → Billing → Tax
›Password reset flow: Settings → Forgot Password → enter registered email → receive link → set new password
›Mobile nav: hamburger icon at top-right on viewports < 768 px; expected to open a slide-in drawer
›Booking date picker: JavaScript date picker on /flights/search; departure date must be today or future
›Test accounts: customer@example.com (registered, active), admin@example.com (admin role)

Expected deliverables

✓Four completed bug reports in your chosen format (Jira-style fields, Markdown template, or spreadsheet)
✓Severity vs. priority filled independently on every report, with a one-sentence rationale for any report where they differ
✓Bug titles of 15 words or fewer that uniquely identify each defect
✓Component/label filled for all four reports
✓Evidence notes for all four reports (specify the artifact and why it is diagnostic, even if you cannot capture it in a dry run)
✓A brief prioritisation summary (3–5 sentences) explaining the relative urgency of the four defects and which you would escalate first

Evaluation rubric

Dimension	What reviewers look for
Reproducibility and clarity of steps	Are the steps atomic, ordered, and unambiguous? Could a developer cold-read the report and reproduce the defect in under five minutes without asking a single clarifying question? Steps such as 'navigate to checkout' fail this bar — they must name the starting state, exact actions, and test data used.
Severity vs. priority distinction	Are severity (how badly the defect impacts the system or user) and priority (how urgently it must be fixed) treated as independent axes? The checkout tax bug should be Severity: Critical (incorrect financial data shown to every user) but may be Priority: High rather than Critical if a server-side fix can be deployed without a full release. Reports that copy severity into priority without thought show a gap here.
Completeness of environment and evidence	Is the environment section specific enough to be reproducible? 'Mobile browser' is not sufficient; 'iPhone 14 / iOS 17.2 / Safari 17.2 / viewport 390×844' is. Evidence notes should name the artifact (e.g. network HAR file showing no POST to /email/send) and explain why it proves the defect rather than listing generic evidence types.
Communication — developer-actionable writing	Is the Actual Result a specific, observable system response (e.g. 'Order summary displays subtotal $29.99 with no tax line; total shown as $29.99')? Is the Expected Result equally specific ('Order summary displays subtotal $29.99 + tax $3.00 = total $32.99')? Reports where Actual Result reads 'It doesn't work' or Expected Result reads 'It should work correctly' are not developer-actionable.
Title quality and component labelling	Does each title follow the pattern [Component] [Symptom] [Context] in 15 words or fewer? For example: 'Checkout — order summary omits 10% sales tax on all orders' versus 'Tax not showing'. Component labels should map to a real module in the codebase or product area, not generic categories like 'Frontend'.
Prioritisation judgement	Is the four-bug prioritisation summary internally consistent? Does the candidate recognise that a financial accuracy defect (checkout tax) is the highest-risk item even though a UI overlay (mobile nav) might feel more visible? Does the date-picker defect's priority get correctly contextualised against the business impact of allowing invalid bookings?

Sample solution outline

›BUG-001 — Checkout: order summary omits 10% sales tax on all orders | Sev: Critical / Pri: High | Steps: (1) Log in as customer@example.com, (2) Add any item to cart, (3) Navigate to /checkout, (4) Observe the order summary panel | Actual: line items show subtotal only; no tax line; total equals subtotal | Expected: tax line '$X.XX (10%)' and updated total appear | Component: Checkout / Tax Calculation | Evidence: screenshot of order summary + network request to /cart/summary showing tax:0 in response JSON
›BUG-002 — Auth: password reset email never delivered after valid submission | Sev: High / Pri: Medium (workaround: admin can reset via back-office) | Steps: (1) Navigate to /forgot-password, (2) Enter customer@example.com, (3) Click 'Send Reset Link', (4) Check inbox + spam folder after 10 min | Actual: no email received after 10 minutes | Expected: reset email received within 2 minutes | Component: Auth / Email | Evidence: network HAR showing POST /auth/password-reset returns 200 but no email event logged in SendGrid dashboard
›BUG-003 — Navigation: mobile hamburger menu overlaps page content on iOS Safari | Sev: Medium / Pri: Medium | Steps: (1) Open site on iPhone 14 iOS 17.2 Safari, (2) Tap hamburger icon at top-right, (3) Observe menu and page content below | Actual: menu div renders over page body; links beneath are unclickable | Expected: menu opens as a slide-in drawer; body content remains accessible beneath an overlay | Component: Navigation / Mobile | Evidence: screen recording showing the overlap and failed click on an underlying link
›BUG-004 — Booking: date picker accepts past departure dates without validation | Sev: Low / Pri: Low (low booking volume on affected route; workaround: server-side validation will reject the booking at submission) | Steps: (1) Navigate to /flights/search, (2) Click the departure date picker, (3) Select yesterday's date | Actual: date is accepted; form proceeds to results | Expected: past dates are disabled (greyed out) and unselectable | Component: Booking / Date Validation | Evidence: screenshot of picker with past date selected + a second screenshot showing the results page loaded successfully
›Severity covers four levels across the set: Critical (BUG-001), High (BUG-002), Medium (BUG-003), Low (BUG-004) — satisfying the rubric requirement
›Severity ≠ Priority examples: BUG-001 (Critical / High — admin back-end can override tax for refunds while dev fixes root cause), BUG-002 (High / Medium — admin reset workflow provides a temporary workaround)

Common mistakes

Treating severity and priority as synonyms — 'this is critical so it must be urgent' ignores that a rarely-used but broken flow can be Severity: Low yet Priority: High due to a compliance deadline, and vice versa
Writing vague steps such as 'navigate to checkout and observe the total' — steps must be atomic and include starting state, exact navigation path, and test data (e.g. 'Add item SKU-001 at $29.99 to cart, then navigate to /checkout')
Writing Expected Result as 'It should work correctly' or 'The tax should show' — expected result must be a specific, observable outcome with concrete values
Filing one report for multiple bugs — each unique defect gets its own report so it can be individually tracked, assigned, reproduced, and closed
Omitting environment details or writing 'mobile browser' without specifying OS version, browser version, and device model — a bug that only reproduces on iOS Safari 17.2 but not Chrome 120 is unreproducible without that context
Not noting evidence to attach, or writing only 'screenshot' — specify what the screenshot must capture and why it proves the defect (e.g. 'screenshot of order summary showing total $29.99 with no tax line, proving the omission on the rendered UI')
Assigning every bug Critical severity — over-inflation of severity makes triage meaningless and signals poor calibration; reserve Critical for defects that corrupt data, block core workflows, or expose security vulnerabilities

Submission checklist

Four separate bug reports, one per defect
All required fields present on every report: Bug ID, Title, Environment, Steps to Reproduce, Actual Result, Expected Result, Severity, Priority
Severity and priority filled independently on all reports (not just copied from each other)
At least two reports where Severity ≠ Priority, each with a one-sentence rationale
At least one each of Critical, High, Medium, and Low severity across the four reports
Bug titles are 15 words or fewer and identify symptom + component + context
Component/label field present on all four reports
Evidence notes present for all four reports (name the artifact and state why it is diagnostic)
Prioritisation summary paragraph (3–5 sentences) included

Extension ideas

+Add a Root Cause Hypothesis field to each report and identify the likely code area (e.g. 'tax rate not applied in cart-summary service before rendering')
+Write a regression test case for each bug to verify it stays fixed after the developer's fix is deployed
+Group the four bugs by the test phase most likely to catch them (unit, integration, system, exploratory) and justify your groupings