Examples
Sample QA report and bug report
This page shows the format of our reports using an invented project: a fictional bakery's website with an order form. Every name, address, number and finding below is made up to show the structure. None of it describes a real client or a real result.
Qaveridia is a new practice and has no client reports it can publish. Rather than borrow anyone else's work, we wrote a complete example from scratch. It is short, because a real report on even a small site runs longer, but every section a real report contains is here.
1. Scope statement
Illustrative scope
Project: Harbour Lane Bakery website, relaunch.
In scope: home, about, menu, order form, contact form, delivery information, privacy notice. Seven templates. Order form flow, including the collection-time rule (no collections before 08:00 or after 16:00, no Sundays). Contact form delivery to the shop inbox.
Browsers and devices: Chrome, Edge, Firefox and Safari on desktop; Safari on iPhone; Chrome on an Android phone.
Strands: functional, browser and device, accessibility sample (four templates against WCAG 2.2 AA), security configuration, search metadata, performance on three templates.
Out of scope: the payment provider's own pages; the online shop planned for next year; load testing; screen reader testing.
Dates: first pass 3 to 4 November; retest 6 November; live check on launch day.
2. Summary for the decision-maker
Illustrative summary
We ran 41 test cases and the checklists for six strands. We found 9 defects: 1 blocker, 2 high, 4 medium, 2 low. The blocker stopped orders from being placed on iPhone and has been fixed and retested. One medium defect remains open by agreement, with a fix planned for the first update. The site is ready to launch on the agreed scope, with that one known issue.
3. Defect list
| ID | Summary | Severity | Environment | Status |
|---|---|---|---|---|
| QA-001 | Order form will not submit on iPhone: collection time field rejects every value | Blocker | Safari, iOS | Fixed and retested |
| QA-002 | Contact form messages arrive in the junk folder | High | All | Fixed and retested |
| QA-003 | Menu prices for gluten-free loaves show the old price | High | All | Fixed and retested |
| QA-004 | Mobile menu cannot be closed with the keyboard | Medium | All | Fixed and retested |
| QA-005 | Text on the orange order button fails contrast minimum | Medium | All | Fixed and retested |
| QA-006 | Home page title and description copied from the old site | Medium | All | Fixed and retested |
| QA-007 | Delivery page table scrolls sideways at 320 pixels | Medium | Phones | Open, fix in first update |
| QA-008 | Footer link to the old blog returns a 404 | Low | All | Fixed and retested |
| QA-009 | Favicon missing on Safari | Low | Safari, macOS | Fixed and retested |
4. A full defect report
Illustrative bug report, QA-001
Summary: Order form will not submit on iPhone: collection time field rejects every value.
Severity: Blocker. Happens: every time.
Page: https://harbourlane.example/order/
Environment: Safari on iPhone, iOS 26. Not seen in Chrome on Android or in any desktop browser.
Steps to reproduce: 1. Open the order page in a private tab. 2. Choose two sourdough loaves. 3. Choose tomorrow's date and 10:00 as the collection time. 4. Fill in name, email and phone. 5. Press Place order.
Expected result: the order confirmation page appears and the shop receives the order email.
Actual result: the message "Please choose a collection time between 08:00 and 16:00" appears under the time field, whatever time is chosen. No order is created.
Evidence: recording QA-001-iphone.mp4; the time field sends "10:00 AM" on iPhone and the form expects "10:00".
Retest: fixed on 6 November; order placed successfully with times 08:00, 12:30 and 16:00; 07:45 and 16:15 correctly rejected; Sunday correctly rejected.
5. Extract from the test log
| Case | Environment | Result | Defect |
|---|---|---|---|
| TC-014 Order with collection time inside hours | Safari, iOS | Fail | QA-001 |
| TC-014 Order with collection time inside hours | Chrome, Android | Pass | None |
| TC-015 Order with collection time before 08:00 is rejected | Chrome, Windows | Pass | None |
| TC-016 Order for a Sunday is rejected | Firefox, macOS | Pass | None |
| TC-021 Contact form delivers to the shop inbox | Live server | Fail, then pass on retest | QA-002 |
How to read the defect list
The defect list is ordered by severity, then by ID. The status column tells the story of each item: found, fixed, retested. "Fixed and retested" means we saw the fix work using the original steps. "Open, fix in first update" means the defect is known, was discussed at triage, and was deliberately deferred with a plan. A real report never has a defect with no status, because an item without a status is an item nobody is responsible for.
Severity and status are separate on purpose. A blocker can be fixed and closed; a low-severity item can stay open for weeks. Reading both columns together shows whether a release is safe to launch: in this example, every blocker and high item is closed, and the one open item is medium with a plan.
What a real report adds
A real report also includes the full test log for every case and environment, the accessibility sample notes mapped to WCAG 2.2 success criteria, the security headers as found on the day, the performance figures with test conditions, and the post-launch live check. The structure stays the same: scope, summary, defects with evidence, coverage, and what was left out.
Using this format yourself
You do not need us to report this way. The free bug report generator produces reports with the same fields, the test case builder produces the test log columns, and our guide to collecting test evidence explains how to capture what goes in them.
Want a report like this for your own site?
Describe your forms, flows and launch date. We answer by email, free and without obligation, saying whether a report like this suits your release.
- Written scope
- Fixed quote before any deposit
- Plain-language findings