For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/quality/defects.md.
Defects
Raise, triage and close bugs — and link them to the tests and tasks they relate to.
Pro and Premium
Bug and defect management comes with Pro Unlimited. Linking defects to test cases requires the Premium Test Case Manager.
#Raising a defect
A defect report is only useful if someone else can reproduce it. Four things are non-negotiable:
Steps to reproduce
Numbered, from a known starting state. "It breaks sometimes" is not a report.
Expected versus actual
Both. "It's broken" leaves the reader guessing what correct looks like.
Environment
Browser, OS, device, version, which environment. Half of all "cannot reproduce" outcomes are environment mismatches.
Evidence
Screenshot, recording, console output, request id.
A defect nobody can reproduce gets closed
Not because it is not real, but because there is nothing to act on. The ten minutes spent writing a proper report saves hours of back-and-forth.
#Severity and priority
Two different things, and conflating them is why triage meetings drag.
| Asks | |
|---|---|
| Severity | How bad is the impact when it happens? |
| Priority | When are we going to fix it? |
A crash affecting one user on an obsolete browser is high severity, low priority. Cosmetic misalignment on the signup page is low severity, high priority — because it is the first thing every prospect sees.
#Triage
Regular, short, and decisive. The output of triage is a decision per defect, not a discussion.
Goes into the current sprint. Something else comes out.
Say so, with a reason. An honest "won't fix" beats a defect that sits open for two years.
Back to the reporter with a specific question — and a deadline, or it stalls forever.
A defect list nobody triages is a graveyard
Once it passes a few hundred untriaged items, people stop reading it and start reporting bugs in chat instead. Triage weekly and close aggressively.
#Linking
A defect can be linked to the test case that found it, the task that fixes it, and the release it affects.
That chain is what makes the data worth keeping: months later you can see what was being tested, what broke, and what was changed to fix it.
#Status flow
A workable default:
| Status | Means |
|---|---|
| New | Raised, not triaged |
| Confirmed | Reproduced, accepted |
| In progress | Being fixed |
| Ready to verify | Fixed, awaiting retest |
| Closed | Verified fixed |
| Won't fix | Accepted and declined, with a reason |
Tip
Ready to verify is the status teams most often omit, and the one that prevents defects being closed by the developer who fixed them without anyone else checking.
#Patterns worth noticing
Individual defects are noise; the pattern is the signal.
The same area keeps breaking
That is a design or test-coverage problem, not a run of bad luck. Fix the cause, not the tenth symptom.
Defects spike after every release
Insufficient pre-release testing, or releases too large to verify.
Most defects come from one source
If a single customer or tester finds most bugs, everyone else has stopped reporting — usually because reports went nowhere.
Reopened defects
Fixes that do not hold mean the root cause was not found. Track reopen rate.
#API access
Defects are available through the Developer API — list, create, update, link and change status — so you can sync with an external support desk or monitoring tool.