Luxe Quality logo
Quality Assurance

Oleksandr Leonov, QA Automation Engineer Lead & Mentor's Scrum Master

Oct 19, 2023 18 min read

How To Write A Bug Report: Best Practices in 2023

Bug reporting is a necessary part of the software development and testing life cycles. These are used to document an issue or problem on the web site or app. A bug report is a technical document that describes sequences of actions that led to the incorrect operation of the test object and the expected result.

How To Write A Bug Report

What is a bug report?

A bug is a discrepancy between the actual result of the program and the expected result. Defects are detected at the stage of software (software) testing when the tester compares the obtained results of the program (component or design) with the expected result described in the requirements specification. 

An effective bug report should include a title, problem description, environment information, a sequence of steps to reproduce the bug, and other details to help developers understand and resolve the problem more efficiently.

Anyone can write a bug report, but is every bug report effective? We have prepared a detailed guide how to write a good bug report and tips to maximize the effectiveness of bug reports. Let's start! 

The advantages of a qualitatively created bug report

To developers: 

  • Clear Problem Description: A well-structured bug report offers a clear description of the issue, helping developers to understand its essence. 
  • Steps for Reproduction: Detailed steps to reproduce the problem enable developers to find and fix the error quickly. 
  • Visual Aids: Screenshots or video recordings of the issue streamlines the checking process, making it easier to confirm the error's reproducibility.

For Testers: 

  • Tool for Interaction: The bug report becomes an essential tool for testers to interact with developers and confirm the existence of a problem. 
  • Accurate Problem Description: It allows testers to accurately describe the conditions for the reproduction of errors, simplifying internal communication and providing effective collaboration with other team members. 
  • Enhanced Testing Planning: Bug reports help to plan the next testing phases, improving overall testing efficiency. 

For Project Managers: 

  • Objective Project Information: Bug reports provide objective data about the project's current status and potential threats. 
  • Basis for Prioritization: They serve as a basis for deciding patch priorities and release schedules 
  • Timely Problem Resolution: Bug reports enable timely action to eliminate problems and improve product quality.

For Users: 

  • User-Centric Benefits: Effective bug reporting helps resolve issues that may affect users, providing them with a more stable and reliable product.

In summary, a quality bug report facilitates effective collaboration among all project participants, simplifies problem understanding and resolution, and contributes to the achievement of overall project goals.

How to write a bug report?

A properly written error report is one of the critical links in identifying and correcting software errors. If you want your deficiencies to be corrected quickly and efficiently, preparing and presenting information logically and clearly is essential. In the next section, we will consider how to write a bug report with which you can best communicate your observations to the developers. 

Gathering information before writing

The first and most important step in identifying and solving software bugs is gathering information before writing a bug report. This stage determines the quality and efficiency of subsequent actions, as the accuracy and completeness of the information you collect can affect the speed of solving the problem. Below is a detailed analysis of this crucial stage on how to prepare a bug report in software testing: 


Identifying the problem: Before collecting information, it is essential to identify the problem or bug in the software accurately. This may include detecting incorrect functionality, non-compliance with specifications, program emissions (crashes), errors in the user interface, and other anomalies. 


Description of the problem: A detailed problem description is a critical element of information gathering. Try to provide as much detail as possible about the problem. Describe what you saw when reproducing the problem, including text error messages. 


Steps to reproduce: Describe in detail the steps that allow you to reproduce the problem. Start with the initial state of the application or system and follow the steps that lead to the error. This will help developers quickly reproduce the problem and fix it.


Expected and actual results: In the bug report, it is important to indicate the expected and actual results of the actions. A bug report with expected and actual results helps developers identify where the problem occurred and fix it.


Environment: Information about the environment in which the error occurred is also important. Note the operating system version, browser, hardware platform, and any other factors that may be important in reproducing the problem.


Additional data: If there is additional data, such as screenshots, videos, event logs (logs), or any other files that can be useful for developers, do not forget to add them to the bug report (there should be at least a screenshot taken, this is a mandatory attribute for a good bug report).

