Bug Title Crash Course Rikard Edgren
If you want to seriously improve your bug reporting skills, read up, or take, the BBST Bug Advocacy course.
If you want to start by improving bug report title/subject/summary; read Lessons Learned in Software Testing, no, 83, or this blog post.
Many people will only read the title, so it is important to make it possible to
* understand how the problem appears
* understand limitations and dependencies
* understand the consequences of the bug
Some people will make their first decision on fix/don’t fix, based solely on the title.
(And for those that look carefully at the report, the title will guide their thinking.)
The goal is to make it possible to understand the bug, and how important it is, just by reading the title.
A few tips
* As short as possible, but no shorter than that.
* Start the sentence with the most important, to capture the reader’s interest.
* Don’t overdo “externalization” to capture interest, rather describe the dry facts, and let the readers draw conclusions
* If it’s difficult, try many times, or write the title after everything else is done (you might find the right words on the way.)
* Include a brief description of what happens.
* Include where the problem happens.
* Describe observations rather than (presumed) facts.
* Use a fair description, don’t exaggerate or understate the consequence of the problem
I also have a tiny, controversial one; start the title with lower case for the first word.
Most testers think they are writing a sentence in a story, and start with upper case (and end with a redundant full stop.) The problem I see with this is that you lose the ability to use upper case for names and terminology. “Exit” refers to an element in the software, “exit” refers to the action, which can be done in several ways. This is nitpicking, yeah, but it’s what I think.
You can’t include everything in the title, so use what’s most important.
The best way to learn this comes as no surprise: practice a lot.
It is a really important thing that you are discussing here, and I like how you compressed it here. It is so important that I usually get into a discussion on bug report titles after I have been in the project for a short time. Long enough for people to experience my bug reports but short enough for them not to get used to them.
In a discussion like that I try to figure out their views and terminology to emphasize for example which consequences are important.
Usually we also end up with some kind of protocol for titles. I like being able to just add one or two words in the beginning of a title which means the same thing for the whole team, ie. “Server: Data validation not working properly”, which would mean that the people more involved in server parts will more easily spot those issues.
What do you think about protocols of keywords like that in the title?
I like using same terminology within a project.
It makes understanding, but also searching, both faster and easier.
The only thing I would be cautious with is if the terminology is acronyms or similar that not every reader of the bugs will understand.
Some bug titles might be read by managers who have to decide to fix or not.
Rikard:
“I also have a tiny, controversial one; start the title with lower case for the first word.”
For some reason just seeing the title of this post made me look for this comment… 😉
Sigge:
I recently came into an envorinment where keywords like “Server: …” are heavily used and I have yet to make up my mind if I like it or not.
At first sight my feeling was that those belong in a field or other paramater of the bug report, but I do also see the pros with it (I’m sometimes using them myself now). I’m still considering pros and cons with those titles vs just using bug report fields for it, and would love to hear other peoples ideas & thoughts.
[…] Bug Title Crash Course Written by: Rikard Edgren […]
Rikard – This is very useful. I have more than once had bugs get lost because the title didn’t describe the importance of the description, severity, or priority. One thing you didn’t address is the need to avoid “defect creep”. If retesting a fixed bug results in other problems showing up, it is usually better to open a new bug ticket rather than reopening the same one. That is especially true if reopening would require changing the original title of the bug to make it match the new scope.
Good point, Jeff.
I agree new reports should be opened when it’s no longer the same issue (unless speed or other circumstances override this.)
I actually said nothing about changing bug titles.
I guess it depends on the situation, but I’m all for correcting typos (proof-read was missing as well…), and I think the title content can be changed, but I want the reporter to be involved in those decisions.