VisaSpark
Sign in
beginner17 min

Writing Defect Reports Testers Trust

A bug a developer can't reproduce is a bug that doesn't get fixed. Learn the anatomy of a defect report that actually gets acted on.

What you'll learn

  • Identify the essential elements every defect report needs
  • Rewrite a vague defect report into a reproducible, actionable one
  • Explain why severity and priority are different judgments, not synonyms

Prerequisites

Explanation

"Search is broken" is a sentence, not a defect report. A developer who receives it can't reproduce it, can't judge how bad it is, and can't confirm when it's fixed — so it sits, unactioned, until someone eventually asks the reporter for the details that should have been there from the start. A defect report is a piece of technical communication with a specific job: let someone who wasn't there reproduce the problem, understand its impact, and verify the fix, without needing to ask the reporter anything else.

A trustworthy defect report has, at minimum: steps to reproduce (numbered, specific, in order — not "click around the search page"), expected result (what should have happened), actual result (what happened instead — with the exact error message or screenshot, not a paraphrase), and environment (browser, OS, account type, or whatever context could plausibly matter). Steps that are vague ("go to the site, search for something") are functionally useless — "go to /search, type 'wireless mouse' with a trailing space, press Enter" is reproducible by a stranger.

Two more fields are commonly confused with each other and shouldn't be: severity is a technical judgment about how bad the defect is on its own terms — does it crash the app, corrupt data, or just misalign a button by two pixels? Priority is a business judgment about how soon it needs fixing relative to everything else in the queue — a low-severity typo on the homepage might get high priority right before a major launch, while a high-severity crash in a rarely-used admin tool might get lower priority than a release-blocking issue. A report that conflates the two ("this is critical!" for a cosmetic issue) trains reviewers to stop trusting the reporter's judgment, which makes the next genuinely critical report harder to get taken seriously.

Example

A structured defect report as an object, checked against the fields it needs to actually be useful.

const report = {
  title: "Search returns no results for a query with a trailing space",
  stepsToReproduce: [
    "Go to /search",
    "Type 'wireless mouse ' (note the trailing space)",
    "Press Enter",
  ],
  expectedResult: "Results for 'wireless mouse' appear, ignoring the trailing space",
  actualResult: "\"No results found\" is shown, even though the product exists",
  environment: "Chrome 128, macOS, guest account",
  severity: "medium",
  priority: "medium",
};

function hasRequiredFields(r) {
  return Boolean(
    r.stepsToReproduce?.length && r.expectedResult && r.actualResult && r.environment,
  );
}
console.log(hasRequiredFields(report)); // true

Try it yourself

Remove the stepsToReproduce array (set it to []) and re-run — see how the check reacts to a report missing its most important field.

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Guided exercise

Guided exercise

Given vagueReport below, decide whether it's actionable by setting isActionable, and explain why in oneReasonMissing (a short string naming one missing element).

Checks: correctly identifies the report as not actionable · names a real missing element

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Independent exercise

Independent exercise

Write a function classifySeverityPriority(crashesApp, isHomepageRightBeforeLaunch) that returns an object { severity, priority } using strings 'high' or 'low'. A crash is always high severity. A cosmetic issue on the homepage right before launch is low severity but high priority (business urgency despite low technical severity).

Checks: a crash is high severity and high priority · a low-severity issue can still be high priority · an ordinary low-severity issue is low priority too

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Common mistakes

  • Writing steps to reproduce vaguely enough that a stranger following them exactly would not land on the same bug.
  • Pasting a paraphrase of an error instead of the exact error message or a screenshot, losing details that matter for diagnosis.
  • Using severity and priority interchangeably, which erodes trust in future reports once someone notices the mismatch.

Knowledge check

Knowledge check

1. What is the single most important test of whether a defect report's steps to reproduce are good enough?
2. How do severity and priority differ?
3. A cosmetic typo appears on the homepage the day before a major public launch. What is the most accurate classification?

Takeaway

A defect report's job is to let someone else reproduce, understand, and verify the fix for a problem without asking the reporter anything else — and severity and priority answer two genuinely different questions.

Summary

This lesson covered the essential elements of an actionable defect report and the distinction between severity (technical impact) and priority (business urgency).

References

Your notes

Notes save automatically.

Finished this lesson?

Mark it complete to track your progress and schedule a future review.

Next: Traceability and Regression Strategy →