Seven ways to master functionality QA in video games

If there's one thing that everyone in the games industry has in common, it's the desire to produce games that will be enjoyed by as many players as possible.

Making these requires a high degree of cooperation between many moving pieces during production, with each playing their own essential part, such as Functionality QA (FQA) which is responsible for reviewing the quality of the gameplay experience.

This can seem daunting at times, as this quality can definitely affect how much players will be able to enjoy a game, but thankfully there are steps that QA can take on its own in order to improve collaboration with other stakeholders and help improve the quality of a title overall.

1. Build a QA plan that's flexible

Planning ahead is obviously key in any long-term endeavor and identifying problems before they arise will save everyone from dealing with a lot of pain down the line.

That being said, not everything can be anticipated and learning how to deal with curve balls is probably one of the most important aspect of Functionality QA. This is why you should build a QA plan that's flexible.

Give allowance for extra time in your QA plan: for example if your release date is pushed back you might need to reduce your team size to gain extra mileage out of your budget. This also applies to the budget itself; you never know when an extra feature will suddenly require more hours devoted to it.

2. Ensure that documentation is up-to-date

One of the key performance indicators of a Functionality QA team is often tied to how many valid vs invalid (duplicate, as designed, etc...) issues are reported. While I won't delve into what constitutes 'acceptable' in this regard, you can reduce the amount of 'as designed' issues reported.

Working with outdated documentation or no documentation at all is generally the main culprit here. It makes sense that keeping documentation up-to-date would work as a solution but it is easier said than done.

The QA and development team can also meet in the middle, setting up processes to communicate changes. Build notes can be sent from developers to the QA team or features can be listed in a database, allowing QA to follow up on them.

Regardless of the approach taken, the bottom line should be to have it written down in one central location.

3. Assume as little as possible

The more experienced we become, the more it seems we are susceptible at making assumptions based on our past experiences, especially when dealing with similar situations or projects we've been involved with before.

It can be little things, such as assuming that an issue will be fixed on the next build and preparing accordingly - all the way to assuming you'll get a waiver for an issue at submission, as every previous iteration of the game was granted that same waiver. Each has its own impact, regardless how small.

You can't always double-check absolutely everything, but one way you can reduce those risks is to constantly weigh the impact of being wrong versus the time it would take to confirm your assumption.

"You should give your team time to be creative and go crazy with the game; breaking it apart in ways no one else would have imagined"

4. Shake it up

One of the challenges with long-term development is avoiding your staff becoming blind to issues over time, as Functionality QA is inherently results-driven and requires repetition. The longer someone is stuck in a repetitive loop, the higher the risk of missing the obvious.

Try to rotate tasks between team members once in a while if you're not currently on a tight deadline or plan ahead and give them something new to focus on every few weeks if it makes sense. Simply moving people's seat or desk around can help as well. This also leads to my next point.

5. Allocate time for the team to get creative with their tests

As pointed out above, it's great to have a plan and to be flexible with it. The thing is, however, that it still won't catch everything. And of course, games continue to get more and more complex.

This is why you should give your team time to be creative and go crazy with the game; breaking it apart in ways no one else would have imagined. You can even have your team document any successful attempt at breaking the game and use those as test cases on similar titles or similar engines in the future.

6. Set up a central point of contact

This one is a bit more specific, but in some cases you may end up working with multiple departments, or even multiple offices. There is a real risk of information being lost between stakeholders, and this will increase proportionally unless you're prepared.

It might be tempting to share absolutely everything with everyone, even what is irrelevant for other groups, but the truth is that overloading people with too much information may increase the risk of someone missing something important.

Something you can do is to assign a central point of contact, someone who can coordinate communication and that everyone can rely on. This person would help ensure that all stakeholders are appropriately informed and receive relevant updates in a timely fashion.

7. Identify opportunities for improvement

When all else fails, what you're left with is the chance to learn and adapt. Nobody will have all the answers, there are probably as many unique scenarios to deal with as there are Functionality QA teams.

Of course, one part is recognising your mistakes, but you should also identify successes and see, depending on their nature, if they can be reproduced with another person, team or project.

All this may seem obvious to industry veterans, but the key element to keep in mind is to take the time to sit down and review these: something easier said than done. Alternatively, you can also include these as topics or sections of existing meetings you already attend such as milestone, monthly or quarterly reviews.

For more information on Keywords Studios. Click here.