How to Write Bug Reports in Manual Testing: Report Structure

Are you a manual tester and want to improve your bug reporting skills? You’ve come to the right place. Bug reporting is one of the most important skills a manual tester should possess.

One of the main responsibilities of a manual tester is to find and report issues with the software. We call these issues “bugs”. Bugs can be found everywhere. Some are obvious while others are harder to find. It is up to the manual tester to thoroughly explore a given app or website, and look for ways to break them. Or in other words, expose bugs that can lead to a bad user experience. However, it’s not enough to just know a bug exists. You need to properly report the bug, by writing a bug report, in order to get it fixed. Think of it this way—the better your bug report is, the higher the chances of getting the bug fixed.

Essentially, bug reporting is a skill, and one that is certainly worth having and improving. We have a few tips—coming from an experienced manual tester—to help you master this skill. Let’s take a look at why bug reporting is important and how you should report bugs effectively.

Why should bugs be reported

Bug reporting is an important aspect of software testing. It helps smooth out software, making sure it works as required without frustrating users. Namely, finding and reporting bugs will ensure the software is user friendly, safe to use, and will not cause problems to the owners, development teams, and most importantly, the end users.

After detecting a software bug, it is crucial that you report it to developers in a way that they can easily understand so that they can fix it fast and efficiently. You need to describe the bug in detail, explain where it appears, and be able to reproduce it. A good bug report will help developers fix the bug faster, while a bad bug report could result in the software issue not being resolved and delay releases.

What could happen if a bug is NOT reported

Imagine using your favorite mobile app and the buttons are not working, there is text missing, and the videos are stuck on full screen. You’d be pretty annoyed wouldn’t you? These are just some minor bugs. Now imagine a critical bug that causes the app to restart every time you try to login. The app would be unusable and you would not be happy. Unfortunately, it is impossible to find all the bugs in any software, so our job is to find the ones that users are most likely to stumble upon while using the software. If ignored, software bugs can be exploited, resulting in data leaks and ransomware attacks.

The biggest software bugs and tech failures of 2021 prove how serious software glitches and defects can be. They can ruin reputations, cost companies millions to fix, and be the downfall for apps. Therefore, to ensure the quality of your product, you need to detect bugs before they become an issue and report these bugs to development teams so they are addressed accordingly.

How and what data should you collect for your bug report?

Once you have been assigned to a project, there are various types of testing you can perform. There are functional tests, component testing, change-related, and exploratory testing, just to name a few. Whatever type of testing you choose, the goal remains the same—finding bugs. Usually, there are three parties involved in every project: the client, the developers, and the testers. Each party has to interact with one another for the project to be a success. The client provides the project specifications, the developers are responsible for developing the software, and the testers have to make sure the software works as intended. For the testers, it is important to keep track of where and how the bug occurs. This information is vital for developers to be able to reproduce the bug in order for them to fix it. Here is how you should collect and report data about the bugs you find.

Software and hardware versions

As a tester, you should note the version of the software you are testing as well as the devices and device versions you are using. For example, if you find a bug while testing a website you should specify the browser, its version, and the website used. As for the hardware, you should note the device and its version. This information can be found in the settings or “About” section.

For example:

• Website: https://www.testdevlab.com/
• Browser: Google Chrome | Version 96.0.4664.93 (Official Build) (x86_64)
• Device: MacBook Pro 2017 2,3GHz i5 | Mojave

Reproducibility

Sometimes the bug requires a unique sequence of actions and conditions for it to appear and the tester cannot come up with steps to consistently repeat it, which makes it difficult to reproduce the bug. So noting that the bug is not reproducible 100% of the time is also a useful piece of information. To get the rate of reproducibility, you have to try to reproduce the bug multiple times and note how many times the bug has appeared out of the total number of attempts.

For example:

• Reproducibility: 2/5 (Out of 5 attempts, the bug was seen 2 times)

Preconditions

Preconditions are a prerequisite. It is something that has to happen before something else can happen. Therefore, when writing a bug report, you have to mention the things you did before you were able to detect the bug. This includes things likes:

