Bug Title (Subject Line) Standardization

Authors: Amit Kulkarni, Atul Angra, Glory Leung, uTest
Reviewer: uTest

Background: If you have used a bug-tracking system for logging and reporting purposes, you are likely familiar with a “bug dashboard” – a summarized list of bugs by identification number, bug title (also known as subject line), bug type, severity, priority, status, bug reporter, and assignee to list a few. Various problems arise when you are not the only one reporting bugs and/or reviewing them. For example, have you found yourself reviewing a list of bug titles written by other testers, only to find the bug title confusing or misleading? This brings us to the necessity of bug title standardization. However, there is not a “one size fits all” solution. Too much process (such as category dropdowns with mutually exclusive options) and the system breaks down due to lack of flexibility. Too little structure leads us back to root problem of “making sense of bugs at first glance.”

Because of this known frustration, some organizations have begun to standardize the way in which bug reports are titled. After all, we cannot expect all testers to instinctively write the summary or bug report subject in an identical fashion. And again, the primary driver behind this effort is to help various stakeholders better understand the bugs at first glance, which ultimately saves time.

Here are two suggestions: 1) be concise yet descriptive, and 2) follow some type of structure/approach to help bug reviewers quickly identify the area in the application where the bug occurs.

Using these suggestions, a simple approach is conveyed in the following example:

1. State the area [in the application] in which the defect occurs, followed by a hyphen ("-"), and
   • "Homepage - "
2. A brief description of the bug
   • Homepage - "the 'Contact Us' button is linking to the incorrect page"

This approach helps the bug reviewer quickly assess if a bug has already been reported. This is still not perfect, however, as choice of words varies across testers.

Here are some other examples and words of wisdom provided by members of the uTest community:

Glory, from Canada, writes: When people reports bugs, they must make their bug titles stand out. First of all, you have to assume that the person who reads your bug title does not know anything about what you are doing. Remember, anyone can read a bug title. Secondly, most of your bug titles must be short, concise and must have enough information so that the user who is reading it can understand what the bug is about. Don't write "It does not work!!!" on the bug title. It gives me no information as to what is wrong, or why it's wrong. Why do you think being in support is the worst job in the world? Exactly: bad bug reporting and titles. So now you ask: "So Mr. Smart guy, how do you write a bug title then?" Simple. You must be objective and clear. Don't use short form words or slang. Include keywords or numbers of any error messages you are getting. An example of an unclear bug title is "The webpage does not load". You can make this bug title better by using "HTTP 404 error when I access http://" I'll give you another example: "Unexpected Error!", you can write the bug title as "Unexpected Error: , when I hit Submit Bug" As you can see, writing clear bug titles that "get to the point" allow users (whomever they be) to understand the nature of the bug without even going into the bug details.

Atul, from India, writes: Bug Title should be short and simple. Here is an example using the standard Gmail application:

"Gmail => Compose Mail => Subject: Special Characters are not allowed"

General guidelines:

• Always start with the project name (Gmail)
• Then add hyphen or ‘=>' or '-> ‘ (=>)
• Then write the Module where it is happening (Compose Mail)
• Then add hyphen or ‘=>' or '-> ‘ (=>)
• Then write the Section where the problem lies ( Subject: )
• Then write the bug description, Bug Description should be simple and understandable

With this concise bug title a user or developer can easily understand that where that bug occurs and what is the exact bug.

Amit, from India, writes: “Testers are viewed as key players who make sure the application is working the way it should. There are so many different styles for each bug reports. It all depends on what organization you are working for, the bug tracking used by the organization and, most importantly, if there are any standards for reporting bugs. If there are no standards for reporting bugs, it is difficult to understand the exact problem upon first glance.

If you are working on or testing an application where there are many modules and the team size is not only large but geographically dispersed, it helps others if you take that extra step of having standardized subject line for your reports.

Standardized bug reports help all parties, including customers, management people, developers and your testing team members.

Here are two examples – it should be easy to spot the poorly written one:

1. Incorrect rounding for decimal values (not recommended)
2. My Account – Payment – Incorrect rounding for decimal values

The first example tells me about the problem, but I’m not sure where, or which screen. The second example uses the Parent/Child area names, followed by a concise description of the underlying issue.

Conclusion: These recommendations and examples should help raise the bug title writing to a level that benefits both bug reporters and reviewers. The ultimate goal is to help bug reporters provide their audiences with a decent understanding of the bug [at first glance]. If you have more examples or words of wisdom, please share them in the uTest forums.