Myth-Busting Bug Tracking: Why 'Priority' Isn't What You Think

Here's a myth we hear constantly: “Priority and severity are basically the same thing, right?” Wrong. In fact, conflating the two is one of the fastest ways to sink a bug-tracking process. We've all sat in a triage meeting where someone shouts “This is a blocker!” and we dutifully mark it P0 — but is it really urgent, or just really broken? We're going to bust this myth and a few others, because getting bug tracking right isn't about fancy tools; it's about the thinking behind them.

Is “priority” the same as “severity”?

No, and the difference matters. Priority measures how urgent a bug is to fix, while severity measures how much it affects system functionality or user experience (Atlassian, issue priority vs severity). A typo in a marketing landing page might be low severity — it doesn't break anything — but if it's on the homepage and the CEO noticed it, it might get high priority. Conversely, a crash in an obscure feature that no one uses could be high severity but low priority. We've seen teams burn days on a “severe” bug that nobody actually cared about, while a “trivial” bug that blocked a big customer sat ignored. Stop treating them as synonyms. Your workflow should let you set them independently, and your triage should ask two separate questions: How bad is it? And how urgent is it for us right now?

Should every bug go through the same lifecycle?

Not exactly. A typical defect moves through New/Open, Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, and Closed (Atlassian, bug life cycle). But real life throws in exceptions — Rejected, Duplicate, Deferred, Reopened, Not a Bug, and Non-Reproducible (Atlassian, bug life cycle). The myth here is that a bug should follow the happy path and never skip steps. We've seen teams get so rigid that a duplicate bug gets “Fixed” just to close it out. That's a disaster. Duplicates are not fixed; they're closed as duplicates. Non-reproducible bugs aren't verified; they're marked and revisited later. Build those states into your tracker, and teach your team that the workflow is a guide, not a straitjacket. The goal is to get accurate information, not to force every bug through a gauntlet that doesn't fit.

What's the point of a triage step?

If you don't have a triage step, you're probably wasting time. A simple, effective workflow is Open to In Progress to In Review to Done to Closed, optionally adding a Triage step (Atlassian, issue priority vs severity). That optional step is where you sort the wheat from the chaff. We've seen teams that skip triage and let developers pick whatever bug they feel like, which means the urgent stuff gets buried and the trivial stuff gets fixed first. Triage is where you assign priority, severity, and the right developer — but it's also where you reject duplicates, mark “not a bug,” and defer nice-to-haves. We recommend you make triage mandatory, not optional. It doesn't need to be a big ceremony; even a daily 15-minute scrub of new issues can save hours of misdirected work later.

Should I track accessibility bugs like any other bug?

Yes, but with a twist. Accessibility defects in web content are validated against the W3C's Web Content Accessibility Guidelines (WCAG), whose success criteria are defined at three conformance levels: A, AA, and AAA (W3C WAI, WCAG 2 Overview). The myth is that accessibility is a “nice-to-have” — it's not; it's a legal and ethical requirement. But the twist is that you need to track against a specific version. WCAG 2.2 is the latest, published on October 5, 2023, and it's backwards compatible — content conforming to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0 (W3C WAI, WCAG 2 Overview). If you're tracking an accessibility bug, you need to know which conformance level you're targeting and which version of WCAG you're using. Otherwise, you might “fix” an AA issue and still fail an audit because you were actually required to meet AAA. We've seen it happen. So when you file an a11y bug, include the specific guideline and success criterion — e.g., “WCAG 2.2, 1.4.3 Contrast (Minimum), AA.”

Does my bug tracker need to handle security vulnerabilities differently?

Absolutely, because security vulnerabilities have a different lifecycle and a different urgency. The NVD enriches every CVE published to the CVE List by aggregating data from the description, supplied references, and other public information (NVD, National Vulnerability Database). And CISA maintains the Known Exploited Vulnerabilities (KEV) catalog as the authoritative source of vulnerabilities that have been exploited in the wild, directing organizations to use it as an input to their vulnerability management prioritization framework (CISA, Known Exploited Vulnerabilities Catalog). The myth here is that a security bug is just another bug. It's not. A security bug might be exploited today, so it needs a different triage path. We recommend that your triage includes a quick check: “Is this CVE in the KEV catalog?” If it is, it's not just high priority — it's a directive to remediate by a certain date. CISA's KEV catalog even records a remediation due date and whether the vulnerability is known to be used in ransomware campaigns (CISA, Known Exploited Vulnerabilities Catalog). Your bug tracker should support these fields — due dates, CWE types, ransomware status — so your team can act fast.

Quick tip: When a bug is marked “Fixed,” reassign it to the original tester — don't let the developer close it themselves. That's the only way you'll get an honest retest.

Takeaway

Bug tracking is not about the tool; it's about the workflow and the thinking. Separate priority from severity, embrace a triage step, use the right lifecycle states, and treat security and accessibility bugs with the special handling they deserve. And whatever you do, don't let a “blocker” label override your common sense. Get the fundamentals right, and your bug tracker will actually help you ship better software.

Sources

• Atlassian (bug life cycle) - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• Atlassian (issue priority vs severity) - https://www.atlassian.com/software/jira/guides/issues/priorities
• W3C WAI (WCAG 2 Overview) - https://www.w3.org/WAI/standards-guidelines/wcag/
• CISA (Known Exploited Vulnerabilities Catalog) - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD (National Vulnerability Database) - https://nvd.nist.gov/general