The question that’s asked by many of my new team members when I emphasize the importance of a bug’s title is, “Just how important is a bug title?” The answer is, very important! Of course a title isn’t everything so don’t discount this as craziness. I feel the title is a common area that’s neglected in training and advancement. Inevitably this lesson can garner some confusion from the curious new comers and seasoned testers alike. Generally the follow-up question always being, why?
So let’s dive into that very question, why? To start off let’s evaluate what makes a good bug title. We’ll gloss over the obvious ones like spelling and grammar and dive into the core piece, what the title conveys. You may be asking, “Well obviously it conveys the bug I wrote up!”, but does it? Unfortunately there are times a bug title can say one thing to a tester but an entirely different thing to a producer or developer. Ultimately this can lead to possible pitfalls like incorrect prioritization or assignment. Right off the bat I like to call out a simple one; adding all pertinent information. All too often I find bugs that are as simple as “Item X has wrong text”. I use this example in the context that “Item X” has multiple ‘areas’ of text or ‘types’ of text. So without jumping into the depths of the bug, possibly more reading or evaluating screenshots, etc, it clearly becomes difficult to deduce exactly what this bug is about. This is a simple straight forward example that shows how changing the title to “Item X has missing word of second sentence in the hover text” would allow for a skeletal bug on the inside (saving tester time) and allowing a dev or producer to quickly fix or prioritize the bug at a quick glance.
Another front runner to help make a good bug title is knowing your project. The code execution path, how systems work together, the proper naming and identification of items, and even in some cases the upcoming schedule. These are all areas that help create a great bug title, but obviously as I stress all the time not an exhaustive list. This area also includes your company, team, or projects nomenclature. Simple glossary’s shared between QA as well as development teams can save a generous amount of time otherwise spent volleying a bug back and forth only to find it was a simple misunderstanding. General terminology has its place in not only a bug title but the description, repro, etc, a very important piece to call out!
Rounding out the higher priority items would be tagging or labeling. Most of the time this can be handled by various bug fields or bug DB settings. Unfortunately these tools aren’t always available, don’t contain all needed information, etc. In these cases a simple tagging system (ie “SOMETAG: “) can go a long way! Not only does this allow for quick searching (under >95% of bug database engines) but it also lends itself to allowing developers to perform quick ‘visual filtering’ and sorting. Of course this sounds like a simple process that could be considered ‘common sense’ but I point it out to show that a simple yet powerful process can still have many pitfalls if taken to laxly. At a quick glance things like failure to solidify common tag names, failure to properly tag bugs in general, or spelling/structure mistakes can render this entire process useless.
Let’s finally circle back around to the simpler common items mentioned earlier such as spelling or grammar. While these items are considered common practice I feel its all too often left out when training new testers. As simple as it sounds its extremely helpful to convey to new comers just how important these simple everyday writing basics are. As QA we’re expected to have an exceptional eye for detail, outstanding communication, and excellent organization. So what does it convey when your bug titles and descriptions are riddled with multiple spelling, grammatical, and punctuation errors? Having put that point into some context we’ll stick right with it and mention title length and structure. Two things that go hand in hand with your communication and organization skills. While it sounds simple enough, cramming all the detail I’ve covered above into a short, concise, and descriptive bug title is quite a challenge — but its better than the flip side of a staggering paragraph title!
All in all those are some of the more simple pointers that in my experience help generate better bugs and hopefully tighter QA/Developer relationships!