Gathering information before writing a bug report is an essential step in understanding how to create a bug report effectively. This process helps to create a high-quality and effective problem report, which in turn assists in identifying and resolving errors promptly, thus contributing to the overall enhancement of the software's quality.

The correct structure of the bug report in software testing

If you're wondering how to make a bug report, especially an effective one, pay attention to the main attributes that give structure and clarity to your observations. In this section, we'll look at the critical attributes of a bug report and explain their structure and meaning in detail. 

Summary (Topic)

A bug report's first and most important attribute is a brief description of the problem. In this field, you need to meaningfully explain the essence of the bug, answering the questions: "What doesn't work?", "Where does this problem occur?", "When does it occur?".  

For example, "Required fields are not highlighted in red on the registration form after clicking the 'Submit' button." 


This field provides an extended description of the nature of the bug and additional details if necessary. In bug tracking systems, the "description" field is usually used for most of the following steps. 

Steps To Reproduce

This field is intended to accurately describe the steps to help other users or developers quickly reproduce the problem. 


  1. Go to the site (link to the site). 
  2. Click on the "Registration" button. 
  3. Click on the "Send" button. 
  4. Take a look at the "First name" field (the last step should always include a call to attention to the error). 

The steps to reproduction should be precise, ensuring that different individuals interpret them consistently.

Expected and Actual Results

In a bug report, it is important to provide detailed information about the expected and current results of testing a function or software: 

  • Expected results: Describe how the function should work or what result you expected from specific actions or functionality. Specify expected values, messages, or system status. 
  • Actual results: Report what results you observed after performing these actions. Include a specific description of the error, anomaly, or flaw you've noticed. 

This information helps developers to accurately understand the difference between the expected and actual results of the problem. Knowing how to create a bug report is essential, as it significantly contributes to the efficiency and productivity of the remediation process by presenting information in a structured and clear manner. 


Files such as screenshots, videos, or log files should be attached to the bug report if it can help to understand the problem. Information presented visually can be more effective for understanding than textual description (A screenshot showing the problem area should be mandatory).

Priority (Priority of the defect) and Severity (Severity of the defect)

A bug report includes information on Severity and Priority, determined for each found defect. 

Severity determines how seriously the error affects the system's functionality. Here are some Severity levels: 

  • Blocker: This level is used when an error blocks the main functionality of the system and makes it impossible to use it. For example, it is not possible to log in with an existing user. 
  • High: This level is used when the error affects critical functionality but does not block it completely.  
  • Medium: This level is used when the error affects essential functionality but is not critical. For example, if inappropriate graphics appear on the company's website, but this does not prevent users from making purchases. 
  • Trivial: This level is used when the bug has a minor impact on functionality and may include, for example, small text errors or minor cosmetic issues. For example, if the company's website mistakenly displays an entirely different logo, it can significantly damage its reputation.

Priority determines how important it is to fix the defect. Priority is determined based on the impact of the defect on the project and deadlines.  

  • Highest priority: The problem will block progress. 
  • High Priority: Such a bug may require immediate correction due to its strategic importance for the company. 
  • Medium priority: Minor problem or easily worked around. 
  • Low Priority: Such errors cannot significantly affect the project's work and can be corrected in the developers' free time.

Thus, depending on the Severity and Priority, developers determine when and in what order to fix defects to ensure the best user experience and critical tasks for the project. 


Status displays the current state of the bug report, indicating its life cycle from creation to retest and completion. Status names may vary in bug-tracking systems, but the general principle remains. 


Attributes such as Component and Environment indicate the environment in which the test was run and on which platform the defect was detected. This information helps developers find and fix the problem faster because they understand the context in which the testing occurred. 

Additional attributes

It is also worth considering additional attributes such as Fix Version, Assignee, Build, Label, and others, which can be helpful in better understanding and resolution of defects. 

The correct structure of a bug report helps to identify, solve, and track software errors effectively, improving product quality and user satisfaction. 

Bug report submission and management 

Submitting a bug report to the specified bug management systems or tables is critical in managing bugs and problems that arise during software development or product operation. This process includes the following key steps and principles: 


