Introduction
A successful bug report does more than just tell the developer what went wrong; it highlights the difference between what was supposed to happen and what actually happened. As a tester, it’s your job to get this right, ensuring that the report is clear and informative, which makes the whole process smoother for the development team.
When writing a bug report, there are two key components: actual results and expected results. The actual results are what you observed during the test, regardless of what the software was intended to do at that point in development.
The expected results, on the other hand, represent how the item should behave according to the specifications or requirements. This is the “ideal scenario” that the developer and tester agree on when running tests. While your actual results come from your direct observations, the expected results rely heavily on the documentation you can access.
So, what happens when you’re missing some of that critical documentation? Let’s look at two key situations and how to handle them.
Situation 1: you do not have requirements or specifications
We’ve all been there; testing a feature with little or no documentation to guide you. When this happens, your bug report needs to rely on your observations and your understanding of the ideal scenario.
Here’s where you need to get detailed and clear. You can’t afford vague statements like “The captions should load, but they don’t.” You need to be specific about what the expected result is, even if you don’t have a formal spec to back it up.
Let’s break this down into two possible scenarios you might face:
1.1 What you are presenting is just an improvement of an existing process. This time, it's best to use the word "could":
If the issue you’re reporting is more about improving an existing process (rather than something broken), you can use the word “could” in your expected results. This frames the change as a suggestion or improvement.
For example:
-
Actual result: The app makes it easy for users to accept cookies, but rejecting them is hard.
-
Expected result: The app could make rejecting cookies as easy as accepting them.
The wording here shows you’re suggesting a better experience without saying it’s absolutely broken.
See more: It’s easy to accept all cookies, but how difficult is it to reject all of them?
1.2 The bug behavior is based on industry standards. This time, you need to use "should":
On the other hand, if the bug behavior contradicts industry standards, use “should” in your expected results. This implies that the behavior doesn’t meet the general expectations for how things should function.
For example:
-
Actual result: You can log in as a regular user in the admin section of the product.
-
Expected result: You should not be able to log in with a regular user account to the admin section of the app.
In this case, “should” indicates that the app isn’t meeting basic functionality standards, and it helps the developer understand that this is a more serious issue.
Situation 2: you do have requirements or specifications
f you’re lucky enough to have full access to requirements and specifications, you have a solid foundation for writing your bug report. In this case, the expected results are already documented, so your job is just to compare the actual results with what’s in the documentation.
When you have the proper documentation, your bug report should reference it directly. This can save the development team tons of time by clarifying exactly where things went wrong.
1.3 In this situation, the bug report template involves presenting a link to the existing documentation followed by a screenshot, as shown in the examples below:
1.
2.
3.
Bug Reports as a Communication Tool
In the end, bug reports aren’t just about identifying issues, they’re a primary means of communication between testers and developers. Writing clear, well-structured bug reports can make a huge difference in how smoothly the development process goes.
By embracing standardized bug report templates and industry-recognized formats, you streamline the process, making it easier for everyone involved. This consistency creates a more efficient, informed, and collaborative development environment. And when teams work together in harmony, the software development lifecycle becomes more robust, reliable, and effective.
Stay Updated with the Latest in QA
The world of software testing and quality assurance is ever-evolving. To stay abreast of the latest methodologies, tools, and best practices, bookmark our blog. We’re committed to providing in-depth insights, expert opinions, and trend analysis that can help you refine your software quality processes.
Delve deeper into a range of specialized services we offer, tailored to meet the diverse needs of modern businesses. As well, hear what our clients have to say about us on Clutch!