Most defect tracking begins at test execution, which quietly encodes an assumption: that defects are things found in built software. They are not. A contradiction spotted while reviewing a requirement is a defect, and it is the cheapest one you will ever fix.
DefectSync tracks defects across the whole pipeline rather than only the testing end of it, and the source field is where that shows.
Where a defect came from
Every defect records its origin: requirement review, test design, test execution, exploratory, or production.
This is not filing metadata. It is the only way to answer a question most teams cannot: where are we catching things, and how much is that costing us?
- Requirement review. Found before anything was built. Cost is a conversation.
- Test design. Found while designing coverage, usually because the requirement could not produce a sensible test. Cost is a rewrite.
- Test execution. Found by running the software. Cost is a code fix plus a retest cycle.
- Exploratory. Found by someone poking at it deliberately, outside a scripted run.
- Production. Found by a user. Cost is the fix plus the incident plus the trust.
A team catching most of its defects at execution is functioning normally. A team catching a meaningful share at requirement review is functioning well, and the distribution tells you that without anyone having to run a maturity assessment.
Track the distribution over time, not the totals. Defects shifting earlier in the pipeline is one of the few unambiguous signals that requirement quality is improving.
Severity and priority are separate fields
Severity is Critical, High, Medium, or Low. Priority is P1, P2, or P3. They are recorded independently because they answer different questions and belong to different people.
Severity describes how badly the system misbehaves. That is a QA judgement based on observed behaviour. Priority describes how soon it must be fixed. That is a Product Owner decision based on commercial context.
A cosmetic error on the checkout button is Low severity and can legitimately be P1. A total failure in a rarely used admin export is Critical severity and can legitimately be P3. Collapsing the two into one field forces someone to average two incomparable judgements, and the resulting number carries neither.
Lifecycle, including the honest endings
The status vocabulary is: open, in progress, fixed, retest, closed, reopened, deferred, rejected.
Two of those deserve attention because they are the ones that get fudged.
Deferred is a decision to not fix this now. It is a legitimate outcome, and making it an explicit state rather than a ticket that goes quiet means somebody consciously accepted the risk. An undecided deferral is just a defect nobody looked at.
Rejected requires a category: working as designed, cannot reproduce, duplicate, configuration issue, test data issue, environment issue, or other. Requiring the reason turns rejection into information. A pattern of "cannot reproduce" points at reporting quality. A pattern of "working as designed" points at requirement ambiguity, which means those are not really defects at all, they are specification disputes surfacing late.
Root cause and resolution
Closed defects carry a root cause (validation missing, logic error, configuration issue, API failure, data issue, or other) and a resolution (fixed, rejected, duplicate, will not fix, or cannot reproduce).
The value of a constrained list rather than a free-text box is that it aggregates. Fifty defects with free-text causes are fifty stories. Fifty defects across six categories is a chart showing that a third of your production issues are missing validation, which is an actionable engineering conclusion rather than an anecdote.
Linking back to the work
A defect links to the execution result that found it and to the requirement it affects, through explicit link types that distinguish where a defect was found from where it was verified.
That distinction sounds fussy and is not. Found in and verified in are different builds, and conflating them makes it impossible to answer whether a fix was actually confirmed on the build you are shipping.
Key takeaways
- Defect source spans the whole pipeline, and the distribution over time is a real quality signal.
- Severity is a QA judgement, priority is a Product Owner decision, and they are separate fields for that reason.
- Deferred is an explicit accepted-risk state, not a ticket going quiet.
- Rejection categories turn rejections into information: repeated "working as designed" means the requirement was ambiguous.
What to review weekly
Not the total. The total is a function of how much testing happened.
Look at the source distribution, the rejection categories, and whether anything high severity sits on a path that carries money, identity, or data integrity. Those three tell you where quality is being decided. The count tells you how busy people were.