Gathering information and creating a bug report: The tester should gather all the necessary information about the problem before submitting a bug report. This includes a description of the error, steps to reproduce, actual and expected results, device configuration data, and other details to help developers reproduce and fix the problem. 


Choosing a bug tracking system or spreadsheet: One of the critical aspects is choosing a bug tracking system. This can be a specialized bug-tracking system such as Jira, Bugzilla, Mantis or a table created in a standard editor such as Google Sheets or Microsoft Excel. The choice depends on the team's needs and the project's size. 


Creating a new bug report: The tester creates a new record in the bug tracking system. This record contains all the information collected about the problem. In bug tracking systems, these can be appropriate fields for description, steps to reproduce, attaching files (such as screenshots or videos), and the ability to set priority and other attributes.


Assign a responsible developer: An important step is to assign a specific developer responsible for fixing the problem. The priority of the bug report is also determined, indicating the urgency of the correction. Typically, the team uses a ranking system of priorities, where higher values indicate greater urgency.


Status tracking and updates: When a bug report is created, and a responsible developer is assigned, its status is tracked in the system. The submitter and other contributors can check the bug's status and receive updates about the fix. 


Bug report fix verification and closure: After the developer fixes the bug report, the bug report is returned to the sender or other testers for verification. The bug report can be closed if the problem is fixed. 


Analysis and reporting: Bug report data can be used to analyze product quality, identify patterns, and improve the development process. Knowing how to report a bug in software testing is crucial, as effective reporting can help make decisions about priorities and product development direction. 

Submitting a bug report to a bug-tracking system or spreadsheet is crucial for systematizing, tracking, and fixing software defects. Learning how to create a bug report effectively ensures product quality and reliability, making it an essential skill for any software tester (you can also learn about our quality assurance and testing services to ensure the reliability and quality of your software product).

Right and wrong examples of bug reports: How not to get lost in the details

In this section, we will consider the important aspects of the description of Actual and Expected results, which are mandatory when creating a bug report. But before that, let's understand some terms: 

The actual result is the behavior of a component or system that we observe or obtain during testing. Here, we describe the results we got after completing all the steps of the bug report. The principle "What? Where? When?" is applied when describing the actual result. First, we write what is happening, then specify where it is happening, and finally, outline after what actions it happens. However, it is important to distinguish between the description of the defect and the description of the actual result – the latter should be more detailed. Very often, the actual result duplicates the actual result. At the same time, you should avoid complex sentences and leave the text as clear and concise as possible. This helps make the information easier to understand. 

The expected result is a component or system behavior that we expect to see under certain conditions defined by the specification or other sources. This field describes the expected behavior of the product at the final stage of defect reproduction. Even if this behavior seems obvious, it is important to describe it. This is especially important in the case of complex errors, where the product may work but not meet the requirements. The description of the expected result (also created according to the principle of "What? Where? When?") is necessary for a correct understanding of the problem and its subsequent correction. 

Let's start!

Result type

Incorrect example

Сorrect example



Nothing happens when the product is added to the cart

The product is not added to the cart on the product description page after clicking on the "Add to cart" button

"What?" – is the essence of the problem. 
"What?"– The product is not added to the cart.
"Where?"– this is the place in the system where the bug was detected. 
"Where?" –On the product description page.
"When?" is a conditional context that explains how a result different from the expected one occurred. 
"When?"  – After clicking on the "Add to cart" button 

The user cannot log in to his account 

The "Profile" screen not displayed on the "Login" screen after clicking on the "Sign in with Google" button

"What?" –The "Profile" screen is not displayed.
"Where?"– On the "Login" screen.
"When?"-–After clicking on the "Sign in with Google" button


The page is displayed correctly

The login field is displayed within the "Registration" block on the main page after clicking on the “Register” button

"What?" – The login field is displayed within the "Registration" block.
"Where?" – On the main page.
"When?" – After clicking on the “Register” button

When writing the results of a bug report, it is important to avoid wording where the actual and expected results differ only in a negative form. Adding a negative to one of the sentences is not the best approach.

Incorrect example: 

  • Actual result: The information matches on the product comparison page 
  • Expected result: The information does not match on the product comparison page  

