Today I’d like to talk more about how the Quality Assurance (QA) team works during different stages of a game development project. From the beginning, we in the QA team are seriously involved in all the work. We are the first focus group confronted with the team ideas.
In the pre-production phase, we discuss the story ideas with our writers, and cooperate with the game designers when it comes to game features. In the first prototypes we’re not looking for bugs, but rather the fun factor. We can call this practical design. The designers have lots of great ideas that they try out to give the player as much fun as possible, but they also need someone to look from the outside – people not committed to a specific feature or idea – assess whether these ideas make sense. In a way, we are the vanguard of public opinion about the game. So, contrary to the common belief, testers have a role to play even before the alpha stage.
In the Alpha stage, we check if the game is simply playable. Can you finish it? How do all the features work? That’s when we have to catch a large number of bugs in a short time. I think I can say now that in The Witcher 2 Alpha we found around several thousand bugs – it was around 300 hundred bugs a day. Of course, each error and glitch is completely different, so first we want to find game blockers or crashers – everything that might ruin the game’s performance. Then come the little things. Even seemingly small problems can disrupt the game’s quality. Therefore, we report as many possible, so who ever fixes them can plan his work for the Beta. The Beta is the phase of the general polish, but the Alpha is for the serious bugs.
In the period somewhere between the Alpha and the Beta, we go back to testing the fun. This time we focus on the game’s balance. The game will be balanced only if the team is balanced.
As I said, it’s important to be a gamer when you work in QA. It’s not so much about your gaming skill as it is the range of skills. A good QA team has to consist of different types of people. We have to have casuals and hardcores on board. If we have people that beat every game, get every achievement in it – then we have only one point of view. If you find a part of any game to be always absurdly difficult, be sure that it was tested only by hardcores. Dividing the team is important not only when it comes to setting the bar for game difficulty, but also other factors. In our current projects we allow only half of the team to read the whole story of the game, while the rest doesn’t know it at all; this second group can then give us feedback about the comprehension and presentation of the story. In The Witcher 2 we gathered a team with people who had read Sapkowski’s novels and people who knew squat about Geralt. We’re creating a game, after all, for people who are unaware that these novels even exist. I say that if every tester who has beaten the game a hundred times (in terms of gameplay hours) says it’s easy, it means that everything is just as it should be.
When we are talking about balance in the game it’s not all about mechanics, but also about presentation. We analyze the game’s length and what happens in particular playthroughs. We can show the designers that a particular quest has too little or too much combat, dialog or cutscenes. There are a lot of things to check when analyzing the game, so we try to divide tasks so nobody gets bored doing the same thing over and over. We set two weeks as the maximum time a person works on one aspect: gameplay, performance etc. and then we let them switch tasks. It’s great when a person can rest from one part of the game and when he or she returns after some time to this fragment of the game they can approach an old job with new perspective and give valuable feedback.Tweet