Bug reporting FAQ

Although it might initially seem straightforward, bug reporting is a complex process. You might be thinking: how hard can it be?

Someone reports a bug, and then someone solves it. It doesn’t sound too tricky.

However, the actual workflow is much more elaborate.

If you’re a newer team lead, it’s well worth learning as much as possible about bug reporting, as you’re sure to come across some new insights or ideas.

The goal of this article is to clear up the most common doubts and misconceptions and answer all the most frequently asked questions on bug reporting.

What is a bug report

As a general rule of thumb, the fewer the bugs, the better. Bugs are defects in your system, impediments to well-functioning software, and therefore never good news.

This is why it’s essential to write bug reports well.

A bug report is your best weapon for resolving software bugs. These documents are detailed, comprehensive logs that describe the software bug, providing all available information about it.

Yegor Bugayenko, Huawei’s Director of System Programming, perhaps summarized the content of a bug report best:

A bug report should contain everything there is to know about the software bug.

Indeed, after reading a bug report, your developers should fully understand the exact malfunction and will be able to start the debugging process much faster.

For a better idea of what exactly constitutes a bug report, take a look at this example:

This particular bug report details a broken action—the software isn’t working as envisioned.

The bug in question is described as a major bug, and the reporter took the time to include exact steps to reproduce the bug. Furthermore, they even attached screenshots of the issue.

As you can see, the bug report is relatively thorough, with plenty of details describing the defect’s exact nature. The reporter has even listed the environment and affected version details.

This sample is a superb bug report, as it clearly explains the problem and lists all relevant information. With such a document, your developers should have no problem debugging.

What is the process of reporting bugs

Bug reporting can’t be done haphazardly. If you lack a standardized, consistent procedure, the bugs will take longer to resolve, as developers and testers won’t know what’s expected of them.

They’ll lack a systematic workflow.

Therefore, to solve as many defects as possible, it’s worth maintaining a fixed bug reporting workflow.

The graph below displays a typical bug reporting process:

Before the tester can write the bug report, they must first identify if the bug really is a bug and then reproduce it.

Then they can compose the bug report, making sure to assign severity and priority.

That bug report is designated to a developer who fixes the defect. Finally, the tester verifies that the bug is genuinely solved, after which the bug report can be closed.

It’s important to note that roles shouldn’t change throughout this process. QA shouldn’t try to fix bugs, and the development team shouldn’t look for bugs.

Each department has its own responsibilities, and tasks are best executed when teams focus on their own duties.

There’s no need to interfere with the other team’s workload, as this will only create confusion and prolong the bug reporting process.

This concept is nicely visualized in the illustration below:

Although this hypothetical wall might initially seem counterproductive and a collaboration roadblock, it’s actually an extremely effective strategy.

By clearly defining roles and insisting on task delegation, your testers and developers should have fewer distractions and be more effective.

Consequently, the bug reporting process will be far smoother.

What is the bug report life cycle

In general, there are two types of bug reports: open and closed, indicating whether a bug is resolved or unresolved.

However, a bug report goes through an extensive series of states between these two key positions. This is called the bug report life cycle.

For a visual representation, look at the graph below:

A new bug report is always assigned to a developer. Once the developer starts working on a resolution, that bug report is considered open.

The developer will then fix or close the bug report (if he determines it’s unnecessary). You can see possible reasons for this on the graph’s right-hand side.

If the bug report is marked fixed, the tester must then verify the solution. If the bug is still active, the entire process begins again.

However, they can close the bug report if the defect is genuinely solved.

The bug report life cycle is rarely quick. In fact, if a company has many bug reports, it’s not unusual for a bug report life cycle to last years.

This all depends on how complex the bug is and how important its resolution is. In other words, it depends on the bug-fixing cost/benefit ratio.

John Arthorne, Shopify’s Senior Development Manager, went so far as to say:

If developers don’t see any benefit to resolving the bug, the bug report life cycle could be prolonged indefinitely.

Consequently, it’s crucial to perform systematic checks on your bug reports. That way, you’ll know they’re being addressed on time and will avoid an endless bug report life cycle.

Who is responsible for reporting bugs

It’s often said that testers are responsible for ‘breaking’ the software. It’s their task to uncover the codebase’s defects and flag down all its faults.

Since the QA team tests the software, they’re also the first employees who come in contact with software bugs. Consequently, they’re also responsible for reporting these defects.

Generally speaking, QA is always in charge of reporting software bugs—especially while the software is still being developed.

This topic was also discussed on Twitter, with one user highlighting the difference between QA and developers:

While your developers are responsible for fixing bugs, QA must first find them. As a result, QA is the most common bug reporter.

That being said, it’s also possible for bugs to creep into production, where users will likely notice these defects.

