Data you should receive with each app bug report

Generally speaking, you should strive to have as few software bugs as possible, as these errors cause your product to malfunction and lead to user dissatisfaction.

One of the best approaches to reducing these issues is to have your testers and users submit bug reports.

Developers use bug reports, detailed reports describing every aspect of a bug, to aid their debugging efforts.

However, for a bug report to be helpful, it should contain certain essential information.

To find out what, keep reading— this article lists all the data you should receive with each app bug report.

Bug title

Each bug report should begin with a title. After all, your employees need to differentiate between bug reports, and a title ensures they can easily recognize each unique report.

Generally speaking, the title should describe the bug concisely yet in a descriptive manner. Developers should understand at a glance what the exact problem is just from the title alone.

This topic was also discussed in a Quora thread, with one user providing an example of an unsatisfactory title.

The above example is highly generic and needs more helpful details.

Consequently, it’s impossible to understand the problem, and the developers must carefully consult the rest of the bug report to extrapolate the precise issue.

Here’s a clearer, more specific variation of the previous example:

Video on landing page not playing when clicked.

With this title, developers will know what problems the bug is causing as soon as they see the document. There’s no room for ambiguity.

Environment specifications

Some bugs will only appear in specific environments and be absent in others.

For example, although the Add to cart button isn’t functioning on iOS, it might work perfectly normally on Android.

Because of these intricacies, it’s essential to include environment specifications (e.g., device type, operating system) in the bug report.

That way, developers know the prerequisites for recreating the bug.

Luckily, some bug reporting tools record all these details automatically, so your testers don’t have to keep track of them manually.

For example, here’s what Shake automatically attaches to each bug report:

Shake immediately includes environmental details such as the devices’ OS and model, the app version, connectivity details, the memory and battery status, and more.

Numerous datasets contribute towards the description of the environment, and Shake’s automated reporting ensures your developers receive most of them, saving your testers a fair chunk of time.

Bug reproducibility

Although environment specifications help understand bugs, it’s never a given that your developers will be able to recreate the bug every time.

Sometimes bugs only occur after a particular sequence of actions or under specific conditions. A recent study offered some insights regarding the exact preconditions for bug reproducibility.

Some bugs require rare combinations and/or relative timings of inputs, or a specific state to be reproduced; or there may be a long delay between the fault activation and the failure occurrence. In other cases, the activation of a fault makes the system traverse several error states.

Given these determining factors, consistently reproducing a bug can be challenging. In fact, some bugs, more often than not, simply don’t appear again.

Nevertheless, developers will appreciate knowing a bug’s reproducibility rate, as this will also influence their debugging efforts.

For example, if the reproducibility rate is high, yet they can’t recreate it, they’ll know to ask for assistance.

The reproducibility rate is usually expressed as the number of times a bug has appeared vs. the number of attempts.

So, if a bug appeared only five times out of twelve, the reproducibility rate is 5/12.

Steps to reproduce

While the reproducibility rate can be highly useful, it’s not much help on its own. What good is a reproducibility rate if your developers don’t know how to reproduce the bug?

This is what the steps to reproduce are for. These instructions detail the exact steps, in the correct order, that the developers must follow to recreate the bug.

Given the volatile nature of bugs, the steps to reproduce must be accurate. The developer might never be able to recreate the bug if a step is missing or incorrect.

Here are some sample steps to reproduce:

The steps are clear and precise, letting developers know the exact measures they need to take to recreate the bug.

As with the bug title, the steps to reproduce must be short yet detailed.

That way, developers will be able to quickly understand what actions will recreate the issue without spending too much time deciphering the instructions.

Expected result

The expected result usually comes immediately after the steps to reproduce as a summary of how the user expects the software to act after the steps are followed.

In other words, the expected result describes what would happen if there was no bug.

Consequently, it’s crucial to be precise when writing the expected result. If your testers are too vague, the developers won’t know what well-functioning software looks like.

They simply won’t know when they’ve solved the bug.

Here’s an example of a subpar expected result:

The landing page should play the right video.

This description falls short, as there’s no way to understand which video is the right one. The vocabulary is too ambiguous.

It would be better to rephrase the description as:

The product introduction video on the landing page should play with both visuals and audio.

This is a much-improved version, as it specifies the content of the video and mentions that there should be audio and visuals. The developers know exactly how the software should be acting.

Actual result

If the expected result explains how the software would function without the bug, the actual result does the opposite. It details how the software is actually behaving, with the bug still present.

To be more specific, the actual result describes how the bug distorts the expected result. In other words, how the bug affects the software.

As with the expected result, the actual result should be written in clear, straightforward language, with plenty of details and no generic phrases.

For example, a developer likely wouldn’t appreciate this actual result:

The video on the landing page isn’t working.

A simple isn’t working isn’t specific enough to assist anyone. What does isn’t working mean? Does the video crash? Is the wrong video playing?

Now consider this reworked version:

The video on the landing page shows the claim procedure instead of a product introduction, and the visual and audio only work for the first five seconds.