Correct example: 

  • Actual result: The information matches on the product comparison page 
  • Expected result: A description of each product is displayed on the product comparison page

Avoiding objections as a result helps to make the bug report more clear and concise. 

Therefore, non-compliance with the principle "What? Where? When?" – is the most common and severe mistake when writing a report. Understanding the importance of this principle simplifies the reporting process and saves time. It is important to note that the expected and actual results are written according to the same algorithm as the summary. 

Tips for effective bug reporting and mistakes to avoid

Let's look at the essential tips from our experts that will help you write informative, precise, and effective bug reports from a professional testing perspective.


Lots of practice: Writing quality bug reports takes practice. Spend time practicing, especially expressing your thoughts clearly and concisely.


Focus on the real problem: Focus on the problem itself. Ensure you're clear on where exactly the problem is occurring, and provide screenshots highlighting the problem.


Accuracy of steps: Describe each step to reproduce the problem as accurately as possible. Ensure these steps are interpreted precisely how you want them to be.


Take a video: If the problem is difficult to reproduce in words or requires many steps, consider taking a good-quality video. This can make understanding the problem much easier.


Correct description: Ensure the bug report is correctly worded after providing all the necessary information. It should be easy to understand and contain enough details for developers.

When creating a bug report, testers sometimes make mistakes that complicate fixing the problem and interacting with developers. The most common mistakes are listed below:


Lack of steps to reproduce a bug: It is imperative to describe the steps that led to the bug's reproduction. With this information, developers can reproduce the problem and, accordingly, fix it. 


Lack of visualization of the bug: The lack of screenshots or other images that illustrate the problem makes the bug report less informative. Visual content helps developers better understand the essence of the problem. 


Missing expected and actual results: Describing expected results and comparing them with actual results helps developers understand the differences that caused the bug.


Lack of technical information about the environment: Information about the operating system, application version, browser, hardware, and other technical details helps developers reproduce the conditions in which the problem occurred. 


Lack of alternative solutions or recommendations: Testers should not only identify bugs but also, when possible, suggest alternative ways to solve the problem or provide recommendations for improvements. 

In the realm of software testing, knowing how to report a bug effectively is crucial. To create an effective bug report, avoiding these mistakes and providing as much information as possible can simplify bug fixes and facilitate collaboration with developers. Understanding the intricacies of how to report a bug in software testing not only ensures clear communication but also accelerates the resolution process. Discover the importance of software testing and how it can benefit your project's success.


In this article, we've delved into the essence of a bug report and highlighted the benefits of a meticulously crafted report for the entire team. Recognizing the importance of this skill, we've also created an in-depth guide on how to write a bug report effectively. By exploring examples of both effective and flawed bug report patterns, we've equipped you with a clear understanding of the dos and don'ts. Moreover, you've been introduced to a concise list of best practices to ensure your reports are impactful. We trust this knowledge will serve you well and be a valuable asset in your professional toolkit.
Contact us today to discuss your software testing needs and how we can assist you!

Have a project for us?

Let's make a quality product! Tell us about your project, and we will prepare an individual solution.

Frequently Asked Questions

What if you're not sure if it's a real bug?

It is better to submit questionable information than to miss a real bug. Knowing how to write a bug report effectively can greatly assist testers in this determination. 

Is it necessary to specify the version of the program in the bug report?

Yes, specifying the version of the program helps developers understand which version the problem is related to and whether it has already been fixed. 

How do you choose the proper priority for a bug report?

Use the priority system provided by the developer. As a rule, medium priority is used for standard bugs. After reviewing the bug by the developer or management, the priority may change. 

Why is it essential to include screenshots in a bug report?

Screenshots visualize the problem and help developers better understand the bug. They can be critical to a quick fix. If reproducing a bug requires a lot of steps or more attention, we recommend recording a video, which will make it much easier for developers to solve the problem. 

How detailed should the "steps to reproduce" section be?

Be as detailed as possible. Every step, click, and action taken to produce the bug should be mentioned to help developers replicate the issue.

Recommended Articles