Summary: This article focuses on the significance of crafting informative and actionable bug reports, highlighting key elements such as clear communication, detailed descriptions, structured titles, concise steps, expected outcomes, attachment usage, and maintaining positive communication with developers.
What is a bug report and why do we write them?
Writing a good and actionable bug report is one of the most important skills within the testing world. Creating a well-written bug report is truly an art that requires a combination of testing experience and good communication skills. This article provides insights, advice and tips helping you create bug reports that are informative and actionable, thus improving their value for those who end up solving the bugs.
What makes a bug report good?
Clearly said, what does a developer need to have to get a clear view of the problem you (as a user) have encountered. This includes all the ins and outs, steps undertaken and variables that can be of relevance to the developer. These can vary per project, sometimes technical detail of the hardware used is needed, in some cases of for example a SaaS tool the browser and version of the browser has more relevance to the desired output.
Good bug reports are in one word: Informative. The report describes in near perfect detail what happened, and how the incident was created. Written in a clear and understandable way with actionable steps ‘walking someone through’ the path that leads to an error.
However a “good” or valuable bug report needs to take it up a notch provide useful information in an efficient way. To help you get started writing valuable bug reports, there are some key areas to put your focus on:
The Title
A good title helps reduce duplicate issues and should quickly summarize the details of the bug. It’s best to avoid generic problems in the title. Often times, bugs are transferred into the developer’s issue management tool (like TestMonitor or Jira for example.) that may contain hundreds, if not thousands, of other issues. Can you imagine yourself trying to search through the database for a specific issue? Be descriptive, concise and use the structure that the team is familiar with. Your bug report needs to survive (and be useful) beyond the current test cycle; a strong title will help it through its journey.
Instead of saying: Problem with ABC component, or ABC is generating an error.
Say: ABC component creates error once the user is attached, or ABC gives an error upon saving attachments.
Actions performed
To be able to reproduce your bug, the developer needs to know exactly what happened while you were testing. Since these descriptions usually contain the most information, it’s important to keep it concise and easy to read. Always keep your steps short and to the point. Depending on the software that is being used for logging and creating bug reports, the issue handler might have other data available to him so write them accordingly.
Expected Result
While testing a tool/application, users and/or testers might have different ideas regarding the result they expected to see. To deliver a full report it could be handy to add what you expected as a result of walking through the steps described. This might be a little cryptic for some, but it could help create a better user experience. Not everything is as logical to end-users as what the developer intended. On the same note, certain parts of applications might be built on a faster pace, where the rough edges are still visible. If you as a tester explain in detail what you would like to see, or what you expected to happen this can clarify and help developers making software more fluid and user-friendly. Keep it short and concise, don’t try to push your personal agenda but look at the expectation from a broader perspective would your expectation add to the overall customer feel?
Attachments
Images are a quick and easy way to add context to your bug. A good thing to do is highlight the area(s) of interest in your image. This way a developer doesn’t have to look through your whole screen to understand what you need. To increase workflow speed attach the image files directly to the bug report. Try to avoid putting them in a Word doc or a ZIP file, this only causes unnecessary extra steps for anyone who wants to view them.
Keeping up appearances with your Developer
If you follow the steps described above, you and your developer will already start having a better relationship. Now that they finally understand the problems you face while working they can start adjusting and improving the software.
A common thing to avoid though is using an overall tone of negativity when reporting bugs. Obviously, everyone is looking for a functional fit for the application. People tend to forget that devs are humans too. Their understanding of ‘robotic’ languages doesn’t make them less capable of showing emotions. Especially if the whole team starts cursing and or taking a negative attitude towards their creation.
Some tips to keep the Development team from screaming “off with their heads!”
Neutralize your bug reports, deliver bad news gently, be fair-minded in wording and implications. Avoid: Attacking developers, Criticizing the underlying error.
10 tips for a good bug report
- Structure: test carefully
- Reproduce: test it again
- Isolate: test it differently
- Generalize: test it elsewhere
- Compare: review results of similar tests
- Summarize: relate test to customers
- Condense: trim unnecessary information
- Disambiguate: use clear words
- Neutralize: express problem impartially
- Review: be sure
Start testing with TestMonitor