This is an improvement, as it specifies exactly how the video is malfunctioning and what is infuriating about the error.

The developer will understand the specific problems the bug is causing.

Bug severity

Not all bugs are created equal—different software bugs cause different levels of damage.

In continuation of the previous example, a video crashing would likely constitute a major bug. However, if the audio dropped off for one second, that could be considered a minor bug.

There are altogether five levels of bug severity, shown below:

A critical bug causes severe damage. If an application refuses to launch, this is a critical bug.

After that comes a major defect—an important feature malfunctioning without a workaround. For example, a camera app not taking photos.

A minor bug is a smaller issue with a workaround. A good example is broken shortcuts, but the toolbar options perform the same action.

Even more harmless is a trivial defect. This bug is an annoyance, like a pop-up message consistently appearing every hour.

Finally, an enhancement is working software that could work better in terms of the UX (e.g., layout changes).

Bug priority

Whereas severity measures the bug’s impact on software, the priority indicates how quickly this defect should be fixed.

Developers use the priority level to know where to start debugging and to determine which bugs require the most attention.

The priority is typically decided in regard to business importance and to what level the bug will affect the project’s success.

All in all, there are three priority levels:

A high-priority bug is an urgent matter and should be resolved immediately. Usually, these defects are critical or major bugs, such as the application crashing.

Next up is medium priority—errors that can be fixed in the normal course of development (e.g., a video not playing). However, the developers should ideally solve these bugs before the next deployment.

Lastly, low-priority bugs are the least important issues that barely affect the project. For example, the audio in a video dropping off for one second.

Activity history

When examining software bugs, it’s helpful for developers to know the activity preceding the error’s appearance, as this activity possibly triggered the bug.

The term activity encompasses several datasets: user actions, network traffic, system events, notifications, and logs.

This information can be challenging to uncover, but luckily, there are tools that deliver it to you.

For example, Shake tracks all these details and automatically attaches them to each bug report.

The user actions (taps on UI elements) and system events (app lifecycle events) are tracked automatically.

However, network traffic tracking must be enabled. Furthermore, users can also add custom network requests with the following codeset:

Custom requests are also available with notifications and logs. Here’s the codeset for implementing custom notifications:

Regarding custom logs, users can select the following log levels:

All this information significantly facilitates debugging, as all possible activity details will be hand-served to your developers.

Black box data

The app’s environmental profile is always useful for debuggers—especially when it comes to the insight into the seconds right before the bug occurs.

These details might just help solve the issue.

With this in mind, Shake automatically delivers black box data with every bug report. These datasets record everything that happened 60 seconds before the reporter submitted the ticket.

The black box data encompasses CPU usage, app memory usage, device memory usage, network details, and device orientation.

This information is extremely comprehensive; for example, Shake accounts for multi-threading, meaning that CPU usage can go above 100%.

Furthermore, the device memory usage shows both exact memory usage and the percentage of total available memory. Here’s an example:

App memory usage is similarly described, with exact MB measurements.

The network chart displays the app’s connectivity details, providing the following intelligence:

Finally, you’ll also learn the app’s orientation: portrait or landscape.

With these environment details at your developers’ disposal, they should solve the bug in no time.

Visual proof

Sometimes the easiest way to describe a bug is to simply show it. Consequently, visual proof is often the best medium for explaining the bug’s impact on the software.

By including screenshots or screen recordings in the bug report, developers can see the error with their own eyes and, therefore, better understand it.

There are multiple screenshot and screen recording tools available, but it’s also worth investing in a bug reporting tool, as they often also incorporate these features.

For example, Shake automatically includes screenshots with each bug report—there’s no manual work involved.

Furthermore, you can also enable automatic screen recordings in Shake. These are the setup steps:

This automatic screen recording is fifteen seconds long, which should be more than enough to capture the bug.

With this visual proof, developers will always have a front-seat view of the error, greatly helping their debugging efforts.

User metadata

Lastly, it never hurts to include the bug reporter’s personal information in the bug report. That way, developers will know whom to contact if they have any questions.

Furthermore, a specific user status might be causing the bug, so it’s a good idea to have extensive user details. For example, an error might occur only with subscribed users.

Unfortunately, bug reporters won’t always remember to include their personal details in each bug report. However, there’s a way to automate this process with Shake.

After registering a user, Shake allows you to attach a map with key-value pairs containing additional data about the user.

That way, the following data will accompany each user:

In other words, each bug report will include the above details regarding the user who submitted the ticket.

Consequently, your developers will always know who to contact if something isn’t clear to them.

Conclusion

A bug report is only helpful when it contains specific app-related datasets. If one of those details is missing, your developers might struggle to resolve the issue.

For example, imagine receiving a bug report explaining the actual result but with no expected result.

The fact that there is some missing information would immediately make it difficult to resolve the bug.

Therefore, it’s essential to include as many details as possible, ranging from environment specifications, steps to reproduce, activity history, visual proof, user metadata, etc.

Therefore, ensure your testers provide as much information as they can, and their bug reports should be top-notch.