Bug tracking
Bug tracking is the practice of recording every defect a team knows about and keeping that record current as each one moves toward resolution, so that at any moment the team can say what is broken, how bad it is, who owns it and what state it is in. It is a record-keeping discipline rather than a meeting or a piece of software.
The longer version
A defect that exists only in a conversation is not tracked. Four things have to be true before a report counts: it is written down somewhere the whole team looks, it can be told apart from every other report, its current state is visible without anyone having to be asked, and the evidence behind it stays attached to it. Drop any one of them and the record becomes a list of titles nobody trusts.
The practice is regularly confused with the two things that happen inside it. The bug life cycle names the states a defect passes through, from reported to closed. Triage is the recurring decision that moves a report between some of those states. Tracking is neither: it is the work of keeping every defect's position in that sequence written down and current, over months, across releases, including for the reports nobody has looked at in a while.
Because the words are also the name of a product category, the practice gets mistaken for the software. A shared spreadsheet tracks bugs if those four properties hold, and an expensive issue tracker fails to if they do not. What actually ruins a record is drift between the record and the work: the same bug filed three times under three titles, a ticket sitting in progress a month after the fix shipped, a screenshot living in a chat thread instead of on the report. Each of those costs somebody a reconstruction later.
The payoff is that questions about the queue as a whole become answerable. How many defects are open, how long a report waits before anyone assesses it, which areas produce repeat regressions, whether the queue is growing faster than it drains: those are properties of the record rather than of any individual bug. A team whose record is current can answer them on the spot. A team whose record has drifted has to rebuild it from memory before it can start.
Common questions
Is bug tracking the same as the bug life cycle?
No. The life cycle names the states a defect passes through, from reported to triaged, fixed, verified and closed. Bug tracking is the practice of keeping each defect's position in that sequence written down and current, so the record still describes reality a month later. One is the map; the other is keeping everyone's position on it up to date.
What is the difference between bug tracking and bug triage?
Triage is a decision made repeatedly inside tracking: an untriaged report is assessed, ranked and assigned. Tracking is the record of that bug across its whole life, from the first report through closure and any reopening afterwards. Triage happens in sittings; tracking is continuous, and it holds the outcome of every triage pass.
Does a team need a dedicated tool to track bugs?
No. A shared spreadsheet tracks bugs as long as every report is uniquely identifiable, its state is current and its evidence stays with it. Tools earn their place at volume, where duplicates, stale states and reports scattered across chat threads are what break a manual record. The discipline is what makes a record trustworthy; the tool only makes it cheaper to maintain.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.