Feed from Testthisblog.com
An important bug got rejected by dev today. It was my fault.
I included an incorrect solution to the problem. Rather than describing the bug and calling it quits, I went further and described (what I believed to be) the right solution. The dev rejected it because my solution was flawed. The dev was correct…a bit lazy perhaps, but correct.
The main purpose of a bug is to identify a problem, not to specify a solution. I think it’s okay for testers to offer suggested solutions but they should be careful how they word the bug.
For example, if tester logs this…
Expected Results: A
Actual Results: B because D needs to be used to determine E, F, and G. Please modify the operation to use D when determining E, F, and G.
Dev may read it and think, modifying the operation to use D will not work…I’ll have to reject this bug. ….um, what about the problem?
A better bug would have been the following:
Expected Results: A
Actual Results: B
Let the dev figure out how to get to A. If you have repro steps and other suitable details, the dev will probably know how to fix it. If they don’t, they know who to ask for assistance. It may even be the tester!
Am I right?
Loading ...