Another thing to remember about the title is that you don’t need to overload it with information. Bug trackers normally store quite a lot of fields about the bug in other fields. Priority information and other classification information normally have separate fields available. They can all be displayed on a bug list so you don’t need to clutter the title up with them.
Exactly what you put in the title depends on how you are classifying your bug reports in your system. It’s worth discussing in your organisation so that you come up with a general set of guidelines. If you have a good product/component classification scheme in use on your bugs then you only need to provide minimal information in the title about which system is affected. For example a good bug report might go like this,
- Title: Crash when trying to add a 4th phone number to my contact list.
- Product: gmail
- Component: contacts list
- Reported version: beta
- Priority: High
- Severity: Trivial Bug
- Url: https://mail.google.com/contacts/
With that kind of information someone needing to manage the bugs can do so simply by looking at the title and whichever of the other fields are relevant. A title of ‘Important: crash in gmail’ on the other hand would be pretty useless.
If the problem is serious remember to make sure that’s obvious. I’m inclined to say if you have a crash make sure it’s mentioned in the title. Actually that’s a bit misleading. What I really see is that non-technical people don’t tend to distinguish between error screens and things not working as they expected. If you see an error screen that should be clearly stated, that’s commonly the sign of what geeks would call a crash. An error screen being something that gives a generic error message, or shows what appears to be lists of files and numbers and says an error occurred. That’s as opposed to a specific error message saying something like ‘you need to type a number in the amount field’. Error screens/crash reports are usually pretty easy to fix and an obvious error on the programmers part. Programmers want to know about those first because they are a no brainer thing they need to fix.
One other minor point to note is that if you have discovered a serious problem like a crash while testing another bug report don’t tack it on as a side note. Create a brand new case and clearly mark it as a crash.