What Is Bug Tracking? The Difference Between a Record and a Message

Bug tracking is keeping every known defect in one place, in a form that survives the person who found it going on holiday. That is the whole idea. The software people mean when they say “bug tracker” is just the filing cabinet that makes it possible.

The distinction that matters is between a record and a message. A message is what you send when you notice something: a chat line, an email, a verbal mention on the way past somebody’s desk. It is addressed to a person, it is read once, and it is gone. A record is addressed to nobody in particular and read whenever somebody asks the right question. Bug tracking is the practice of turning the first into the second.

What a tracker has to do

Four things. Anything else is convenience.

• Hold one entry per problem, so two people finding the same thing find each other rather than filing twice.
• Say where each one stands - open, being worked on, fixed, verified, closed - in a way that is true rather than aspirational.
• Name an owner, because a defect that belongs to the team belongs to nobody.
• Be searchable later, which is the one people skip when choosing and regret in month four.

A spreadsheet does the first three badly and the fourth not at all. A chat channel does none of them, which is not a criticism of chat: it is a message medium doing exactly what it is for.

What goes in an entry

Less than most templates ask for and more than most reports carry.

The parts that earn their place are the ones somebody else needs to act: what happened, what was expected instead, how to get back to it, and where it happened - browser, build, account, URL. Our guide to writing a bug report is the long version of that list, and it carries a template you can paste into a form.

Everything else in a typical form is metadata for the process rather than the problem: severity, priority, component, milestone, the person who owns it. Useful, but it belongs to whoever runs defect management, not to the person who noticed the button was broken. Asking a reporter for it at filing time is the most common way to make reporting expensive enough that people stop.

Three failure modes

Nearly every tracker that stops being trusted got there one of three ways.

The graveyard. Nothing is ever closed, so the count grows monotonically, so nobody reads the list, so real defects arrive and are never seen. A backlog of eight hundred issues nobody has opened this year is not a record of anything; it is a place things go.

Statuses that lie. Every entry says “open” because moving one is somebody’s job and nobody has it. At that point the status field is decoration and the only way to know where anything stands is to ask a person, which is what the tracker was supposed to replace.

The duplicate pile. The same defect filed six times because searching is harder than typing. This is usually blamed on reporters and is usually a search problem: if a search for the words a normal person would use does not find the existing entry, the tracker taught them to file again.

Where the entries come from matters more than which tool holds them

Teams spend a long time choosing between trackers and almost no time on the step before it, which is how a defect gets from the person who saw it into the tracker at all.

That path is where reports die. Somebody notices a problem, and between noticing it and having written a useful entry there is a gap: which browser was that, what did the console say, what URL was it, what did I click first. Most people, most of the time, will write two sentences and move on, because the alternative is fifteen minutes of forensics for a bug that is not theirs.

Anything that shortens that gap raises the quality of everything downstream. A form on the page where the bug happened beats a link to the tracker. A capture that collects the technical half automatically beats asking a support agent to open developer tools. Capturing the report where the bug is is the same problem seen from the other end.

Choosing one

The honest advice is that the choice matters less than the habit. Jira, Linear, GitHub Issues, Bugzilla, Trello with a column called Bugs: all four things above are achievable in any of them, and none of them will do those things for you.

Two questions are worth asking of a candidate, and they are not the ones on the comparison pages:

Weak question

Which one has the most integrations and the best reporting dashboards?

Better question

Can somebody who is not on the engineering team file into it without help, and can somebody find a two-year-old entry from the words they remember?

If filing needs an account, a project, a component and an issue type, the people closest to your customers - support, sales, QA, the customer themselves - will not file. Their bugs will arrive as messages instead, and the difference between a record and a message is the thing you were trying to buy.

Tracking, testing and the rest of it

Bug tracking sits downstream of everything that finds bugs, which is why it collects the vocabulary of all of them. A test plan names how defects get reported and who decides whether one stops a release. Regression testing exists because a tracker full of closed entries is a list of things that used to work. Flaky tests are what happens when the thing being tracked cannot decide whether it is a defect.

A tracker does not improve software. It stops the same afternoon being spent twice.