01 Overview
Most bug reports are read once, in a hurry, by someone who is already behind on something else. They scan the title, maybe the first line, and decide whether to keep reading. That decision determines whether your carefully gathered evidence ever reaches a human being. The title is not a label you attach after the real work is done; it is the real work, compressed into the one sentence that will survive the scan.
A weak title forces the reader to open the report, reconstruct the problem, and guess what you meant. A strong title lets the reader decide in two seconds whether this is their problem, whether it is urgent, and whether they need the details. Everything else in the report exists to support that decision, not to replace it.
This article treats the bug title as a craft problem. It covers what a title is actually claiming, how severity and priority differ, how to write steps that survive handoff, how triage queues work in practice, and what to do when a defect comes back. The goal is not a template you fill in mechanically. The goal is a report that a stranger can act on without asking you a single question.
02 What the report is actually claiming
Every bug report makes a claim, whether or not the author intended one. The claim is usually some version of: under these conditions, the system does this wrong thing, and that matters. If the title does not carry that claim, the reader has to infer it, and inference is where reports go to die. A title like "Login broken" claims almost nothing. A title like "Login fails with a 500 error when the email field contains a plus sign" claims a specific condition, a specific failure, and a specific surface.
The claim has parts. There is a trigger, which is the condition or input that sets the defect in motion. There is an observed behavior, which is what the system does instead of what it should. There is an affected area, which is the component or surface where the user sees the problem. A good title usually names at least two of these three, and often all three, without becoming a paragraph. The body of the report then supplies the evidence for each part.
When you write the title first, you are forced to decide what the defect actually is before you write a hundred words around it. That decision is the hard part. If you cannot state the claim in one sentence, you probably do not yet understand the defect well enough to file it. Writing the title first is not a formatting preference; it is a test of whether the report is ready to exist.
03 Severity versus priority
Severity describes how much damage the defect causes. It is a property of the defect itself, and it should not change based on who is asking or what release is coming. A crash that loses user data is severe. A cosmetic misalignment on a settings page is not. Severity is about impact: what breaks, how badly, and how many people or processes are affected. Two testers looking at the same defect should arrive at roughly the same severity, because they are describing the same damage.
Priority describes when the team intends to fix the defect. It is a scheduling decision, and it legitimately depends on context that severity does not capture. A severe defect in a feature that is not shipping this quarter may have lower priority than a moderate defect blocking a release. A low-severity typo on a pricing page may get high priority because it is customer-facing and cheap to fix. Priority is a judgment call made by people who own the schedule, not a property you can read off the defect alone.
The confusion between the two causes real friction. Testers sometimes inflate severity to force attention, which erodes trust in the severity field. Engineers sometimes treat priority as a measure of importance and argue about it, when it is really a measure of timing. Keep them separate in your report. State severity as an impact judgment, and let triage assign priority. If you have an opinion about priority, put it in a note, clearly labeled as a recommendation, not in the severity field.
04 Writing steps someone else can follow
Reproduction steps are not a narrative of what you did. They are the shortest ordered sequence that reliably triggers the defect, written for someone who has never seen your screen. The test is simple: hand the steps to a colleague who was not involved, and see whether they reach the same failure without asking you anything. If they have to guess a value, a setting, or an order, the steps are incomplete.
Start from a known state. Say what account, data, or configuration the steps assume, and how to get there. Then list the actions in order, one action per step, using the same words the interface uses. If a step depends on a previous step, say so. If a value matters, give the exact value. If timing matters, say how long to wait. Avoid words like "sometimes" and "randomly" unless you have evidence; if the defect is intermittent, say so explicitly and describe what you tried to make it happen more often.
Include what you expected and what you observed, in that order, right after the steps. Expected behavior is not obvious to everyone, and stating it prevents arguments later about whether the behavior is a defect at all. If you can, note whether the defect reproduces every time or only under specific conditions. A report that says "reproduces three out of three attempts from a fresh session" is far more useful than one that says "happens sometimes." The steps are the part of the report that gets tested, so make them testable.
05 Running the triage queue
Triage is the routing decision made at review. A group of people look at incoming reports and decide, for each one, whether it is real, who owns it, how severe it is, and when it will be addressed. The queue is not a place where reports sit forever; it is a place where reports get sorted into next actions. A report that leaves triage without an owner and a priority has not really been triaged, even if someone read it.
The first job of triage is to confirm the claim. Someone reproduces the defect, or confirms that the steps are clear enough to attempt. If the report cannot be reproduced, it goes back for more information rather than being closed silently. The second job is to assign severity based on impact, not on the volume of the report or the seniority of the reporter. The third job is to assign priority based on the schedule, which is a conversation among people who own the release, not a unilateral decision by the reporter.
Good triage is fast and consistent. Fast means reports do not age in the queue while people debate; consistent means similar defects get similar treatment. The most common failure mode is not a wrong decision but a missing one: reports that are read, nodded at, and never routed. A simple discipline helps. Every report leaves triage with a status, an owner, and a priority, or it leaves with a specific question addressed to a specific person. Anything else is just a reading list.
06 When a defect comes back
A defect that comes back after being marked resolved is not a failure of the original report. It is new information, and it deserves a new entry in the ledger rather than a quiet reopening of an old one. The first question is whether it is the same defect or a different one that looks similar. If the original steps no longer reproduce but a new variation does, that is a new claim with new conditions, and it should be written up as such.
When you reopen or refile, say what changed. Note the build or version where it reappeared, the steps you used, and how they differ from the original. If the original fix addressed one path and the defect now appears on another, say so explicitly. This is where a good title earns its keep again: a clear original title makes it obvious whether the new report is a recurrence or a neighbor. A vague original title makes every recurrence feel like a mystery.
Recurrence is also a signal about the fix, not just the defect. A defect that returns after being closed may indicate that the original fix was too narrow, that a related path was missed, or that the reproduction steps did not capture the full condition. Treat the recurrence as evidence to be examined, not as blame to be assigned. The goal is to close the loop with a report that is at least as clear as the first one, so the next person has a fair chance of fixing it for good.
07 Frequently asked questions
How long should a bug title be? Long enough to carry the claim, short enough to scan. If you can name the trigger and the observed behavior in one sentence, do that. If the title runs past roughly fifteen words, you are probably putting evidence in the title that belongs in the body. The title is a headline, not a summary of the whole report.
Should I include severity in the title? No. Severity is a judgment that triage may revise, and putting it in the title invites arguments about the label instead of the defect. State the impact in the body and let the severity field carry the rating. The same goes for priority; if you have a recommendation, put it in a note, not in the title.
What if I cannot reproduce the defect reliably? Say so, and describe what you tried. An intermittent defect with honest notes is more useful than a confident report that turns out to be wrong. Include the conditions you observed, how many attempts you made, and whether anything seemed to increase the frequency. The reader can decide whether to investigate further.
What if the report is closed as not a bug? Ask for the reasoning in writing, and check whether the expected behavior was stated clearly in your report. If it was, and the team still disagrees, that is a product decision, not a reporting failure. Update the report with the outcome so the next person who sees the same behavior finds the answer instead of filing it again.