Testing Guidelines

This page contains various guidelines to follow while testing the MV3D software.

General

A common misconception about game qa people is that they sit around having fun playing the game all day. If that's the case, then they aren't necessarily doing all of their job. The job of a game qa person (imho) is to exercise the various features of the game, test the limits by doing unexpected things, test bug fixes, and get as specific as possible when reporting a bug. In the course of doing those things, yes, the qa person will be playing the game, but their job is not necessarily to evaluate the fun aspect of the game.

The people who are supposed to evaluate the fun aspect of the game are the people in the focus groups. They should include a variety of people that are respective of the desired audience for the game. Their job is to simply play the game and answer questions about it.

Exercising Features

To exercise the features of the game, the tester must first know what those features are. These should be pulled from the DesignDocument? or the FeatureSpecifications?. When testing a feature, all aspects of that feature should be tried.

It is important to note that not just new features should be exercised. On a regular basis, regression testing should occur. During this, previously finished features need to be tested in order to ensure that recently added features of bug fixes haven't broken them.

Testing the Limits

This part of testing involves actively trying to do invalid or unexpected actions within the game and making sure that it reacts appropriately. A simple example of this would be entering -1 in a text box that expects a number above 0. Other examples would be jumping off a cliff to make sure appropriate damage is given, attempting to walk through other players or objects, and casting a heal spell on an angry goblin. In some cases, the desired result may not be well defined, or defined at all. In that case, if it is different from the tester's expectation, or causes bad application behavior or inconsistant game state, it should be reported as a bug.

Testing Bug Fixes

When bugs arise, the programmers will fix them. Once they have been fixed, a tester will be assigned to test the fix in order to make sure they have really been fixed and that they have not broken anything else.

Reporting Bugs

The first thing to do when you find a bug is to figure out what you did to cause it. Some bugs may just occur randomly, but the majority of them will have specific causes. Re-run the client after each time you encounter the bug (if applicable) in order to get a clean application state. Copy any error messages (On Windows, they may be in Ogre.log, CEGUI.log, or RunClient?.log). Take screenshots using the Print Screen key. Screenshots will be stored in the mv3d directory as 'screenshot_x.png' where x is a number. Warning: x starts at 0 each time you run the program, so it will overwrite old screenshots without asking.

Once you have a good set of information, you'll want to see if this bug has been reported. At the top of this webpage are two buttons View Tickets and New Ticket. Have a look at View Tickets or {2} to see if the bug you found is listed. If it is, you can certainly add information to it if you have figured out more than what is listed. If not, use New Ticket to create a new ticket.

Make sure to fill in as much detail about the bug as possible, but please try to keep it clear and concise. Please do not change the priority from "Normal." Make sure you have set your settings as well so that the bug is attached to your user and email.

Back to AlphaTesterGuide.