1. Courses
  2. Engineering Roles
  3. Software Testing and QA
  4. Stop 6

35 minBeginner

Bugs, reports and acceptance

A bug that nobody can reproduce does not get fixed, and a feature that real users cannot use should not ship. This lesson teaches you to write bug reports developers act on, sort them in triage, and run user acceptance testing that ends in a clear go/no-go decision backed by evidence.

By the end you can

  • Write a bug report with a precise title, environment, minimal steps, expected and actual results, evidence and impact
  • Isolate a bug by changing one thing at a time until you have the smallest reproduction
  • Set severity and priority separately, and explain a triage decision
  • Choose between retesting and regression testing after a fix
  • Plan and run a UAT session with real users, and write a go/no-go summary

The everyday picture

You are moving into a new flat. Before you sign the handover, you walk through it with the builder and write a snag list. "Bathroom bad" helps nobody. "The hot tap in the bathroom basin drips about once a second, even when fully closed; video on my phone" gets fixed the same week. Some snags are serious and some are cosmetic. No water in the kitchen stops you living there; a scratch on a door does not.

The builder's own checklist is not enough, though. You only learn that the kitchen is too dark to cook in when you try to cook dinner. So the last step is to live in the flat for a day: cook, shower, plug in the washing machine. Then you decide. Move in, move in while the builder fixes two small things by Friday, or refuse the keys.

This lesson is that walk-through for software. Bug reports are the snag list. Severity and priority sort it. User acceptance testing is the day of living there, with the people who will really use it. The go/no-go decision is signing for the keys, with any conditions written down.

A bug report that gets fixed

In What testing is for you met the chain: a person makes an , which leaves a in the code, which may cause a that someone sees. A bug report describes a failure well enough that a developer can find the defect. The ISTQB Foundation syllabus (version 4.0) calls it a defect report and gives it three jobs: give the people who fix it enough information to resolve it, track the quality of the product, and give ideas for improving the way the team works. The first job is the one you control most.

A developer reads your report with no context, often days later and in a hurry. Every field answers a question they would otherwise have to ask you, and every round of questions costs about a day. These are the parts that matter:

  • Title: what fails, where, and under which condition. Triage scans dozens of titles in minutes, and people search titles to find duplicates.
  • Environment: app version and build number, device and OS version, network, the test account, and the server environment (staging or production). Many bugs live in only one of these.
  • Steps to reproduce: numbered, as few as possible, starting from a known state such as "logged in as a test customer with an empty cart".
  • Expected and actual results: expected quotes the , such as the rule or the acceptance criterion. Actual is what you saw, with no guess at the cause.
  • Evidence: a screenshot or screen recording, log lines, and the of the failing API call (Testing APIs and data shows where to find it).
  • Frequency: "5 of 5 tries" or "3 of 10 tries, only on 4G". The word "sometimes" sends a developer on a long hunt.
  • Impact: who is hurt and how much, in customers, orders, money or store time.
  • Severity and a suggested priority: the next sections explain both.

Here is a report for a boundary bug in checkout. The rule is that delivery costs 150 cents when the cart total is under 2,500 cents and is free from 2,500.

Markdown
## Delivery fee charged on a cart of exactly $25.00 (Android 6.4.0)

**Environment:** Mangrove app 6.4.0 (build 6402), Android 13, 3 GB RAM test phone,
Wi-Fi, staging, test account qa-cust-07 (not a first order)

**Steps**
1. Start with an empty cart.
2. Add 2 x Rice 1 kg at 1,250 cents each (cart total 2,500 cents).
3. Open checkout.

**Expected:** Delivery fee $0.00. Rule: delivery is free from 2,500 cents.
**Actual:** Delivery fee $1.50, order total $26.50.

**Frequency:** 5 of 5 tries. A cart of 2,501 cents gets free delivery; 2,499 is charged correctly.
**Evidence:** screenshot checkout-2500.png, request id 8c1f-42aa (GET /checkout/quote)
**Impact:** every customer whose cart is exactly 2,500 cents pays $1.50 too much.
**Severity:** minor (wrong amount, small, rare cart total). **Suggested priority:** medium.

Notice what the report leaves out: no blame, no guess about which line of code is wrong, no second bug tacked on. One bug per report. Two problems in one report get half fixed and then closed.

Quick check

Which title helps triage most?

Loading the rest of the lesson…