The title of a bug report is the first thing a developer, project manager, and future tester will see. It is also the primary field used in search, in sprint board views, and in release notes. A weak title makes a good bug report invisible. A strong title makes it actionable.
Learning Objectives
By the end of this lesson you will be able to:
- Apply the What-Where-When formula to write precise, unambiguous bug titles
- Identify the most common title antipatterns and explain why they fail
- Write a title that is searchable, assignable, and self-contained
The Formula: What? Where? When?
A good bug title answers three implicit questions at a glance:
| Question | What It Captures |
|---|---|
| What? | The incorrect behavior — what went wrong |
| Where? | The component, page, or feature where it happened |
| When? | The condition or action that triggers it |
The Template
[Component] + [wrong behavior] + when/after [condition]
This keeps titles concise, specific, and scannable.
Examples: Bad vs Good
Example 1
Bad: Form broken
Good: Registration form submits successfully with an empty required email field
What went wrong: accepts invalid input. Where: registration form. When: email field is empty.
Example 2
Bad: Button doesn't work
Good: "Add to Cart" button does not respond to click on mobile Safari 17
What went wrong: button unresponsive. Where: Add to Cart button. When: on mobile Safari 17.
Example 3
Bad: Something weird happens after login
Good: Dashboard shows incorrect username after login with Google OAuth on first visit
What went wrong: wrong username displayed. Where: dashboard. When: first login via Google OAuth.
The Antipatterns to Avoid
Too Vague
"Login issue", "Payment not working", "Profile bug"
These tell you nothing about the specific behavior. When there are 40 tickets in the sprint, you cannot distinguish between different issues. Three months later, you cannot search for this ticket at all.
Too Long
"When I am on the login page and I try to log in using my email and password and then click the button it sometimes doesn't work properly"
This is a paragraph, not a title. Extract the key information and compress it.
Cause, Not Behavior
"Missing validation in the email field"
This describes a root cause (missing validation) rather than the observable behavior (what the user sees). Bug reports describe behavior; root causes go in the description. The title should say: "Registration form accepts invalid email format without showing an error".
Emotional or Evaluative
"Terrible bug on the checkout page", "Critical issue!!!"
Severity belongs in the Severity field — not the title. Emotional language reduces credibility.
Searchability Matters
Imagine you need to find a specific bug from three months ago. You remember it was about the payment flow. You search for "payment." If the title was "Bug in payments", you'll find twenty tickets. If it was "Checkout throws 500 error when payment card has expired", you'll find exactly the right one.
Good titles include:
- The feature area (checkout, registration, dashboard)
- The action or condition (click, submit, after login, with empty field)
- The wrong behavior (shows error, does not redirect, displays incorrect data)
Pro Tips
Read your title out loud. If it takes you more than two seconds to understand what the bug is about, rewrite it.
Use consistent terminology. If your team calls it "checkout" not "payment flow," use "checkout" in your titles. Consistent naming makes the whole issue tracker more searchable.
Summary
- The bug title formula:
[Component] + [wrong behavior] + when/after [condition]. - Good titles answer: What went wrong? Where? When?
- Antipatterns: too vague, too long, describing causes instead of behavior, emotional language.
- Searchability is a long-term investment — a well-titled report from six months ago is still valuable.