Defect report, issue report, bug report
Regardless of what you call it, the bug report is a useful tool in IT projects. To be more specific, a bug report is a powerful instrument that, when used correctly, can yield excellent results.
I’m only trying to emphasize that it’s the tester who produces the report, not the report itself, that makes a bug report effective.
So, how can you write a bug report that is effective?
That is exactly the question we will address today.
We’ll go over the ten things you should ask yourself while writing a bug report. These ten questions will assist you in writing an excellent bug report. They’ll also make it easier for your coworkers to get the most out of your bug report by providing clear and actionable information.
Let’s get started and see how to write the gold standard of bug reports. More information on bug report templates and examples may be found here.
#1: Is that really a bug?
Yes, you’d be shocked how many times simply asking this question may have saved a tester’s blushes.
“It Isn’t the Report That Makes a Bug Report Effective; It Is the Tester Who Writes It.”
When you find a defect, you must compare it to Something — ‘the need.’ There’s hardly much room to stand on if the need doesn’t match your definition of a defect, is there?
While both the “anticipated result” and the “actual result” are useful indicators of what you’re testing for and what you see in practice, the “expected result” must be based on concrete, stated criteria.
There are always exceptions to the rule
As gatekeepers for product quality, testers are tasked with going above and beyond the call of duty to detect issues that aren’t backed up by requirements.
Minor instances include finding formatting problems, copy issues, or incompatibilities across two different travel pages.
Major instances include the gaping issue that one of my testers discovered just days before delivering a major internet banking upgrade:
My client commissioned a series of releases as part of an upgrade from a traditional internet banking system to a newer platform, moving historic functionality page by page onto the new platform and giving users with a few new features every 6 to 8 weeks. A client information update page was one of the functionalities that was relocated.
Functional requirements were written, user stories were developed, old and new pages were compared for gaps, test cases were planned and signed off on, and they were executed, passed, and the test results were accepted. Surprisingly, we had a 100% pass rate for that specific version, which featured this functionality as well – a feat never before accomplished.
Then something unexpected happened. One of my men began exploratory testing the feature on a production server that had not yet been exposed to customers in the days coming up to the release. This phase is more of a health check to ensure everything is working well in production before pushing it to a customer-facing server.
While the functionality worked as intended from the customer’s perspective, the tester discovered that non-functional needs for reporting exceptions to a back-office operations team had not been considered. While a client may receive a success message for every personal information update, they initiated online, an exception could be issued for a variety of reasons, referring the customer’s update request to the operations team.
“Of all the things you can do right in a bug report, the title is the one thing you can do right the most.”
Exceptions were received by the operations team, such as a report prepared overnight and submitted to a team inbox. There was only one problem: the report was no longer being generated.
If you’ve ever worked with or for a bank in any capacity, you’re well aware that this could result in a breach of the bank’s service level agreement (SLA) for responding to customer requests, as well as reputational, regulatory, and financial issues (among others).
Naturally, my colleague brought it up, and we had a long discussion about whether the standards mention back-office reports at all. The requirements obviously didn’t.
There was only one thing left for us to do: remove this functionality from the release in the coming days. Thankfully, this was accomplished by simply reverting to the legacy feature page URL (we hadn’t yet decommissioned it — not until the replacement was up and running).
As a result, it’s OK to submit a bug report that isn’t related to a specific requirement. But you’d best be able to back it up with solid evidence.
If you’re not sure, raise a ‘query’ rather than a bug. You can raise one using almost every testing tool on the market, and then convert it to a bug if necessary. You’ll avoid a lot of heartburn this way.
#2: Is the title/summary of the bug report crystal clear?
Now, of all the things you can do right with a bug report, the title is the one thing you can do right the most.
The ‘face is a window to the mind,’ as they say. Similarly, your bug report’s title/summary is the window through which everyone sees it. For this reason, you want to nail your title.
What is the best way to construct a good title/summary for your bug report?
Remove any unnecessary information:
Any good bug tracking application will give you a plethora of options and customizations to allow you to specify a million parameters for the system, component, function, feature, program, test type, and so on. So, unlike many testers, you don’t want to repeat all of that information in your title.
Keep it brief and to the point:
With just a few words, you can convey a lot. Period.
Be specific:
a developer’s attention will be drawn to a summary that is both forceful and clear. You wouldn’t use the phrase “UX not aligned properly” to describe a high-severity bug that requires quick attention. There could be dozens of other bugs with the same issue and, as a result, the same label. This title, which is the most read section of a bug report, gives the reader enough information to grasp the bug.
#3: What exactly is the bug?
Following on from the title/summary, a bug report’s description and accompanying parameters play a critical part in determining whether or not the report is actionable.
Identify the system, component, program, feature, type of test, environment, channel or device utilized, operating system version, and so on using the parameters. These options allow your team to slice and dice the bug list anyway they like. As a result, you should fill complete the specifications to the best of your ability.
“The Most Read Part of a Bug Report Is the Title.”
It is your obligation as a tester to ensure that the bug report is actionable. Bug parameters are a powerful tool for accomplishing this.
Another way to provide the appropriate level of information about your bug is to use the bug report. Explain how you discovered the bug in the description area, including:
- Steps to reproduce
- Expected result
- Actual result
- Any other relevant information
#4: Is that a known bug?
Check whether the bug has previously been found before filing a bug report that others in your team will spend hours, if not days, trying to fix. This is a reality on projects that offer subsequent releases, especially when the same feature is tested again over numerous releases.
It’s conceivable that a bug was detected earlier and is now being addressed. It’s also possible that the bug was detected previously and downplayed as a one-off, occasional problem.
Whatever the cause, knowing if the bug you uncovered has been found before will be useful. If that’s the case, you have other options:
- Create a bug report and associate it with the original issue.
- If the bug has been discovered in a feature other than the original, confirm that it is a recurring bug that is not limited to a single system or component, and elevate the bug profile.
- If a patch is already in the works, notify the developer so that this occurrence of the bug is covered as well.
#5: Have you tested with the correct version of the software?
We frequently discover that testers used the incorrect version of a browser or program to run a test case. You can’t expect Chrome version 48 to keep your website running well (we’re on version 63 today).
“Ask If the Developer Was Able to Reproduce the Bug Successfully at First Go Whenever You See a Defect That Has Remained Unresolved Past SLA.”
To put it plainly, any issues you uncover when using the wrong version of a browser or program are invalid.
Good test managers collaborate with their project teams to keep track of the tools and versions that are supported. As a result, stay up to date on the proper versions to utilize for any test cycle.
#6: How many bugs are you raising on this report (trick question)?
If the answer is “more than one,” you must break down each bug and create a separate bug report for each one.
To convey the relevance of this one, I don’t think I need to say much. You must make certain A bug report just contains information about the problem. It’s just a bug.
#7: Can the developer reproduce the bug successfully?
This is a critical question, and the answer will largely decide how quickly the bug will be resolved.
The bug report should include all of the necessary details for a developer to reproduce the problem. That means you’ll need to use everything we’ve covered so far to create a detailed bug report that walks the developer through replicating the bug from start.
Remember to inquire if the developer was able to reproduce the bug correctly on the first try whenever you see a fault that has gone unresolved past the SLA.
I’ve seen far too many engineers and testers spend hours, if not days, exchanging messages in order to find the bug’s core cause. This time could have been better spent if the tester had put in the extra effort to ensure that the developer could readily reproduce the error.
#8: Have you assigned the right level of priority/severity?
Is the fault limited to a sub-step of the customer journey that is infrequently utilized or triggered, or does it affect other portions of the trip?
Is the bug affecting the full function or is it simply a cosmetic issue?
What is the risk to the consumer and our business if we have to go live with the bug intact?
How many test cases have been halted as a result of the bug?
These types of questions will aid you in determining the appropriate priority and severity for each bug. A bug report with the appropriate priority/severity assignments will go a long way toward establishing a prioritized pipeline of problems for the project team to address in order.
Note: I know a number of testers who err on the side of caution and label everything as ‘high’ or, even worse, ‘medium.’ The stream of bug reports with the same priority/severity is then ranked and re-prioritized with far too much effort. Don’t get caught in this trap.
#9: Are you presenting facts or opinion?
This is one of the most important questions to ask yourself as a tester while writing a bug report.
Why?
Sticking to the facts can help you write a bug report that is clear and succinct. If you have suggestions for how the product should be planned or created, save them for Retrospectives and other feedback channels that are intended to collect constructive feedback.
The focus of the bug report should be on describing a verified issue with the sole intent of resolving it. There’s nothing else.
#10: Are you writing a bug report or an indictment?
Maybe you and the developer have never agreed on anything. Perhaps the developer has gotten on your nerves a few times. Perhaps the developer went too far and sent you obnoxious emails on the most trivial of topics.
Perhaps you haven’t given much thought to the developer’s ability.
And perhaps you’re frothing at the mouth, ready to exact vengeance for what you see to be a heinous injustice.
I’m not going to pretend to understand how you feel or give you advice on how to get even with this person.
What I’ll advise you is that you shouldn’t take your frustrations out on the developer by filing a bug report.
To say the least, that is unprofessional.
Whatever issue you have with a specific person, your bug report should be flawless and fully factual. Personal remarks or judgments about the quality of the code or an individual should be avoided in the bug report.
Any disagreements should be addressed directly with the individual or their boss, rather than using crucial tools such as the bug report to sting others.
Yes, we see that all too often when people utilize any method available to resolve their differences.
A good tester will be able to rise above such nonsense.
Now It’s Your Turn
The true reflection of a tester’s ability is a high-quality bug report. Every time you create a bug report, you should be proud of yourself.
Remember, a developer is secretly thanking you for providing them the opportunity to repair a bug they may have introduced in the first place every time you record that immaculate, flawless bug report. And your team will thank you for making it easy to fix errors and provide your product to customers faster.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html