Silvonis

Welcome to the Project: Gorgon Alpha Test!

Whether you are a seasoned video game tester or if this is your first testing experience, this guide will prepare you for the road ahead!

I. UNDERSTANDING EARLY DEVELOPMENTAL TESTING

What exactly is “early developmental testing” and what are you supposed to do in it? I’ll give you a brief overview of the developmental process and help define your role in it.

A. The Stages of Development

An MMO, like over video games, goes through multiple phases of development before it is ready for final distribution/release.

Pre-Alpha
This is the first phase of the game’s development. Generally, the core systems are constructed at this stage.

Alpha
This if the second phase of the game’s development and this is where most of the game’s content is designed and implemented.

Beta
This is the third phase of the game’s development and this is where most of the core game features have been implemented and it’s time for the development to fine-tune the details.

Release
This is fourth phase of the game’s development and this is when the game has had its core and secondary features added and tuned. The game is ready for launch!

Post-Release Support
This is the fifth phase of the game’s development and it can include the development of new content, patches to fix problems, and the planning of expansion packs and major content updates.

B. Builds

During the early developmental testing phases the game client and launcher will go through multiple build interactions. Essentially, a new build will typically include either fixes to existing game content, tuning of existing game content, or entirely new game content. Usually, it includes all three!

C. Your Role

The role of a tester in an early developmental stage is not to play the game as if it was at the final release stage; but rather, the tester should play the game with the intention of completing all content while documenting and reporting bugs. We also openly welcome your suggestions and feedback! The question then becomes, what’s a bug? I’ll cover that in the next two sections.


II. THE TESTING PROCESS

A. Exploratory Testing

1. What it is?

This is the method of testing where testers are not guided by the development team.

2. How to do it:

There are many ways to go about exploratory testing. Here are some examples:

• Explore all content; don’t play as if the game was released. Do things you normally wouldn’t try!
• Try unconventional gameplay.
• Use everything, everywhere.
• Don’t be afraid to lose or die!
• Test new features and try to get around restrictions.
• Repeat actions, try things more than once!
• The best way to participate in exploratory testing is to explore, try all the content, and do things that you normally wouldn’t try! This isn’t release, there is no end game. Try the wacky combinations, do things that wouldn’t make sense.
• Most importantly, report your feedback and suggestions. That includes any bugs that you find along the way!

B. Directed Testing (Test Cases)

1. What it is?

This type of testing is where the development team has specific areas of the game in mind that they want the testers to focus on. Sometimes a tester is handed a task to complete in a specific way with an expected result and instructed to see if it is true (also known as a “test case”).

2. How to do it:

It is important to perform test cases as directed by the development team because sometimes while the testers may be exploring all the ways to unconventionally play the game, it’s more important that the conventional way is assured to work. Complete each action that is requested of the development team. A clever tester can also figure out ways to incorporate exploratory testing around whatever directed testing is given.


III. IDENTIFYING A BUG

How to do you recognize and identify bugs?

A. What is a Bug?

How do you know what you’re looking at is a bug?

1. Definition

A bug is a defect in the game that causes the game to perform or behave in a reproducible manner that does not coincide with the intended design. This could happen because of improper coding or the code could be working perfectly but unseen side effects occur.

2. Bug vs. Glitch

A Bug is reproducible while a Glitch is an odd occurrence that happens due to imperfect external forces (for example, network packet loss).

B. Bug Types

Here is a list of common bugs encountered by players:

Note: This list is not all inclusive. There are many other types of bugs, but this list is intended to give you a general overview of the types of bugs that you may encounter during testing.

• Crashes/Client Hanging: Freezes your game client or suddenly closes it on you. This is the most important type of bug as unstable builds can slow the development process.
• Gameplay: Affects the designed gameplay for the user (for example, a card doesn’t do the ability it is supposed to or does it completely differently from what it says on the card)
• Functionality: Affects menus or any other function of the game outside of gameplay (but does not fall into any other category below).
• Collision: Includes incorrect or missing physics of any 3D objects in the environment (the game board) and the boundaries of the environment (cards sitting on the board).
• Camera: Affects all camera issues that obstruct the user’s view or brings the camera through unintended areas.
• Graphics: Includes video/graphic corruption, missing/default textures, particle effects, animations, etc.
• Text: Includes: wrong, misspelled, missing or grammatically incorrect text. This also includes text that extends out of its text box.
• Sound Effects:Missing or incorrect music and/or sound effects.

C. Bug Classification

In addition to the type of bug found, you must also be able to determine what class the bug is to rank its severity.

1. "Critical" Bugs

These bugs are severe errors that prevent continued gameplay or progression. Also, they can be avoidable or unavoidable and must occur along the “critical path” (intended progression path), however if there is a way to work around them then they are not "Critical" bugs. Some conditions include:

• Requires the user to restart the client or log back in after a disconnect,
• Prevents the user from completing an objective,
• Cannot be solved by logging out and logging back in or reloading the UI,
• Requires the user to start a new character/game/etc.

2. "Major" Bugs

These bugs are general errors that negatively affects gameplay for the user, but do not halt progression. Some examples include:

• Objects that are missing, incorrect, or corrupt graphics,
• Abilities perform differently than intended,
• Graphical errors, including objects not acting as intended.

3. "Minor" Bugs

These bugs are minor errors that do not significantly affect gameplay, and may be difficult for the average consumer to notice or detect. Some examples include:

• Objects have a small patch of corrupt or missing graphics,
• A certain combination of opening and closing menus causes a button to become inactive,
• Other unique combinations that cause an error.

4. "Exploit" Bugs

These include hacks, cracks, and cheats that can negatively affect gameplay, functionality, or the economy. Players must report these as discovered and if they are found to be taking advantage of such bugs, they are subject to being banned.


IV. WRITING A BUG REPORT

You need to be able to write a bug that simply provides all the necessary information for the developer to read your bug and easily reproduce it.

Note: Report Bugs using the in-game reporting feature located on the right action bar. The bug report will automatically capture your character location.

A. Writing

In order for a bug to be written clearly and concisely so another person can read your steps and reproduce it without prior knowledge of the bug, bugs reports must be written in a standardized way with as few errors as possible. If other testers in the beta and on the forums cannot understand your report, most likely the developer won’t be able to understand it either and the bug will not be fixed. That’s why it’s imperative that we write our bugs in a simple and standardized way so that the developers can easily prioritize and fix bugs as soon as they are available. There are few key components that are common in all reports: the steps to reproduce, the result, and any additional info that can be provided for extra clarity.

1. Summary: When creating a summary, be clear and concise.
2. Steps to Reproduce: Include clear instructions on the conditions present when the bug occurred and include the actions as they happened.
3. Result: Clearly describe the unintended result you saw or heard.
4. Additional Info: Brief extra points regarding the bug (if it occurs less frequent elsewhere, if it’s timing specific, etc.)

V. REPORTING BUGS/FEEDBACK/SUGGESTIONS

Submitting bugs, feedback, and suggestions is a critical aspect of testing Project Gorgon. It is important that all players participate and follow the above guidance.

A. IN-GAME

You can submit your bugs, feedback, and suggestions using the in-game reporting feature. It is currently located on the right action bar.

B. FORUMS

Community discussion is a critical aspect of the testing process and we encourage discussions to take place on our website forums. Please be sure to create your post in the appropriate section.

B. EMAIL
If you have a critical issue, or need to appeal a ban, you can email Support@GorgonSupport.com.