Test cases

From FreeAllegiance Wiki
Jump to: navigation, 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.

Testcases are actually a description to reproduce bugs so its imperative that the procedure are fully fledged written, to avoid unknown results that can conflict with intended final result.

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 tests

Some of the test area's will overlap, and that's not bad, it's what make these tests important. Each area will have its own page to avoid testers taking 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 that they might have found if they had run the test without shortcuts.

These test cases or test lists are your friends it helps others understand where in the test process the error was and how to reproduce it. To be able to pinpoint where in the process the error occurred is crucial when we communicate across the Globe, even when we have the Internet we don't expect that everyone is online 24/7, so the test list and test cases are a substitute for our actions and can stand in when we are offline.

Addition to test cases are welcome, some test cases or test lists may even split up into several sub-tests in order for the work to be spread out so we don't sit with a huge test case that totally kills the drive of the individual. Some tests may even be so complicated that they need to be dissected into several small tests, so they don't stop the flow of the process.

So don't hold back if you got new ideas on how tests should be conducted or just if you want to split up a test case in order for it to be more easy to handle, after all if the test case is huge it's also huge to debug, and developers hate to debug huge test cases.

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

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

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

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

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

Rendering of Graphics

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

Sound Playback

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


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


Test Case Template

The following is a template for test cases.

Pictures and screen dumps: Since the wiki don't necessary support upload of pictures or a 3rd party is hosting pictures, please refrain from using this in case the picture is lost.

Test Case Title


Brief description of the test case.

Expected result.

A brief description of the result/outcome for a success. If this contain several result or its is found that are several results of the test, there should be a sibling test cases in order for the result to straight forward and not conflicting with the case.

Dependent test cases.

A list of test cases which this test case can be dependent of.

System requirements.

A list or simple requirement needed for the test to be conducted in a target environment.

Knowledge requirements.

Headsup for the tester, if special requirement are needed for the test to be fully understood or conducted.

Components used for the test.

List of possible 3rd part elements used for the test cases, this could be configuration files or other assets needed for the test cases to be completed.

Procedure for recreation.

The essential step by step run for the test to be completed, if there is a complications or missing step descriptions during the courses of the test, there should be notes regarding this and/or links to test cases that will cover the missing steps or sidetracks.

Associated Test cases.

Links to associated Test cases which have similar functionality or possible opposing test cases. The link can also be test cases which is dependent of this test case.


So if your reading this, you probably broke something, to be sure that you actually broke something during the test, try again and this time notice the "small" detail that lead to the broken "thing" this will come handy when you have to file a bugreport or a ticket as we call it. If the description in the testcase vary don't fit the procedure from which cause the "thing" to break but have relation to the testcase, make a new testcase and add the associated testcase as reference, and make a bugreport with the description from the testcase and reference link to the specific testcase that can reproduce the broken "thing".

On the other hand if you encountered a new bug which dont any description or ticket.. "great" you struck gold and are about to take responsibility for creating a new testcase with procedure to recreate the bug which you encounter.

First things first..

  • Check if the testcase is already made and have a assigned ticket.. there is no need to make a double.
  1. if the testcase is made check if there is a ticket assigned to it.
  2. Go to the ticket list and see if the ticket is made but no testcase is made which fit the ticket description.
  • If the above fit, create a testcase with the testcase template or assign a ticket and link to the testcase in the ticket description, and file it.


A few link to tools which can help catch the anomalies(bugs) or document the testcase description, pictures are always a good way to show the intention of the final result.


opensource screen capture Zscreen

FAZ Development
About Free Allegiance Zone
Releases: R1 · R2 · R3 · R4 · R5 · R6  · (current)R7
Allegiance R8: What's new? · Build it!
Testing Beta: Overview · Testing procedure