Guess who.'w' Thought it was a good idea to start this topic. I'll be giving the game a go and post again if I find anything.
Tips : How to write a good Bug Report
Anybody who has written software for public use will probably have received at least one bad bug report. Reports that say nothing ("It doesn't work!"); reports that make no sense; reports that don't give enough information; reports that give wrong information. Reports of problems that turn out to be user error; reports of problems that turn out to be the fault of somebody else's program; reports of problems that turn out to be network failures.
I'll try to state clearly what makes a good bug report. Ideally I would like everybody to read this before reporting any bugs. Hopefully that will make things easier :)
In a nutshell, the aim of a bug report is to enable the programmer to see the program failing in front of them! You can either show them in person, or give them careful and detailed instructions on how to make it fail. If they can make it fail, they will try to gather extra information until they know the cause. If they can't make it fail, they will have to ask you to gather that information for them.
- In bug reports, try to make very clear what are actual facts ("I was at the computer and this happened") and what are speculations ("I think the problem might be this"). Leave out speculations if you want to, but don't leave out facts.
- Tell them exactly what you did. Which buttons you pressed and what order you pressed them in. If it's a bug that happened after typing something, show them precisely what you typed.
- Sometimes the fault doesn't show up on every computer; your system and theirs may differ in some way. Remember to give your specs if something still doesn't work.
- If you saw error messages then tell the programmer, carefully and precisely, what they were. They are important! At this stage, the programmer is not trying to fix the problem: they're just trying to find it. They need to know what has gone wrong, and those error messages are the computer's best effort to tell you that.
- In particular, if the error message has numbers in it, do let the programmer have those numbers.
- Be specific. If you can do the same thing two different ways, state which one you used.
- Be verbose. Give more information rather than less.
- 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.
- As pointed out below, it would be nice of you to warn about typos too. ^_^
When an antelope is confronted with something unexpected or frightening, it freezes. It stays absolutely still and tries not to attract any attention, while it stops and thinks and works out the best thing to do. If you stumble upon a bug, keep calm and take note of what happened so far. If you close error messages too fast you may miss important information necessary to fix the bug...! x_x
Remember, if you're playing the beta safe often..! *chuckle*
Hope this was helpful...! Have fun playing! XD