8 questions to ask when a bug report is created

8 questions to ask when a bug report is created

A bug report outlines all the details pertaining to a bug, providing developers with helpful insights to resolve the issue.

In other words, a bug report is invaluable because it guides the developer through the debugging process.

However, to be truly effective, the document needs to be well-written. If there’s missing data or incorrect information, then it’s not of much use to anyone.

As such, it’s a good idea to carefully review your bug report before submitting it.

That’s what this article is all about—we’ve prepared eight questions to ask yourself to ensure your bug report is high-quality.

Is the bug really a bug?

This question might seem silly, but it’s worth asking. After all, a bug report is redundant unless what it’s describing is really a bug.

Software bugs are frequently utilized as a blanket term for any unexpected behavior in a software product.

For example, if a photo app doesn’t automatically save photos taken by the user, but requires the user to save them manually.

However, not all such instances necessarily constitute a bug.

Consider the following definition:

A bug is only a bug if it deviates from the software requirements or end-user expectations.

Consider our example of unsaved photos in a photo app. This seems like an obvious defect, but testers can’t be certain before consulting the requirements.

If that document doesn’t state that the app should automatically save photos after a user takes them, then this issue is not actually a bug.

It’s the requirements that define incorrect behavior and are the criteria for identifying bugs, not the tester’s own judgment.

Furthermore, testers should be exceedingly careful when performing software testing. This Quora user explains why:

For a test to uncover bugs, it must be executed correctly. Otherwise, you will incorrectly assume something is a software bug if you don’t see the expected results.

However, if the test was imprecise, then there’s no bug—just the correct result for the wrong test.

For example, imagine adding five items to your cart and not receiving the promised discount code. This is because the test case specifies over five items should be added.

Unfortunately, you missed this detail. Consequently, you’ll probably report a ‘missing discount code’ bug report, despite there being no such bug.

Can the bug be reproduced?

After establishing you’ve found a bug, the next step is to reproduce it. This is essential to fixing the issue, as it allows developers to see the bug for themselves.

Debugging is most easily done when the error is re-creatable and interactable. After all, no description can replace a real-life visual.

In fact, if the bug isn’t reproducible, there are slim chances the developers will solve it—the lack of visuals and interaction will be too much of a roadblock.

As such, reproducibility is often the key to solving the bug, so much as to warrant the following advice:

If there’s a defect developers can’t seem to fix, it’s likely that they can’t reproduce it.

Furthermore, reproducibility ensures that bugs are genuine defects that must be solved. If an error is easily reproduced, end-users will probably also encounter it.

However, if your testers can’t recreate the error, the bug probably requires very particular preconditions and is unlikely to occur during regular software use.

Bryan Kiptoo of Testlio also commented on this:

By establishing a bug’s reproducibility, you’re verifying that the issue is a genuine problem that can easily occur and needs to be taken care of.

Has the bug already been reported?

Before submitting a bug report, it’s always worth double-checking if the bug has already been reported. You want to avoid multiple reports of the same error, as this can cause confusion.

A bug might be resolved, but a developer will assume that the bug is active because a duplicate bug report is still open.

They’ll start fixing it but won’t achieve any results—because the bug has already been resolved. Ultimately, they’ll just waste time.

Consequently, it’s always a good idea to check for duplicates, especially considering how common they are.

A recent study revealed that out of 94 questions related to bug reports, 35 of them were a variant of the following:

In other words, over a third of all bug-report-related questions concerned duplicate bug reports.

One easy way to avoid such situations is to search the bug report repository before logging a report.

Most platforms will offer some search platform you can use to check if your bug has already been reported.

For example, here’s Bugzilla’s search interface:

A simple search will reveal instantaneously if your bug has been reported or not, and you can easily verify that it’s not a duplicate.

Does the report have a descriptive title?

When a developer picks up a bug report, they’ll first notice its title.

Typically situated at the top of the page, a title should serve as a summary of the bug’s details or as an introduction to the report.

Given its prime position, the title must be descriptive yet concise—giving as much detail in as few words as possible.

As ReQtest stated:

Consequently, developers will use this title to identify the bug report and differentiate it from others.

Imagine titles such as Login not working or Can’t play video. Too many vague headings such as this, and all the bug reports will start to look the same.

Furthermore, it’s impossible to extrapolate what the bug report is really about.

To avoid these situations, it’s vital to write descriptive titles. An easy way to do so is to use the title to answer three questions—what, where, and when?

Here’s an example:

This sample title describes exactly what happens, where in the app it takes place and when, or under which circumstances.

Anyone reading the bug report will know precisely how the bug manifests itself, and will be able to easily differentiate this report from the others.

Was all the required information included?

