Breaking down some misconceptions about what a game quality professional’s job really entails
Guest Blog by David Jenkins
Please note, all opinions expressed here belong solely to the author in their personal capacity, and do not reflect the views of their employer, clients, customers, Game Quality or any other third parties.
What do game quality (GQ) professionals do all day, and why do many people still not… get it? To answer those questions, I’m going to be looking at a few common misconceptions about our discipline from several different perspectives, while clarifying what it is we do in our working day.
Our job is, ultimately, to support the rest of the studio to release the best possible version of the game to the public. So, this article is here to help everyone to better understand how we can do that.
Of course, not everyone has these misconceptions (#notallgamedevs), but many of us still come up against them on a regular basis.
1. WHAT PRODUCERS THINK I DO
I have been very fortunate to work with some amazing producers over the years, who have embraced the supporting role provided by GQ. However, this is not always the case and one of the more common issues seems to be an impression that GQ are a bottleneck, because so much of our role often boils down to saying “no”.
That could be in the form of a Test Case failure, a subsequent bug, not signing off a milestone or not approving a submission build. That can easily lead to Producers dreading contact with GQ, as we will be seen as always bringing them problems which they have to fix.
In reality… well, OK a lot of that is true. BUT it’s still vital information and it isn’t all we do. Or at least it shouldn’t be.
GQ teams should also be responsible for reporting on the positives. Features that have hit their acceptance criteria or are feeling especially fun, systems that are robust and tracking well, and critical bugs that have been resoundingly squashed.
Of course, even the more negative reports from GQ should be about solving problems before they happen; identifying risks and helping to put processes in place that mitigate against them. This includes assisting with bug fix priorities (via a triage) and using test data to predict what features pose a threat to the schedule and which are relatively safe.
We often work more closely with Production than any other department, so it’s essential that the relationship we have with our Producers is solid and based on mutual understanding and trust. I encourage you to engage with each other, have regular meetings, host retrospectives, get involved in planning calls, and of course raise concerns as soon as possible, but celebrate the wins just as loudly.
2. WHAT PROGRAMMERS THINK I DO
To programming teams, GQ are most often the bearers of bad news. Although not every game defect will be theirs to fix, sometimes art, design, audio and even narrative issues will require their support to resolve.
As a result, a huge number of the bug tickets in your database represent some extra work for programmers. And that’s on top of any additional effort required to implement debugging/testing tools and test automation (if this isn’t being handled by QA Engineers and SDETs).
Worse still, that extra work often involves re-doing previous work, which can sometimes feel like GQ’s job is just pointing out the ways programmers haven’t done their job right (although we all know it’s not as simple as that).
In fact, research in the broader discipline of software development suggests that roughly 50% of the defects on any product are introduced before any code is written on any given feature. The issues usually arise from problems with the initial design (e.g. a mismatch between player expectations/wants/needs and the intended implementation) or a misunderstanding introduced during feature kick-off/handover.
One of the reasons for the industry’s adoption of the Shift Left methodology is to help catch as many of those potential defects as early as possible, ideally before they get introduced into the codebase (e.g. by testing designs, workflows, wireframes and paper prototypes).
This front-loading of GQ also reduces the chance of needing crunch later on, makes scheduling easier, keeps the team size more consistent (so you’re not ramping up and down across projects) and helps GQ to better understand each feature. This helps with test planning, collating more impactful feedback, identifying risks and implementing potential time savers like tools and automation earlier in the cycle.
3. WHAT CREATIVES THINK I DO
I’ve put the disciplines of Design, Art, Audio and Narrative together here, because so much of their work can be considered subjective, and that subjectivity is often the cause of any conflicts with GQ teams.
Tickets raised that don’t directly translate to “thing doesn’t match spec” can be considered qualitative or subjective feedback and therefore easily dismissed (in fact, I’ve worked at studios that don’t even allow these sorts of tickets to be added to the database in the first place).
However, one of the most vital duties that GQ performs is in representing the wants, needs and views of the player. “You are not your user” is a common design mantra, but your GQ team members will likely be the biggest gamers at your studio, and so are the closest equivalent to your players that you have in-house. Also, many GQ professionals do have an interest in, aptitude for, and qualifications in, various creative fields, so could be applying the same principles!
4. WHAT MY MUM THINKS I DO
“Play games all day.” I’m sure you’ve all heard this one from someone you know.
But the higher you climb the GQ ladder, the less true this becomes; and it’s not true even at the bottom! While I think it is essential that everyone (that’s the entire development team, marketers, Release Managers, Studio Heads, HR – everyone) regularly plays the game they’re making, GQ will invariably have very little time outside of that to just be “playing games all day”.
The closest would be exploratory testing, or destructive testing, but even this will be guided in some way by goals and outcomes, and could be on the same area of the game for months at a time.
5. WHAT PLAYERS THINK I DO
Nothing, it would seem. Or at least, not enough. Whenever a game launches with a lot of bugs in it, or the servers go down, or the game is just… bad… it is often blamed on “not enough testing” or just “useless testers”.
However, it is ultimately not the responsibility of GQ to ensure that bugs are fixed. We can inform, send up flares and wave red flags, but Production sets priorities and the rest of the development team implements fixes (or doesn’t). But a lack of trust in GQ can easily lead to a dismissal of their warnings and a subsequent buggy (and likely unsuccessful) launch.
So, for the GQ professionals among you, challenge these misconceptions by showing your true value to your colleagues. And to everyone else, I hope this better understanding helps you to make the most out of your GQ teams!
