10 things you should know about ... QA

The stories we live over the course of our careers shape the way we see each other and affect our work together. ‘10 things you should know about ...’ is a series prepared with game developers to share what we feel and hide from each other as we collaborate on a game. Agree, disagree, share and add your own to complete the picture.

This is the last post in this series. Read previous articles about artists, designers, leads, producers and programmers.

The objective of this series was to highlight that while development issues can often be solved with more time, more money, detailed processes, improved hardware, better software or training - sometimes talking, listening and understanding make a big difference in solving (and preventing) issues. And it’s free. Thank you for reading and commenting.

1- You test your work to ensure that it meets requirements. We test your work to see where it fails to meet requirements. It might seem negative and personal, but our opposing mindsets are complementary: the more issues you fix, the better your work will be.

2- We represent the next level of stakeholders: we look at your work with the eyes of the client, the licensor, the first party manufacturer, the user. We wear their hats so we can tell you what they will experience, to give you a chance to influence their reactions.

3- The difference between a bug and a feature is not always obvious. If we find an issue that you classify as ‘not a bug’ or ‘won’t be fixed’, please take the time to let us know. It can be frustrating to see an issue being ignored, and understanding your decision will help us report other issues better.

4- We are an integral part of the team and need to know the same information as everyone else. Changes in the project (at content or planning level) are interesting and useful to help us support your work. And we love celebrating your milestone achievements too!

5- QA departments are often seen as a cost center rather than profit making. This has an impact on how they are staffed, supported and included in the development process. Changing the way we are seen would greatly affect how other departments interact with us.

6- Just because we are looking for issues doesn’t mean that other departments can’t do the same thing. Everyone on the team should have access to the database and be made to report issues they notice when playing.

7- If the project is slipping and you’re considering eating into the QA phase, could we be part of the discussion? It might be the right decision but we won’t feel so disposable if we understand the reasons for dropping the other options.

8- Sometimes testers suggest gameplay and design improvements because they are in the best interest of the game – not because we secretly want to be game designers.

9- Our job is to find bugs. When we start reporting rare and low priority bugs, take this as a sign that your code is in pretty good shape – not as a sign we are detailed-obsessed critics haunted by perfection.

10- If you can’t see it on your machine, maybe you can come and see it on mine. The problem is present and if I found it chances are someone else will.

Written with the contribution of Tim Aidley, Jordan Ault, Dave Hollingbery, Mark Lintott, Kim Russell, Rik Skews, Chris Solarski, Will Sykes, Sean Turner and others who wish to remain anonymous.