If you want to write (or find) a guide to effective bug reporting in a style similar to ESR’s How To Ask Questions The Smart Way ,then this article is for you.
Effective bug reporting
I would say that depends on your team/organization. However, just to keep in mind you can take a look of:
- Wikipedia Bug Report Template
- Apache Bug Writing Template
- Apple Bug Report Sample
- You can find the same on any other OS project.
Adding more info extracted from here:
If you can do the same thing two different ways, state which one you used. “I selected Load” might mean “I clicked on Load” or “I pressed Alt-L”. Say which you did. Sometimes it matters.Be verbose. Give more information rather than less.
If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. One bug report I received was a single sentence; every time I asked for more information, the reporter would reply with another single sentence.
It took me several weeks to get a useful amount of information, because it turned up one short sentence at a time. Be careful of pronouns. Don’t use words like “it”, or references like “the window”, when it’s unclear what they mean. 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.
Read what you wrote. Read the report back to yourself, and see if you think it’s clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.
I would say, that as a must you must provide a description, severity, steps to reproduce and status. Then you can change some flavors, by adding tags, affected version, assignee, etc.
- Step-by-step instructions on how to recreate the bug
- Make sure you’ve attempted to isolate the bug to what you are actually writing a bug against, instead of something else that could be the cause.
- List attempts to isolate the bug to something other than the software you are writing a bug against
- Make yourself available to answer questions and be available to help troubleshoot/recreate the bug
The bottom line is you have to engage some level of critical thinking when the bug is encountered. Once you’ve exhausted all possibilities that it could be your fault, write up a bug. If you find out its your fault, but the software you are using/testing could have done something more usable to indicate its your fault, still write a bug.
Also, to be a truly great bug-reporter, you must avail yourself to those testing the bug to help them recreate it. Its likely you’ve just “got the knack” for recreating that bug and there may be steps you are not conscious of. You can’t just complain and walk away, participate in the process and help the team out by testing, recreating, and troubleshooting.effective bug reporting . effective bug reporting