Bug report titles need to talk about the environments, the digital products, websites or apps we are testing; otherwise, they cannot help customers identify issues that need fixing.

Thus, titles unrelated to the environment under the scope of a test cycle or that can be applied to any environment setting with similar features and functionalities on the internet cannot be accepted because they need to provide helpful information.

For instance, what is wrong with titles like this one?

With this title, we cannot respond to ❝where❞, ❝what❞, and ❝when❞ is happening with this bug, so let’s break them down.

First, ❝Can not❞ is not describing precisely what the issue is. This is why this and similar expressions like ❝doesn't work❞ or ❝cannot click❞ are not allowed to describe behaviours that are seen as problems.

Second, the title has a contradiction that is not resolved within the title, and the ambiguity also doesn't help to understand the issue generating more questions than answers. 1) Is it the button not shown, or 2) Is it clicked but doesn't generate any output?; 3) The button worked once and then didn't work a second time? In what sense is it not working now? 4) Was it the same form the user entered the login credentials? 5) Why can it not be done the second time? Is it the page not rendering? 6) Which page, exactly? 7) Is the form, the button, or anything relevant to the login flow loading? See, there are too many questions that this title is generating instead of responding to the three primary questions a title must have (❝where❞, ❝what❞, and ❝when❞).

A title that successfully responds to the three elements would be:

Click or tap to navigate to the Academy article.

Notice that the title starts telling where the issue was found (login page), what is happening (the system triggers a specific error), and when it is happening (when the user tries to sign in back with the same email account).

By the way, the error was mentioned in the actual result of this report, which is also needed; however, since the system is triggering such specific information, it must be part of the bug report title.

As a rule of thumb, add it to the title whenever a system triggers an error because it is direct and sometimes enough information to identify bugs since they usually tell customers the root cause of the problem.

Here is another functional bug on IMDb.com. What would be the correct severity of this bug?

Click or tap to navigate to the Academy article.

The user is watching a trailer and finds another trailer option under the ❝Watching options❞ that brings up a similar element; however, when the user clicks on the ❝X Close❞ button, the video replays instead of closing.

Initially, this bug was submitted with a high severity level. You may agree with this assessment. However, the final and correct severity of this bug is low.

Why? Let's break it down! To do so, we're using the method of 3 questions at different levels (functionality, customers and user experience) explained in the article: ❝How to select the correct severity of a functional bug❞.

But first things first. What does the Academy say about these two severities?

In our Academy article, ❝Functional Bugs❞, there is a section dedicated to severity assessment where for these two levels, there are four scenarios in which we can apply them:

LOW:

HIGH:

Let's begin!

What is the impact of the bug on the usage of the product? Since the users can play and watch trailers, the functionality is working, users are getting the information they are looking for, and customers are delivering the product they want, so the impact is minimal.

Is this issue preventing users from watching the trailer (one core functionality since the website is a dedicated space for movies)? Since users can watch trailers, the general usage of the functionality is not affected. Also, the ❝X Close❞ button is not as relevant as, in this case, the Play button.

How many users are affected by this bug? Well, we cannot tell precisely how many. Still, we can tell there are not too many since the way this trailer is found demands more effort from users (identifying and opening the ❝Watching options❞ button). Plus, this option is not presented on every trailer, so only the users who go far in their watching trailer journey and who play the videos with this button will be affected.

Is there any workaround to bypass the issue? If the workaround is intuitive and easy, then this set it already! In this case, what would you do if you faced this issue? I bet you'll refresh the page, too! Many users would do this, and when this is done, the browser renders the initial page allowing users to continue watching other trailers.

Therefore, in any way we analyse this bug, its correct severity level is low.

Do I have to do this every time I report a functional bug? Yes, you have to... no worries, with experience, you'll do this in a flash, and if you start with identifying the workaround, then the assessment will be straightforward.

When determining the severity of a bug report, always explore its workaround to assess the level quickly; if this workaround is easy and intuitive, then you know the bug has most likely a low severity.