Finding and Reporting Bugs

If you are testing HoverRace, it is inevitable that at some point you will come across a bug. At this point, you should file a ticket so that the developers can figure out what it is and try to solve the problem. However, you will need to report some information about your setup and about the bug so the problem can be narrowed down well.

Types of bugs

Bugs you may or may not find can be split into a couple of categories:

• Debug ASSERTs - the code is full of ASSERT(FALSE) statements, which throw errors when they are reached.

• Reproducible consistent crashes/errors - this is where you can reliably crash the game or cause an error by doing a specific set of actions

• Random crashes/errors - these are the hardest type to troubleshoot, as they cannot be reliably reproduced.

Debug ASSERTs

You will only find these problems when you run a Debug build of HoverRace. When one of these errors is reached, a dialog will pop up, giving (among other things) a filename ending in .cpp or .h and a line number right next to it (i.e. SoundServer.cpp:502 or something similar). When you write your bug report and file it as a ticket, make sure that you include this information, as it is the most helpful towards solving the problem.

Some ASSERT() statements found in the code do not denote critical errors but instead function as warnings; therefore, some ASSERT errors you might get will not be present if you were to run a Release build of the code.

Reproducible consistent crashes/errors

When you report an error like this, it is very useful to include your system specifications as well as any other possibly relevant information in the bug report. Based on what you report, it is most likely a developer will try to reproduce the problem. Screenshots, video captures, and audio captures or anything else that might be relevant can also be helpful in troubleshooting these issues.

Random crashes/errors

As mentioned earlier, these are the hardest bugs to find and troubleshoot, mostly because it is difficult to report them well. Usually a large part of solving these bugs is developing theories on how the bug can be reproduced. #12 is a good example of one of these bugs. Of course, reporting everything you possibly can that you think might be relevant is very helpful in solving these bugs.

Useful Software

There are a number of applications that can make obtaining data about a bug easier:

• Fraps - a video capture program that can be very useful in making videos of incorrect program behavior or crashes

That list isn't very long, but it's mostly because nobody who's worked on this page has thought of anything other than that.