Test cases: Difference between revisions
(Copied Zapper's original text here) |
m (just some grammatical fixes) |
||
| Line 8: | Line 8: | ||
===Running test's=== | ===Running test's=== | ||
Some of the test area's will overlap, and | 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 occured 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 | 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 | 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 hard thing to grasp, but if one | 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 of testing will follow the latter of the game. | The latter part of testing will follow the latter part of the game. | ||
*Graphic User Interface | *Graphic User Interface | ||
Revision as of 20:26, 8 August 2009
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 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 occured 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
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
- Game start
- Training interface
- Game Lobby
- LAN interface
- Server Lobby
- New Game settings
- In Game GUI
- Game Settings Menu
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!
Communication
This section is a stub You can help by improving it!
