Skip to main content

Module 4 · Bug reporting

Writing a bug report

The parts of a useful report and how to make a problem reproducible.

About 10 min reading and 15 min practice (estimates)

Loading progress…

Read

Learning objectives

  • Write a specific title and minimal reproduction steps.
  • State expected and actual results separately.
  • Attach the right evidence and environment details.

Explanation

A bug report is a request for someone else's time. The best ones let a developer reproduce the problem on the first try without asking a question.

  • Title: what is wrong and where — "Cart total ignores removed promotion code", not "Cart broken".
  • Steps: numbered, starting from a known state, each with one action and the exact data used. Remove steps that aren't needed.
  • Expected result: what should happen, ideally quoting the requirement.
  • Actual result: what happened instead, with exact values and messages.
  • Environment: build or version, browser and device, language, account type, test environment.
  • Evidence: a screenshot or short recording, console errors, the failing network request, relevant log lines. Never include real customers' personal data or secrets.
  • Frequency: always, or intermittent ("3 of 10 tries").

One problem per report. If you find two, write two reports and link them. Before reporting, try to reduce the steps to the minimum that still reproduces the problem — this often reveals the real cause.

Example: a weak report and a strong one

Title: Search doesn't work
It's broken when I search, please fix.
Weak: no steps, no data, no expected result.
Title: Search returns no results when the query has a trailing space
Environment: test build 2026.10.3, Chrome 130, English, signed out

Steps
1. Open the catalogue.
2. Type "basket " (with one trailing space) in Search.
Expected: Palm-leaf basket is listed (search ignores
          surrounding spaces — Expected behaviour, Catalogue).
Actual:   "No products match." 0 results.
Frequency: always (5/5). Without the space, 1 result.
Evidence: screenshot attached.
Strong: specific, minimal, checkable. (Illustrative — the training shop handles spaces correctly.)

Common mistakes

  • Vague titles and missing data, so the developer has to guess.
  • Mixing several problems in one report.
  • Writing an opinion ("bad design") as if it were a defect.
  • Screenshots that show the result but not the input that caused it.

Try

Practise what you just read. Answers are checked here; nothing is graded publicly or counts toward Bug Arena.

Exercise

Rewrite this report so a developer could reproduce it: "Checkout doesn't let me order. Tried many times. Fix ASAP!!" Invent plausible, fictional details where needed and mark your assumptions.

Write your answer first, then compare it with the sample solution. It stays on this page only and isn't sent anywhere.

Review

Check yourself — you should now be able to:

  • Write a specific title and minimal reproduction steps.
  • State expected and actual results separately.
  • Attach the right evidence and environment details.

Practise in QA Lab

References

Continue

When you’re ready, mark the lesson complete in the Try step and move on.

Marked as read when you reach the end of the lesson.