As somebody who has done a smattering of QA work in the past and as a programmer myself, I see a lot of posts that, while not unreadable by any means could use improvement. With that in mind, I decided I would try to write out a few tips for making bug reports easier to understand, find, and ultimately get fixed presented in a nice simple tl;dnr version followed by a more in depth explanation. This is not intended to replace the SD bug reporting guidelines post which outlines several steps you need to take, but rather a more general style and good practice guide.
This being said, I am far from being a QA expert. My experience was limited to non-critical tool testing for a small linguistics company as part of my miscellaneous things to do as an intern so any suggestions, critiques, additions, copy-edits, etc. are more than welcome. I will try to add more as I notice or think of things. I will attempt to give credit to internet sources used as inspiration or reminders at the end of this post.
Consider this: "I started FooApp. It put up a warning window. I tried to close it and it crashed." It isn't clear what the user tried to close. Did they try to close the warning window, or the whole of FooApp? It makes a difference. Instead, you could say "I started FooApp, which put up a warning window. I tried to close the warning window, and FooApp crashed." This is longer and more repetitive, but also clearer and less easy to misunderstand. (Chiark)
edit notes: Trying to get the whitespace to "stick", not having any luck with the rich text editor and my html experience is a little too outdated. I'll make this post more readable at some point if I can.
Hear, hear!
There are many great features available to you once you register, including:
Sign in or Create Account