Test cases

From FreeAllegiance Wiki
Revision as of 09:35, 7 August 2009 by Imago (talk | contribs) (Copied Zapper's original text here)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Testing FAZ beta is about making sure that there are no technical bugs or gameplay related features in the code that dont comply with the overall functionality of the game.

The technical bugs can be faulty graphics rendering, actions that cause a crash of the client or faulty interface handling.

The gameplay related errors could be that you cant do things which was possible in a earlier release, such as Autopilot not working when you are podded or that you in fact is podded when the game settings allow you to.

We will try and get around all the general areas of a FAZ beta test.

Running test's

Some of the test area's will overlap, and thats not bad, its what make these test's important. Each area will have its own pages to avoid the tester's making shortcuts, eventually mature testers will do just that to cut down on the test cases needed for a full test, but they will also be ridiculed for missing out on simple errors they might have found if they had run the test without shortcuts.

The test cases or test list's is your friend it helps other's to understand where is the test process there was a error and how to reproduce it. To be able to pinpoint where in process the error occur is crucial when we communicate across the Globe, even when we have the internet we don't expect that everyone are online 24/7, so the test list and test cases are like a substitute for our actions and can stand in when we are offline.

Addition to testcases are welcome, some testcases or testlist may even split up into several sub-test inorder for the work to be spread out so we dont sit with a humungus testcase that totally kills the drive of the individual. Some test may even be so complicated that they need to be dissected into several small test, so they dont stop the flow of the process.

So dont hold back if you got new idea's on how test's should be conducted or just if you want to split up a testcase inorder for it to be more easy to handle, after all if the testcase is huge its also huge to debug, and developers hate to debug huge testcases.

WARNING: testing can be hard thing to grasp, but if one try and narrow down the area of the test it will become easy to do.

The latter of testing will follow the latter of the game.

  • Graphic User Interface
  • User Controls
  • Rendering of Graphics
  • Sound Playback
  • Communication

Graphic User Interface

Graphic user interface is also called GUI, this is the first area a player will encounter when he starts the game.

This test is easy and trivial, the test on this area is about pushing buttons.

Its divided into different parent GUI's

User Controls

Edit.png
This section is a stub You can help by improving it!

Rendering of Graphics

Edit.png
This section is a stub You can help by improving it!

Sound Playback

Edit.png
This section is a stub You can help by improving it!

Communication

Edit.png
This section is a stub You can help by improving it!