To mitigate this issue, many software platforms offer a bug tracking system where users can also report bugs QA happened to miss.

For example, take a look at this Quora user’s account:

In this situation, the user noticed the bug and reported it to Mozilla.

It’s a good thing they did, as Mozilla resolved the issue almost instantaneously—they were clearly keeping track of their user-submitted bug reports.

To sum up, QA has organizational responsibility for reporting bugs and usually looks for defects while the software is being built.

However, it’s best to also allow a way for users to report bugs once you release your software, as they can also come across bugs QA missed.

How do you write a bug report

The primary purpose of a bug report is to facilitate the developers’ debugging efforts. With this document, they’ll have a great starting point for fixing the defect.

Therefore, to assist your developers as much as possible, a bug report must be detailed. It should contain all known facts about the bug.

Let’s start by looking at an example of what not to do:

Your bug report shouldn’t be devoid of information like the above image. Furthermore, a more appealing user interface would also do some good.

Ideally, your bug report should contain the following elements:

Each bug report begins with a title. This should be a brief yet descriptive statement describing how the software is malfunctioning. The title can be expanded on later, in the summary.

It’s also critical to describe the bug’s environment—what product it appeared in, on which platform, which device, etc.

This information is vital when reproducing the bug. If the environment is incorrect, even the steps to reproduce won’t help.

These steps to reproduce lead others to the software’s current behavior. It’s a good idea to attach visual proof of the faulty operation.

However, a bug report should also state the expected result or how the software should behave.

Finally, each bug should be categorized according to priority and severity. That way, developers can easily prioritize their debugging.

Although there’s plenty of information to include, all this intelligence is necessary when writing a bug report. Ensure all your bug reports have this information—your developers will thank you.

What tools are used to report bugs

Bugs can be reported via several mediums. You can keep an Excel spreadsheet, write documents in Word, or even send emails to the team in charge of solving them.

However, these methods could work better. Excel doesn’t provide great visibility, Word isn’t optimized for the many bug report categories, and emails can easily get lost.

Luckily, there’s an easier way.

Nowadays, many companies have specialized bug reporting platforms and tools that facilitate the process.

Since these resources are designed exclusively for bug reporting, they should significantly improve workflows.

For example, Apple offers Feedback Assistant: a solution where developers can report Apple-related bugs.

If you have an issue with Apple’s systems, the defect is best reported with Feedback Assistant.

Here’s a preview:

Apple asks for the information they need to solve the bug, after which the report will be automatically sent to their developers.

Besides such OS-restricted resources, there are also tools that can be used universally, regardless of the software.

Consider our own bug reporting tool, Shake—this solution works with any mobile device.

With Shake, all you have to do is simply shake your device, and the developers will immediately receive a comprehensive bug report.

There’s no manual data input, as all the information will be attached automatically.

Here’s a quick preview:

This bug report contains everything your developers will need. Environment details, logs, steps to reproduce, screenshots, screen recordings, and more are all included in the bug report.

With this tool, your testers can submit bug reports automatically, significantly accelerating the bug reporting process.

What is the difference between bug reporting and bug tracking

When a tester encounters a software bug, their main task is to report it.

The bug is described, assigned priority and severity, and handed over to the developers. In other words, the bug is reported.

Once the bug report is successfully logged, the bug tracking process begins.

Whereas bug reporting entails cataloging a software defect, bug tracking is the process of managing that bug.

Technopedia defines bug tracking as follows:

Keeping track of software problems (i.e., bugs) involves delegating the bug to a developer, updating its status, and continuously monitoring its progress.

For example, if a software bug fix is awaiting verification from a tester, it’s vital to switch its status from fixed to pending retest.

Otherwise, the developer’s fix will never be double-checked, and you risk a faulty resolution. Such supervision is an essential part of bug tracking.

The easiest method to track software bugs is to invest in a bug tracking tool. These solutions are designed for bug management and should make the tracking process easier.

A great example would be Bugzilla, a classic bug tracking tool.

Have a look:

Bugzilla tracks the bug’s assignee, status, last update date, and even bug type. The tool is a comprehensive, detailed repository of all aspects related to bug reports.

If you couple such a solution with a bug reporting tool, your QA employees will have all the resources they need to report bugs effectively.

Consequently, you’re sure to release smooth, high-functioning software.

Conclusion

Bug reporting is a complex process. The process requires a joint effort between testers and developers and demands excellent management skills.

If a bug report is written poorly, or developers take it upon themselves to look for bugs, the entire workflow can be slowed down, significantly impeding development.

This is why it’s essential to familiarize yourself with standard bug reporting procedures and fully understand the best practices.

Once you’ve established everything bug reporting entails (e.g., the bug report life cycle, bug reporting tools, etc.), your bug reporting will be significantly accelerated, and, ultimately, your software will ship faster.