When a tester logs a new defect/bug, should there be a section on how the Bug impacts the business and how many modules/features it would impact?
Is that a good bug reporting practice?
6 Answers
Yes, there should be some level of impact reporting in all bug reports.
If following ISTQB/ISEB standards then this is accomplished via Severity and Priority measures.
Severity is the functional impact, rated 1 to 5 (1 - Crashes, 5 - Cosmetic issue)
Priority is the business impact and desire to fix it, rated 1 to 5 (1 - FIX NOW!, 5 - Fix it eventually)
Adding these measures in helps those assessing the urgency to fix an issue to determine the full impact of the issue.
For example: We find 2 bugs in an application, both crash the system. Both are therefore Severity 1.
However, if one bug only occurs for clients called Zaphod on the third Wednesday in August....the priority to fix it will be understandably lower due to the fact it is unlikely to occur often.
Assigning priorities can involve a discussion with a Business owner/analyst to ensure that the impact is fully understood and should form part of the defect management strategy.
A classic answer: "It depends"
It depends on how strongly the tester is involved into the development process.
If he knows that the issue affects two different products which are delivered from two separate branches relying on the same implementation, he can state that in his bug report.
A more practical approach would be simply trying to reproduce the same issue in a second product / module / feature and file another bug report.
I think it's fair for QA to enter a bug with what they think the impact/severity of it is. This can easily be updated and over-ridden by someone else downstream (e.g. the person triaging issues, project manager, whatever), but a good tester should have some idea if an issue is a show stopper, if it's going to be a big issue for end users, maybe it's just annoying, etc
As "Joern Boegeholz" said; It Depends.
Usually I prefer to ask my clients (dev team, management, analysts, designers, the client) how much details they want in the bug report.
Many a times people don't really read a whole lot and hence they ask for fewer details, yet if the testers can do Impact Analysis of the Bug and report it in the Bug Report, that's a good help for the developers. It would save some effort on regression testing.
At the end of the day it depends on the then situation and requirement!
answered Jan 30, 2016 at 3:07
Well, entering the impact are can be good for you, so that next time you retest the fixed issue, it will help you in regression of connected modules. but otherwise developer will not get much help from it. And in general it is not listed as part of bug report.
Bug report should have details about current issue, steps to reproduce, test data etc. As developer most of the time prefer to reproduce the scenario. also as suggested, if other area is getting impacted because of this issue, that is obvious and get sorted out with fixing of this issue.
And in case other effected module has issue even after fixing of current issue, you can log the bug then as part of regression. I believe that will be more right approach.
It depends on what is done with the information.
For example if the bugs are reviewed once a week, saying during Agile sprint review and the tester isn't present, it can be useful information in determining its priority relative to other bugs and tickets.
In an Agile environment you should minimize the documentation in favor of conversations. For this reason I like the testers and developers to all be in sprint review. It's also very empowering to them and gets them much more involved generally.
When done, my recommendation is to make it brief and describe the business impact. For example "unable to complete reservation", "unable to see q&a section", etc. I would not expect the tester to be confident in knowing the modules affected without the rest of the team.
answered Mar 10, 2016 at 3:42