The title is only the beginning of the bug report. Although a good title goes a long way, plenty of additional information should be included to guarantee the report serves its purpose.

Here’s everything a bug report should contain:

A title is best accompanied by a bug ID for additional identification purposes.

Following that is the bug’s environment—details such as the device, the operating system, the browser, the version of the app, etc., on which the bug appears.

Next comes the description, which is a longer, more detailed description of the bug than the title.

The steps to reproduce are also crucial, as they instruct the developer on how to recreate the error.

Then, the expected vs. actual result explains how the software behaves when impacted by the bug, compared to how it should.

Severity and priority should be included as well, since they describe how severely the software is affected.

Finally, screenshots or screen recordings are always helpful, as they literally show the developer the bug.

Writing out all this information can be quite the process and take up a lot of your testers’ time. However, the procedure should be much quicker with a bug-reporting tool such as Shake.

Simply shake your mobile device, and Shake will instantly deliver a detailed bug report to the developers. Here’s an example:

The report contains all the information required in a bug report: environment details, logs, screenshots and screen recordings, and more.

Were the bug severity and priority assigned?

Software will, unfortunately, always contain bugs, as completely bug-free software is almost impossible to achieve.

With so many errors, it’s vital to develop a debugging strategy. This is where bug severity and priority can help you out.

Without these assigned rankings, developers can’t prioritize bugs—you risk the typos being solved before the app crashes.

The severity level defines the bug’s impact level, and there are five severity grades:

A trivial bug doesn’t impact the app’s operation but is still unpleasant for the user (e.g., a typo).

The next level is a minor bug—a small issue with a workaround. For instance, there is a broken link, but an alternative path is available.

After that comes a major bug, which is an error with no workaround, such as an entire page being unavailable.

Even more damaging is a critical bug, as this causes a key functionality to fail, like a music app not playing audio.

However, the most dangerous is a blocker—a bug that causes the app to fail completely.

After defining a bug’s severity, you can determine priority, which refers to how urgently a bug should be solved.

There are three priority levels:

A high-priority bug is an emergency that must be addressed immediately, typically a blocker or critical bug that affects a large number of users.

Following this are medium-priority bugs—errors that can be corrected during regular development (e.g., a page not loading).

Finally, low-priority bugs have either minimal impact, like a text misalignment, or they affect a very small number of users, such as app crashes on very old devices.

Does the report focus on a single bug?

While writing a bug report, it’s always a good idea to ask yourself: how many bugs have I mentioned in this report?

Ideally, a bug report should detail only one defect. If the document describes several different errors, this creates clutter and makes it difficult for the developer to decide what to focus on.

This topic was also discussed in a Quora thread:

Multiple bugs in one report run the risk of the developer dealing with one bug but forgetting about the other before marking the bug report as closed.

Consequently, the overlooked bug will remain active, needlessly polluting the software.

As such, it’s best to stick to one bug per report, no matter what.

For example, you might find a bug and notice it’s already been reported. However, you’ve discovered additional information not listed in the existing document.

Even in these situations, submitting a new report is preferable. This Reddit user explains why:

You can’t be certain the two bugs are the same, as you’re not the person who made the original report.

Adding new information, believing it’s the same error, is unwise, as you’re merely operating under an assumption.

There’s always the risk that the two errors are simply similar (not identical), and the multiple bugs in the report could easily confuse the developers.

Are the facts being reported?

At the end of the day, a bug report has one ultimate goal: to report the facts regarding a defect in the software. The key word in this objective is facts.

Testers are tasked with observing and recounting all possible details regarding a software bug.

However, this information is only helpful if it’s 100% verifiable. As such, testers should omit anything they’re unsure about and stick to the evidence they can see.

In other words, a bug report is not the place to brainstorm possible causes or make suggestions.

That’s the developer’s job—the tester’s is to provide them with the facts that allow them to do so.

Simon Tatham has also articulated this difference, stating:

There’s a marked difference between the two, and the latter usually has no place in bug reports.

Instead, a bug report should follow this one simple formula:

Although Bugayenko might be a little brusque, the point still stands.

A bug report is a place to illustrate the current state of affairs and explain how the situation differs from the expected result.

It’s not a medium for giving feedback or expressing personal opinions. Instead, straightforward, clear professional facts should be present.

Conclusion

A bug report can be considered a developer’s guiding light while debugging.

The document provides all available details about the bug, giving the developer the clues they need to resolve the issue.

Given the document’s importance and impact on quality software, it’s well worth giving it a final once-over before submitting it.

At the end of the day, developers greatly appreciate a well-written bug report, as it helps them do their job more efficiently.

That’s why it’s worth asking yourself these eight questions—not only are you improving your software’s quality, but you’re also doing your colleagues a favor.