Tosca tester
How to write an effective bug report
Bug identification is crucial in the testing process. When you find a bug during testing, it is essential to report it so that it can be fixed. Writing a bug report is therefore a key phase of the bug lifecycle, which comes as soon as the bug is identified.
Bug report description
When a bug is found during the quality assurance process, it must be documented and sent to the developers for correction. Because software in today’s digital environment is extremely complex, multi-layered and full of features, most testing processes generate multiple bugs. In addition, developers often work on multiple development projects simultaneously, which means they have a significant number of bugs that require attention. They have to work under considerable pressure and without the right resources, they can be overwhelmed. IT testers naturally spend considerable time researching how to report bugs in a way that benefits developers and helps them troubleshoot bugs quickly and efficiently. One such resource is well-structured and reasonably detailed bug reports. Good bug reports tell developers exactly what needs to be fixed and help them do it faster. This prevents delays in software releases and offers faster time to market without compromising quality.
Good bug report benefits
A well-written bug report contains all the important information that can be used in the debugging process:
- It helps in detailed analysis of the error.
- It provides a better overview of the bug and helps to find the right direction and approach to debugging.
- It saves costs and time by helping to eliminate errors at an early stage.
- It prevents bugs from getting into production and disrupting the end-user experience.
- It acts as a guide to help avoid the same bug in future versions.
- It informs all stakeholders of the error and helps them take an action to fix it.
Elements in a well-written bug report
When learning how to write a really good bug report, start by asking: what is this report supposed to tell the developer? The bug report should be able to answer the following questions:
- What is the problem?
- How can a developer reproduce the problem (to see for themself)?
- Where in the software (on which web page or in which function) did the problem occur?
- What is the environment (browser, device, operating system) in which the problem occurred?
Effective bug report structure
An effective bug report should include:
- Title/Bug ID
- Environment
- Steps to reproduce a bug
- Expected result
- Actual result
- Visual proof – screenshots, videos, text
- Severity/Priority
- Logs from the console
- Other fields
1. Title/Bug ID
The title should serve as a brief summary of what the bug is. Report titles begin with the underlying feature issue in parentheses at the very beginning of the title. Assigning an ID to the bug also helps make it easier to identify. For example, “[APP] enlarged text in the FAQ section of the home page <name>”. Wrong: “When I add a product, I don’t see it in the cart. WHY? Please fix this as soon as possible.”
- unclear
- aggressive
- asks for the implementation of a solution
2. Environment and description
The environment for each application can vary greatly, but be as specific as possible. Unless otherwise specified, testers should always follow a given bug reporting template – this helps limit the amount of unnecessary information. A bug may appear in certain environments and not in others. For example, an error appears when launching a web page in Firefox or an app doesn’t work properly when launched on iPhone X. These errors can only be identified by cross-browser or cross-device testing. When reporting a bug, testers must indicate whether the bug occurs in one or more specific environments. Use the template below to be more specific: .
- Environment: DEV, TEST, PROD (production environment), BETA
- Device type: hardware and specific device model
- Operating system: name and version of the operating system
- Software version: the version of the software under test in which the bug appeared.
- Connection strength: if the bug depends on the internet connection (4G, 3G, WiFi, Ethernet), indicate the strength at the address at the time of testing.
- Reproduction rate: number of repetitions of the bug, indicating the exact steps for each repetition, e.g. 5/5
- Account used: this is important if the client provides test accounts to the testers. It is then best to include email + password in the bug report. When the developers receive the bug, they will understand which account was used to detect the issue.
Bad example, “Last time I tried to add things to my cart and nothing showed up when I did that or clicked a button.” or “The suggestion text on the pricing page looks weird, doesn’t seem right. It shouldn’t be that big and should be in a different colour.”
3. Steps to reproduce the bug
Clearly number the steps from the first to the last so that developers can follow them quickly and accurately and verify the bug themselves. Here is an example of how to reproduce the bug in steps:
- Go to settings > Profile (this will take the user to a new screen)
- Tap More Options > Remove Account
4. Expected result
This component of the bug report describes how the software should operate in a given scenario. The developer learns from the expected results what the requirement is. This will help them to assess to what extent the bug disrupts the user experience. Describe the ideal end-user scenario and try to provide as much detail as possible. In the case of the example above, the expected outcome should be as follows: “Your account has been deleted.”
5. Actual result
Describe in detail what the bug actually does and how it distorts the expected result.
- Elaborate the problem
- Is the software crashing?
- Is it just a suspension?
- Is there an error shown?
- Is software simply unresponsive?
Concreteness in this section will be most helpful to developers. Highlight what is going wrong. Provide additional details so that they can begin to investigate the problem with respect to all variables, such as:
- “The link does not lead to the expected page. There is a 404 error.”
- “When you click the button, nothing happens at all.”
- “The main image on the homepage is distorted on a particular device and browser combination.”
Continuing with the above example, the actual result in case of a bug will be “Although the account deletion is confirmed, it is possible to log back in without registering.”
6. Visual evidence of bug
Any relevant screenshots, videos or files need to be attached. If the issue requires steps to trigger the bug, a video is required. If the bug is, for example, a minor UI issue that is always present, then a screenshot will suffice. Regardless of the issue, logs are also required. For application crashes, both system logs and crash log dumps are required, otherwise developers will be looking for a needle in a haystack. When testing with BrowserStack, multiple debugging options such as text logs, visual logs (screenshots), video logs, console logs, and network logs can be used. The range of debugging tools offered by BrowserStack’s mobile app and website testing products is as follows:
- Live: pre-installed developer tools on all remote desktop browsers and Chrome developer tools on real mobile devices.
- Automate: screenshots, video recording, video synchronization, text logs, network logs, Selenium logs, console logs.
- App Live: real-time device logs from Logcat or the console.
- App Automate: screenshots, video recording, text logs, network logs, Appium logs, device logs, etc.
7. Bug severity
Each bug shall be assigned a severity level and a corresponding priority. This determines how much the bug affects the system and, consequently, how quickly it needs to be fixed. Bug severity levels are:
- Low: the error will not result in any visible system failure.
- Minor: results in some unexpected or undesirable behaviour, but not enough to disrupt the function of the system.
- Severe (Major): a bug that can cause the collapse of large parts of the system.
- Critical: a bug capable of causing a complete system failure.
Bug priority levels:
- Low: the error can be corrected later. Other, more serious bugs have priority.
- Medium: the bug can be fixed during normal development and testing.
- High: the error must be resolved as soon as possible because it negatively affects the system and makes it unusable until it is fixed.
8. Console logs
These logs show developers any bugs that have occurred on a given web page. The logs may also contain information that tracks certain user actions. In general, developers may find the inclusion of console logs useful because it can help them dig deeper into a problem and identify its root cause. When debugging, this will save them a lot of time with any problem. Many application crashes or bugs are difficult to replicate, so having logs available can be mitigating.
9. Other fields
Bugs are not static. Nor do they just all fit into one cluttered group. We need a way to keep track of the history (who reported the issue, who updated it, who will fix it, etc.). We also need a way to understand what feature areas the bug affects (feature area, module, business area, etc.). Therefore, bugs can and do have the following additional data fields:
- Reported by
- Report date
- Assigned
- Status
- Module/area of activity
These fields help in tracking the bug at different stages and states so that we can easily update it. This whole process is also referred to as the life cycle of a bug or fault. Large teams use different kinds of bug management software to make this process easier and more efficient.
Bug report best practices and tips
In general, it is a good to keep these basic guidelines in mind:
- One bug = one problem. Don’t include multiple bugs in one report!
- Avoid duplication. Always try to search the current issue tracker for existing reports.
- Reproduce the bug before creating the bug report. This makes it more likely that the developer will be able to reproduce the issue and identify how it originated.
- Don’t forget KISS: keep it stupid simple. Keep everything as simple as possible. Using bullet points or numbered lists can help.
- Use a professional bug tracking tool. It will help you keep everything in one place and avoid losing files and bug reports.
- Be kind. Developers are human too, and mistakes happen. They are part of the process of creating great end products and websites.
Testing on devices
Needless to say, without testing on real devices, it is impossible to detect all possible bugs. In addition, it is necessary to know how often the bug occurs and what is its impact on the software. Testers cannot report bugs that they did not catch during testing. The best way to detect all bugs is to run the software on real devices and browsers. Ensure that the software is run through both manual testing and automation testing. Selenium automation testing should complement manual testing so that testers don’t overlook any bugs in the quality assurance process. If you don’t have your own device lab, the best option is to choose a cloud-based testing service that provides real device browsers and operating systems. BrowserStack offers over 2,000 real browsers and devices for manual and automation testing. Users can sign up, select their desired combinations of devices, browsers and operating systems and start testing. The same goes for apps. BrowserStack also offers real devices for mobile app testing and automated app testing. Simply upload your app to the desired device-OS combination and check how it performs in the real world.
If you speak German and are an IT tester or IT automation tester, take a look at our employee benefits and respond to our job offers!
