Tosca tester
How to write an effective bug report
Bug identification is crucial in the testing process. When you find a bug in 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.
What is a bug report – description
When abug 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.
Benefits of a good bug report
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 earlier 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 create a really good bug report, start by asking: What is this report supposed to tell the developer? A bug report should be able to answer the following questions:
- What is the problem?
- How can a developer reproduce the problem (to see for himself)?
- 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?
How to write an effective bug report
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 error 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 for some reason. 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 only 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 error 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 error, 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 issue report. When the developers receive the error, 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.’, ‘The suggestion text on the pricing page looks weird and doesn’t seem right. It shouldn’t be that big and should be in a different color.”
3. Steps to reproduce the error
Clearly number the steps from the first to the last so that developers can follow them quickly and accurately and check for errors 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 error message describes how the software is supposed to work in a given scenario. The developer learns from the expected results what the requirement is. This will help him 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 error 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?
- Or is it simply unresponsive?
Specificity of description 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. It displays 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 an error will be “Although the account deletion is confirmed, it is possible to log back in with the account without registering.”
6. Visual evidence of error
Any relevant screenshots, videos or files need to be attached. If the issue requires steps to trigger an error, 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…
7. Severity of the error
Each error shall be assigned a severity level and a corresponding priority. This determines how much the error affects the system and, consequently, how quickly it needs to be fixed. Error severity levels:
- Low: The error will not result in any visible system failure.
- Minor: Results in some unexpected or undesirable behavior, but not enough to disrupt the function of the system.
- Severe (Major): an error that can cause the collapse of large parts of the system.
- Critical: An error capable of causing a complete system failure.
Error priority levels:
- Low: The error can be corrected later. Other, more serious errors 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 errors 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 beneficial.
9. Other fields
The defects 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 -in different stages and states so that we can easily update it. This whole process is also referred to as the life cycle of a defect or bug. Large teams use different kinds of defect management software to make this process easier and more efficient.
Bug report – best practices and tips
In general, it is a good idea to keep these basic guidelines in mind:
- One mistake = one problem. Don’t include multiple bugs in one report!
- Avoid duplication. Always try to search the current issue tracker for existing reports.
- Reproduce it before creating the bug report. This makes it more likely that the developer will be able to reproduce the problem and identify where 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 find 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 automated testing. Selenium automated 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 automated 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 automated tester, take a look at our company benefits and respond to job vacancies.
