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?
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Blog Archive
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
If describing the solution (over and above the steps to reproduce the problem) means explaining the intended behaviour as against actual flawed behaviour I would say the defect management tool should include such comments from the tester and as you mentioned by wording it appropriately. As is words and appropriateness of it is a universal must-do not limited to defect management, isn't it.
Without knowing the specifics of your bug and looking at it from here it seems a modification of the bug description (via a revision history) rather than rejection would have been the way to go...
I think the testers are budding business analysts which most developers tend not to be (considering their job responsibilities especially for large applications where her/his focus is limited to development/ maintenance of a module or two). This means that the tester should use the near considerable (expected) application knowledge at her/his disposal and suggest (vehemently at times) how the functionality ought to be. This is a service which needs to be acknowledged by all & sundry including the developers. The tester's knowledge would fall short of expectations at times and maybe overruled by the developers, business analysts or even the customer. This to a tester must not be a deterrent but an acceptance of human failing with the incentive of the knowledge becoming more wholesome...
Sandeep,
Sounds like you’re saying there is value when testers add non-problem-related info to bug reports. I agree. However, one advantage of keeping the "initial" bug reports as concise as possible is getting your main point across.
This can be understood by looking at a non-testing analogy. Have you ever received a response to your email where the responder appears to have ignored some of the email’s info? Maybe you send an email that asks:
“What is your favorite color? What kind of music do you like? What is your salary?”
The response may be “It is not appropriate to ask me my salary. It is none of your business…etc.”
The responder is so distracted by the salary question, they don’t respond to the first questions. I find it irritating but I’ve noticed I can get more info by only asking people to focus on one idea at a time.
Eric, Guess I was not clear enough and hence you misread my thoughts. The bug description must describe the bug fully and properly in all its ramifications. Period. Extraneous information (unrelated to the bug) would confuse matters - I agree.
The bug must be explained clearly with the help of screenshots/other evidences as gathered by the tester. Details *as relevant* is required since being brief and then exchanging to&fro notes may impact resolution of the bug per se and even cause loss of historical bug data which is valuable even from an analysis perspective.
Ah, yes. I'm with you. Once we get the initial bug understood and accepted, we can probably add all the discussion stuff afterwards.
Yap, it happened to me too. My reported bugs got rejected, I thought those were important! Reading your post, actually I got some thoughts in my mind.
Example you provided first, in Actual Results, I think portion B because D needs to be used to determine E, F, and G is pretty much okay! If you are sure that this is reason for which there is variation between Expected Results and Actual Results, then you've done well by mentioning this. Because it'll let the dev to investigate quickly.
I was wondering that why the bug got rejected! Because there my other path through which this result may occur. Do you got clear information about the investigation the dev did about this bug? I am just asking this because as a tester I think I should get detail explanation before If any of my bug got rejected so that I can be sure that yep the investigation was proper!