Bug Reports II
During my time in QA I have encountered numerous ways of reporting a bug. Be it from beta testers or from external parties that claim to have done QA before. No matter how experienced the bug reporters are – the bugs look similar, in general. 90% require more information on the problem encountered. Be it place, time, the exact matter of the problem encountered, there is always something missing and requires further inquiries and therefore time. These bugs do not make life of QA easier and are not always worth the time that has been invested into finding out more on the issue. Sometimes, and this is not surprising, the users themselves are the main source of the “bug” they have encountered.
This is not only the case when it comes to “professional” QA, though. Even with non-commercial projects, services and even blogs it can happen from time to time that people, who are using these services/project/blogs, encounter a problem of some sort. Either, they cannot use it properly and do not know how to, some technical issue gets in the way of using the service or the user is lost in options and new media and needs a helping hand to guide them through the numerous links and options available.
If this is the case and the user needs to contact someone who seems to be in charge there is always the quick and easy way to solve a problem, and then there is the other way. As you may have guessed, 90% take the rather hard and time-consuming way and if things get rough the solution to their problem stays in nirvana – forever.
The easy way would be to provide as much information as possible. Granted, if it is a non-commercial or private service changes are high that the user at the other end knows just as much as the user with the problem and cannot provide much help but will try to do so anyway. In the best case someone who knows about this issue is contacted and valuable solutions for the problem are shared. Worst case – the providing user admits he or she is just as clueless and cannot provide any help. Whatever case may be – it is always good to provide in a very detailed manner what the exact problem is, when it occurred, where, what was done before and what happened after, what it should have done in the first place, the software that is being used, etc. Anything and everything can be helpful (except, of course, the color of socks being worn at the exact time the problem occurred).
The hard way is to be as vague as possible:
“This does not work.”: A good start but if it is also the end of information there is not much that can be done except ask more questions and hope that useful answers are given.
“I can’t do that.”: A tricky one. Is it a complaint about the service not working or about the inability of the user.
“This sucks.”: This may very well be spot on but offers not enough information to improve the product/service/etc. How does it suck, when does it suck the most, what does not suck? As long as the product referred to is a vacuum cleaner there is not much that can be done (and if it is, in fact, a vacuum cleaner, this is good news!).
What may not be that important when it comes to reporting bugs in a professional manner and environment is style and register that is being used. Provide enough information, be as exact as possible, as detailed as possible and do not waste space and time with lengthy behind-the-scene stories. There is also not much need to be as polite as possible. This does not mean that being rude is the way to go, after all, the bug will be forwarded to a human being who is working on the product. Keeping that in mind is the way to go. Neutral and informative – can’t go wrong with that.
This is not the case when contacting people who are using their free time on some service/product/etc., do not get money for their energy invested and are, as above, human. While trying to make sure to provide as much information as possible on the problem that you want to see solved try and be as polite as possible. Let us scratch the “as possible ‘ – try and be polite.
In the end, not being polite might mean that the solution, that is out there, will never be communicated.
Filed under: Game Related, Private, QA | Leave a Comment
Tags: beta tester, bug, but, commercial, informative, non-profit, Private, problem, product, QA, service, solution, solutions