• Specifically configured user profiles
• Specific device setups (Connected to WiFi, using Bluetooth devices, etc.)
• Have multiple devices

Steps to reproduce bugs

Steps are detailed instructions for the developer to follow in order to reproduce the bug. Just like assembling a chair purchased from the store, the instructions have to be in order and specific. If a step in the bug report is missing, there is a chance that the developer will not be able to reproduce the bug in order to fix it.

Here is an example of a button on the “Settings” page that is not working:

Steps to reproduce:

1. Open randomwebpage.com*
2. Navigate to the “Settings” page by clicking the cogwheel icon in the upper left corner
3. Open “Page Layout Settings”
4. Click on “Change layout” button

*This is not an actual bug or a page for testing. It is just for the purpose of showing an example.

Visual proof

This step is pretty self-explanatory. Gathering visual proof of how you reproduce the bug and how the bug behaves is an easy way of explaining what the issue is. Sometimes the steps to reproduce the bug are complicated, so showing a video or screenshot helps the developer understand how to deal with the bug.

• Video. While recording a video you should show the process of how and when the bug occurs. The best practice for recording the video is using a screen recorder, ideally enabling a plugin that shows where you click or tap on the screen.
• Screenshots. Some simpler bugs—or bugs that are static in nature—don’t necessarily need a video. In such instances, using a screenshot and outlining the part of the screen that has the issue would suffice. Nevertheless, recording a video is preferable in most cases.

Logs

Getting logs is a bit trickier for beginners, but they are an essential part of any good bug report. Logs show developers the different data so that they can analyze it and pinpoint the part that is causing the bug. This data depends on what kind of logs are expected, like console logs, code, and network conditions. There are various ways to record logs. Different platforms require different apps. The recording process is simple enough. Start the software to record the logs, reproduce the bug, end the recording, and save the file in a format that the developer will be able to view.

Here are some tools you can use to record logs:

• Device built-in debugging tool (Accessed by enabling developer tools)
• App built-in debugging tool (Some testing-specific builds include this feature)
• Third-party debugging tools (Android Studio, Xcode)

Taking into consideration project expectations

Once you find a bug and document it accordingly, it is time to look at and follow the project guidelines. Keep in mind that software testing is about improving things, so if you see something that can be improved do not hesitate to talk it over with the team lead or project manager. Before the bug can be reported there are a few things you should consider to keep things organized.

Other testers’ bug reports

You will most likely work with other testers—either joining them on an existing project or starting a new project together. You have three options. First, you can look at how previous testers reported bugs and follow their lead; secondly, you can follow the guidelines that the project manager expects; and thirdly, you can report the bugs in a way you believe is most suitable for the project. Keep in mind that you are working in a team so everything is up for debate. Listen to your team and they will listen to you.

No duplicates

In the case that the project has existed before you were assigned to it, there will already be plenty of reported bugs. If you find a new bug before creating a bug report you should check to see if the bug has been reported previously. You can do this by searching the list of active and closed bugs. If a similar bug has already been reported and is active you can update it with the data you have collected. If the bug has already been verified and closed you can reopen the bug report and add your findings.

Certain restrictions

Some projects have their own unique expectations and limitations, and once you join the team they will provide this information to you. These restrictions may include a specific way to gather logs, a unique way of reporting bugs, and so on. It all depends on the project.

Creating a bug report

After you have found a bug, gathered the data, and checked in with the project guidelines, you now have everything you need to properly report your first bug. You are finally at the point where you can click the “Create” bug report button. This might seem like a lot of information to process, but once you have reported your first bug it will become easier every time. Let’s go over the process of creating a bug report.

Different platforms to report bugs

There are various platforms the project could use: Jira, Visual Studio, etc. These platforms contain all of the information about the project, like the schedules for the next sprint, reported bugs, planned bug fixes and releases, and other important information. The section you should be interested in at this point is the reported bugs section. This is where you will find all of the previously reported bugs and where you will be adding yours as well. To add your bug, click on the “Create” or “+” button. This will usually result in a pop-up window to appear with blank fields for you to fill out.

Structure of the bug report

