Sometimes I just want someone to give me the information I need…
It is times when I feel like this, that I think about writing bug reports…
As I see it, my job is to report information about potential risks and problems, to ask questions about a product/application/system, and report those questions as bugs, if they seem to be incorrect. However, I add to myself a caveat to this job, with all I can muster up, I don’t want anyone to have to come back and inquire anymore about what I wrote up. I want/strive for my reports to be succinct. I don’t really want to have a bunch of questions coming back at me about them; I am usually on to another area that I need to investigate…
Very rarely will I write a bug report that I cannot stand behind. I may not be able to (nor have the authority to) describe what “should” occur, but I really try to get as much information as I can into a report before I will submit it. What does this usually mean?
Again, I refer back to the journalist in me: who, what, where, why, when, and how…
To me, these are more than a guideline, they are a code. I don’t want someone to have to come back and ask any one of these questions to me. It does happen on occasion, my blog title is my acknowledgement of this: UE: Tester_LostFocus (my own error, unexplained – UE – but I lost focus of my goal in writing or investigating or reporting, I missed my mark).
I spent a great deal of time today in asking questions… I think I have a bit of empathy towards developers who receive less-than-good bug reports… I think I thought of a few new things because of it today…
Not all people can effectively communicate in written language by nature. Some need to practice; others need to find another way. With the technology of today, you can find another way to communicate, or rather ADD to your written communication.
First, be detailed… be “anal” about this… it sometimes makes the difference in whether or not a bug “should” be fixed, or should be set aside. Maybe something “bad” happens only if you do XYZ first, but never does outside of this… And maybe that is not how the application/product/system is used by your customer… or… maybe it is how it is used…
Second, work on these skills… notice what you miss, make sure you strive to NOT miss it next time
Third, remember you are part of a team. You don’t want to make anyone else suffer because you do not give additional information you haven’t thought was important… all the pieces make a puzzle… missing pieces make an incomplete picture. To the stakeholders… time is money… every minute spent chasing down your issue is money not spent on the next cycle of development… If you cannot think of it in terms of development, think of it as your raise for the next year…
Fourth, add a video capture/screen capture if you think your words are not enough… there are lots of apps out there for this, some are built right into testing tools… use them if you have to… don’t “rely” on them so much that you forget you should try to “not” need them…
Your job is to try to ensure no developer ever needs to ask you about your report… but rather to ask about your day, if they happen to have the time….
Your job is to try to ensure that if a stakeholder comes to your department and says, “Why didn’t QA/the Testers find this?” to be able to say, “We did, please see bug/report number XXXXX, but it was decided to not fix this”.
If you are new to this field, I recommend reading about things like: philosophy, psychology, UI, UX, writing, reporting, and investigating. Don’t stick to just software development and how to understand your own PC or the technology of today. It takes this, but it takes more. It takes “understanding” what your goal is…. Your goal is to report information… to the people that matter… in a way… that counts… that gives the most “bang for your buck”.
Note: My definition of a bug comes from my lessons learned through the Rapid Software Testing course… which I hold true to my own convictions… You can learn about that, among other things of value to your testing skills, here:
4 comments:
Michele,
So, I agree with your premise, but I find your implementation to be specific to a particular context.
Personally, I prefer not submitting bug reports *at all* (admittedly that, and what follows, is entirely inappropriate in some... even many... contexts).
Here's how I *like* to do it.
- "Dude! look at this!"
- Collaborative triage ensues
- Decision is made... generally:
o Let's fix that now
o I guess that is correct because...
o Outside scope for this build/release - lets create a work item (story/bug/enhancement) to be prioritized for next build/release
- Move on
In my experience, this is far easier, more accurate, more efficient and less time consuming than starting with a bug report.
Remember, of course, my primary experience is in performance testing. I've written multi-hundred page documents on just the "who" and the "what" for a single test that didn't even come close to containing sufficient information to eliminate questions -- not because I'm a bad writer, because a "typical" test for me involves 5000 "whos" each doing at least slightly different "whats".
For me, the goal is to ID and resolve stuff BEFORE the build is "tagged" for anything other than development. With that goal, I see no more need to report bugs I find than there is to report bugs that the Devs unit tests find.
Scott,
Yep, I admit my implementation was specific to a particular context... In fact, it was my way of kinda getting it off my mind...
And I, too prefer not submitting bug reports at all...
My current project started out pretty much like what you describe... Was the best experience I had - to date - in being part of a team, versus tester (in the more usual role, that is).
When the project got bigger, and the stakeholders wanted bigger/broader things in limited time frames, things changed. In order to make these deadlines, it was decided to go back to writing bugs and dealing with them when/if necessary...
I understood their need to make the changes, after all, successfully meeting deadlines and making our customers happy... in turn keeps the stakeholders happy and allows them to continue to take on new endeavors... which in turn keeps me happy, cause I enjoy what I do.
I do, however, miss how the project originally started out...
Good post, I myself try to work on this and be better at writing bugs so that it is clear for any developer that is working on my bug. I try to be as clear as possible and add all the necessary setup information too.
Hi Jasminka,
Thanks for the comment... I think striving to do your best is an awesome attribute in being part of a team... and the best we can ask of ourselves as well...
Post a Comment