As a team, we hold frequent sessions to test and balance the game. This post describes what our own team needs to do during these sessions.

All team members are expected to attend most sessions. Each session will have an owner that will drive the session. If the owner is not present at the start of the session, any other member can step up and drive it instead.

Playing

The session times along with the session owners can be found here: http://bit.ly/2hnLXmw

Detailed instructions for installing and running the game are here: http://wartothecore.com/beta-testing/

Builds

Every day, we should produce a daily build for each of our platforms. Each build has an owner (this is independent of session ownership). The owner is responsible for ensuring that his/her build is built correctly and uploaded at least 30 minutes before the next play test session start time. Below are the build owners

• Steam quality owner: Hajjaj
• UWP/WSA quality owner: Hossam
• FB Game Room quality owner: Abaza

Driving the Sessions

The session owner is responsible for ensuring the points below are followed each session.

1. Ensure that the build owners have uploaded their builds before the session time. If something is missing, he/she should ping the build owner directly.
2. If the session owner wants to test a specific build (platform), he/she should notify others in the channel 30 minutes before hand so that those on slow connections will have time to download the right build.
3. At session start time, notify everybody by tagging @channel in #playtest.
4. Before starting playing, ensure everybody is online on our Discord channel and notify the channel that we are playing. Note that others not on the team may not be able to join our TP server or staging if they are on the production builds.
5. Discuss game logistics on Discord, to avoid cluttering Slack. Stuff like which server to join, asking people to join specific battles, etc…
6. Discuss game bugs and features in Slack. When an issue or suggestion is made, pin it to the channel.
7. After the test session is done, go over all the pinned items.
   1. If the item has a known bug on Mantis, then unpin it and respond to the message with the bug ID so we know it’s a known bug.
   2. Otherwise, create a new unassigned bug on Mantis in the current milestone with a “Minor” severity and leave it unassigned. It will later be resized as needed and triaged to be allocated in the right milestone and assigned as needed.
   3. Unpin the message.
   4. If there were less than 10 newly pinned messages and there were older pinned messages, go back the pinned list and process them so we burn down our pin list.
8. Report a final summary of the build (indicating the build type).
   1. Good: Ready to be pushed to production on the stores.
   2. OK: Some issues, but still usable for internal testing.
   3. Broken: Big bugs that render the build unusable.

Comments

comments