Most bug readers will agree, a simple “Expected Results” vs. “Actual Results” statement in the bug description will remove all ambiguity. But what about the bug title? Is a bug title supposed to include the expected results, actual results, or both? Every time I log a bug, I pause to consider the various title possibilities. I want a unique but concise title that will summarize the bug, making the description as unnecessary as possible. My head swims with choices…
- If user does X after midnight, user gets Y.
- If user does X after midnight, user should not get Y.
- If user does X after midnight, user should get Z.
- If user does X after midnight, user gets Y instead of ZUser should get Z when they do X after midnight.
- etc…
Here is what I think.
There is no “best” bug title. Any bug title is good enough as long as it:
- is unique within my bug tracking system
- describes the problem to some extent
- includes key words (these words will be used someday to find this bug; searching for bugs where title contains some text)
So unless someone convinces me otherwise, with a comment on this post, I have decided to just use the first distinct bug title popping into my mind and stop worrying about bug title perfection.
RSS
I'm currently reading the book _How We Test at Microsoft_...yes, go ahead and laugh. Anyway, Alan Page, the author says that the title of a bug, "is perhaps the most important (or most used) bit of information in the bug report," (page 192). This makes a lot of sense as it is what a developer looks at first. I'm convinced that, in the future, the title of a bug will be used as a set of tags that rolls up into further bug analysis. Just my $2.00.
Cool! Can you give us some of Alan Page's suggestions for crafting a good bug title? Or does he just say titles are important?
BTW - how is the rest of his book?
The title is the most important part. It's certainly viewed by the most people.
You probably consider a few posible titles for each Blog article, before you settle on your choice, right?
- Which words convey the meaning of my article well?
- How can I say this succinctly?
- Does this title distinguish this article from others?
Don't sweat it too much, but give similar thought to the title of your bug report.
As How We Test Software at Microsoft says "At Microsoft, many testers quickly fill out all the fields of the bug report but take extra time to carefully word a title for their bug".
And they give these examples:
- Program crash (too short)
- When running many instances of the program at the same time, a crash occurs in one of the dialogs (both wordy and vague)
- Program crash in Settings dialog box under low-memory conditions (specific, accurate, and tells enough of the story to understand the bug from the report)
(The rest of the book is excellent as well.)
I have always that a bug title is an essential part of a bug report. I usually spent the most time on the title, because I always had the goal that it would be possible to know exactly what the bug was based on the title, and as you put it, make my description completely unnecessary.
--Steve
No problem...I blogged it so just click on my name. This book was worth every penny. I'll post a review in a week or so.
In Testing Computer Software, Kaner, Falk, and Nguyen say, "Writing a one- or two-line summary is an art. You must master it. Summaries help everyone quickly review outstanding problems and find individual reports. Most report that circulate to management list only the report number, severity, some kind of categorization, and the problem summary. The summary line is the most carefully read part of the report." I agree with this. In various roles—as a tester, a test lead, a program manager, and a programmer—a thoughtful problem summary is gold. The keys, for me, are a) to describe the problem without describing the path to reproduce it; what's wrong? and b) to make the significance of the problem clear. "Problems with weak headlines might be dismissed during triage meetings." (That line is from Lessons Learned in Software Testing.)
Remember, too, that you'll write it once, but that people will refer to it more often than that. It's worth a moment to punch what's important and diminish the dross.
---Michael B.
As more frequently managing testing these days, I value the bug title as means of searching and grouping similar anomalies.
That said, I am also quite happy to refine the bug title during initial assessment or later.
Mark
Depending on tool in use, it is sometimes useful to flag functional area at start of title (assuming tool does not have dedicated filterable fields)