There are a few things you should always take into account when creating a bug report. Since someone else is going to have to read—and understand—the bug report it is important that you use simple language, neat spacing between lines to make the text easy to read, and bold font to highlight section titles. You probably get the idea—the structure of your bug report should be clear and concise. There is a lot going on in the bug report, however, the three main sections you will be working on are the Title, Description, and Attachments. Leave the rest to the developer who is going to be fixing this issue, unless instructed otherwise. Now, let’s look at these sections in a bit more detail.

Title

The idea of a title is to describe the issue in a few words. The title has to be simple and understandable. Here is a little trick I like to use: “what, where, when?” If you can answer these three questions as simply as you can, you will get the best title for a bug. Try it.

For example:

Close button not working on homepage when clicked.

What? Where? When?

Additionally it helps to add some tags or labels in front of the title, like “AND:” for Android only devices or “IOS:” for Apple devices. Or maybe you can add some project specific pages like “Homepage:”.

Description

This is the part where you will be listing most of the data you have collected. Here you can explain the issue in a bit more detail. Let’s look at the order of how things should be described:

• Reproducibility. Report the rate of reproducibility. Namely, out of how many attempts using the same steps were you able to reproduce the bug? Use ratios to illustrate reproducibility. If the bug can be reproduced 100% of the time you don’t have to add this to the description.
• Preconditions. List the preconditions prior to reproducing the bug. Use short and simple sentences.
• Steps to reproduce. Go over the steps necessary to reproduce the bug in the correct order using the data you collected.
• Expected results. Explain what should have happened if the bug had not been present.
• Actual results. Describe what actually happened due to there being a bug.
• Devices and versions. Add the devices and versions on which the bug is present.
• Notes. Include additional information that could be helpful for the developer.

Now that you know the order in which you should describe the bug, here is an example of a bug report to give you a better understanding:

Reproducibility: 3/5

Preconditions: Be logged in, use a phone connected to WiFi

Steps to reproduce:

1. Open randowmwebpage.com
2. Scroll down to the bottom of the page
3. Open Questions form by clicking “Open”
4. Click “Close” button

Expected result: The Question form to be closed

Actual results: The “Close” button is unresponsive

Versions and devices:

Webpage: randomwebpage.com | Build 10.4.1

Browser: Google Chrome | Version 96.0.4664.93 (Official Build) (x86_64)

Device: Google Pixel 4a | Android 12

Note: See attached video with audio and logs

Attachments

As soon as everything is written, the last step is to add some visual proof. Generally, on the pop-up window there will be a section where you can upload your videos, screenshots, and logs. Simply select “Attach”, upload your files, and save them.

Following up on reported bugs

Your work is not finished just yet. Even though the bug report is written and submitted, you still need to follow up. Namely, you are still responsible for the bug report. This means that if anyone has any questions about it, it’s your responsibility to answer them. You need to keep track of the bugs and their status until they are fixed and closed.

Adding comments

After you create a bug report, a developer will be assigned to look into it. If there is something unclear or more information is required, they will be adding a comment under the bug report. Your job is simple at this stage—just answer their question.

Retesting the software

When the bug has been fixed, you will be notified to retest it. Follow the steps listed in the bug report you have created and see if you can reproduce the issue yourself. Be sure to use the same setup and if all is well move on to the next step. If not, gather the new data and update the bug report. The developer will then see this update and the cycle will repeat until the bug is fixed. Once the bug is fixed and can no longer be reproduced, you or the developer can change the bug status to “Done”.

Put your bug reporting skills to the test

So, there you have it—you now know everything there is to know about bug reporting and how to perfect your bug reporting skills. You now understand why bug reporting is important, know the type of data you should collect for a bug report, and are able to efficiently structure a bug report and follow up on it until the bug is fixed.

The most important thing to remember when creating a bug report is that you are not alone. Everyone has to start from somewhere so do not be afraid to ask your colleagues, project leads, or even use Google to find an answer to your question. Use our manual tester’s guide to effective bug reporting and put your bug reporting skills to the test.

Thinking about a career change? Become a part of something amazing. Check out our open positions. Find out why we are the number one quality assurance service provider.