Two days ago I logged a slam dunk bug. It was easy to understand so I cut corners; skipping the screen capture and additional details.
Yesterday a dev rejected said bug! After re-reading the repro steps, I decided the dev was a fool. However, a brief conversation revealed that even a semi-intelligent being (like a dev) could justifiably get confused. That’s when it hit me. If someone doesn’t understand my bug, it’s my fault.
Most testers experience the AUT via the UI and what seems obvious to the tester may not be obvious to the dev.
So if the dev is confused about your bug, it’s your fault. Graciously apologize and remove the ambiguity. Remember, we’re not dealing with people. We’re dealing with devs.
11 comments:
Subscribe to:
Post Comments (Atom)
RSS
For you oh master of all semi-intelligent beings (like us devs):
Eric is Special!
"Remember, we’re not dealing with people. We’re dealing with devs."
Well said, Eric. Devs aren't exactly people. They are super human beings, right below the word deity in the dictionary. Whereas, QA is a quack and right next to the word quack in the dictionary. What a coincidence.
Sometimes it's not the tester's fault. I came across a bug report which a dev had marked as "Can't replicate". I checked the details, the environment, the steps, etc and was able to successfully replicate the bug. It was crystal clear and I wasn't even part of their development team.
Sometimes if the dev is confused about your bug report, I think he ought to read it completely and thoughtfully before dismissing it.
It's a good thing to admit your mistakes or shortcomings. But you don't always have to apologize when your dev is not as smart or as quick thinking as you.
Green2,
Are you a dev? Nice comments.
I agree. I guess I'm just saying we should keep our readers in mind while writing bugs. These may be business people too, which complicates it slightly. They like the business domain language, which devs don't always care or understand.
Crayons can code 2,
Thanks for the uplifting post.
I decided to return the warmth.
Bravo well done on the comeback :)
*golf clap*
Also whomever posted the 2nd anonymous comment is AWESOME! Eric, seems like you're making a lot of friends out there in non-meat space.
Although I'd reserve the "quack" reference to pertain just to Eric. I love everyone else in QA.
I agree with Eric that sometimes cutting corners in the bug report happens. No one is perfect and when dealing the magnitude of bugs sometimes steps details are reduced to one liners cause the writer (QA) is assuming that reader (Dev) is already in context. For crying out loud they are the ones that wrote the piece of functionality. The fact that hold handing occurs just boggles my mind sometimes. Dismissing a bug as "Can't replicate" during a crunch time tells me that "I'm too busy to figure this out ... back to you".
my 2 cents
qualityfrog twittered your post and I too applaud with the 'golf clap', been there once or twice myself in haste and really the extra time spent on a complete bug explanation is well worth it when compared to the days of delay for follow-up with dev when they ditch it because they didn't recreate it or didn't understand.
You rocked this post. Thanks!
I'm a tester (with a habit of reviewing other people's bug reports :p). I think it should be a two-way thing. As a tester, as you've said, we have to have the reader in mind and try to make the bug report very clear. Our devs should also put in the effort to read the report without being too hasty.
Nice blog, btw ^_^
Liked your comeback, Eric, but to suggest that what crayons is doing is even remotely akin to TDD is laughable!
;)
I know it's an old post, but this give me a chance to state one of my all-time favorite sayings. This would apply to software testing, talking with your spouse, ordering a meal, anything, anytime, anyhow.
"The responsibilty for clear, unambiguous, understood communication lies solely with the sender of the message."
In this case, it doesn't relieve the dev of the obligation as a team member to try to figure out what you meant