A Beginners Guide to QA

A Beginners Guide to QA

We talk a lot about the games industry as a whole in our newsletter. But Adam, our in-house QA and Ghost editor, thought it might be nice to give his take on QA from an Indie Studio perspective.

Adam Sayers
🎮
Hey there! I'm Adam, otherwise known as Sayersy.
I'm the resident QA at Bellular Studios and article editor for Ghost publications.
I've been in this role for about 2 years now but I've been breaking and discovering bugs in games and more since I first started playing Worms 3D on the Gamecube and PS2!

So, you want to be a Game Tester eh?

You want to play video games and find all those out-of-bounds exploits, item duplications and hilarious physics bugs that give gamers and content creators hours of endless entertainment.

You may have already played your favourite game for well over 200 hours and thought to yourself “How did the developers not see this incredibly obvious bug?”.
As you proceed to find just the right spot, where you can jump while aiming and launch high above the map to get the longest sniper shot ever.

Well congrats! You definitely have the ideal mindset for testing.

But there is lots more you still need to consider before becoming a full time QA/Game Tester.


An Honest Job Description

There really is no one job description that nicely sums up what a tester has to achieve, because the duties and responsibilities can vary from company to company, game to game and task to task.

When I first looked into the game industry and what it would take to become a junior game developer or programmer, I was overwhelmed with technical phrases.

Phrases like -

  • DOTween
  • Occlusion Culling
  • HDRP (High Definition Render Pipeline)
  • Rebasing

Luckily, in my case, having come from an IT and Engineering background I could understand these phrases from context clues - even if I was not knowledgeable in their uses.

So when looking through numerous job listings for Quality Assurance, I was quite surprised at the differences in what was being asked in such generic terms.

📑
A stereotypical job specification would include:
- Good attention to detail
- Good written/verbal communication
- Ability to adapt to changing parameters within the project in real-time with a get-things-done personality
- Playing builds of the game and logging bugs

But an honest job specification for any quality assurance (QA), game tester or bug reporter in a professional setting would include:

  • Must be meticulously organised in databases.
  • Must have near photographic memory and be able to summarize with enough detail how bugs occurred/were encountered.
  • Be approachable and supportive to not only team members during the pre-production, design and production phases but also customers/players in a live environment post production.
  • Independently identify challenges, problem solve and construct feedback throughout multiple small to midsize projects at all stages of development

Though that all seems very daunting you may be doing it more than you realise already!


What it takes to QA

Now if you’ve read this far and are still thinking “That doesn’t scare me! I feel I can do all that!” then bravo.
Lets give you a more in depth look at what it takes to QA.
At least from an Indie Studio perspective.

Let’s start with pre-production.

It can seem almost impossible to consider that QA would take place this early. There’s no game yet made or conceived that we can get our hands onto and begin scrupulously pulling apart.
However, this stage is pivotal for QA to liaise with the marketing, creative director and wider team to make sure that no-one; programmers, artists, audio departments etc; is wasting key-time pursuing dead ends.

QA will sit in on every meeting that takes place, as early as initial concept pitches, and write down all the thoughts, musings and ideas that spring forth. They'll think up theoretical issues that could arise and different perspectives that the numerous narrative or gameplay beats could be seen from.
For instance, say a team consider developing a game about a crow, that will be dumpster diving and scavenging in a bustling city.
During the beginning idea phases, QA will take on board all the concepts thrown about and consider questions like

  • "How much of the environment will be interactable?"
  • "Will the scavenged items be physics based in the crows beak or inventory based in a UI pop-up?"
  • "Does the perspective of the crow art and its animation scale with certain objects?"
  • "Will the controls be keyboard only or will we support controller? Do all the necessary inputs have a corresponding controller input?"

Once those types of questions have been addressed to their relevant teams, collectively it can be determined if a prototype is viable.
Once that's decided a first draft, known as a Vertical Slice, is built and the teams begin iterating and reviewing the game from here on out.
During these initial stages and throughout the later production, it’s important that each department highlights whether or not certain elements of the proposed game are working as intended or are still a "work-in-progress feature".

Production

With a core game loop now determined and starting to get fleshed out, QA can get even more hands on with the systems during production.
Iterations upon iterations are made and tested for everything, from small details like UI looking its best for the end user, to critical tech and systems input; like controller support or achievements triggering at the correct moment and across different platforms.

Within this time period a detailed “Bug Board” is set up, that the QA will log and report all details in concise but accurate notes. These are typically ranked by class; Class A being game breaking and system crashing, Class B being noticeable system or UX (User Experience) issues but not game ending and Class C being minor glitches or inconsistencies across story, art and sound.

Generic Bug Board Template - Adam Sayers

This Bug Board will be maintained by QA throughout production, by rechecking submitted reports and determining their priority or critical impact to the overall game.
They will then assign tasks out to programmers and other departments depending on the fix needed.
A bug report and fix will not be signed off as complete until it’s reviewed by QA. This is to insure no other systems have been impacted by the solutions made and no time is wasted having to trawl back over "fixed" issues.

Back to the drawing board.

Whilst in the production phase, as well as making sure everything works correctly, you’ll probably notice balancing issues and strategies. Such as, optimised loadouts or resources that provide better impact within the overall gameplay design.
This is very important to keep track of and bring up with the team, as it could be the deciding factor between how difficult you can make the game and how fun the game is to play.

During playthroughs of our teams game, The Pale Beyond, I discovered a very useful resource exploit.
While hunting for resources, if you spent the first two in-game weeks giving your crew half rations you would get them onto the first wave of illnesses, "malnourishment" and "freezing".
If you acquired only Emperor Penguins and Elephant Seals from hunting and utilised the sick and injured crew for the parties, then they wouldn't be doubly hurt from the cold whilst out hunting.
After this, you could heal up to 3 crew in the medical bay, warm up 2 members next to the furnace and deploy your Elephant Seals evenly to the furnace and food pot (giving +20 fuel and +15 food each) and at the end of the week heal any remaining crew with double rations.

To make sure this wasn't an over powered strategy, we mapped out the gains and drains from all resources and constructed an Excel spreadsheet.
With equations showing if it would be better to burn or eat certain resources and how likely and long players were able to survive with what they had.

0:00
/0:36

The Accounting Beyond

Your math teachers weren’t joking when they said you would need to use equations every day, it’s just much easier to keep track of them on Excel.

Final Review and Launch

And so we enter the endgame…

A final date has been teased, the bug board has been whittled down to its smallest numbers since its creation and you’ve been driven half-mad by the spreadsheets of resource balancing and repetitive audio segments in trader shops, battles and menus from constant testing.

But with the deadline ever looming, a decision must be agreed upon between the teams.
Can we release?

Ultimately the decision comes down to leadership, but that doesn’t mean QA won’t have a big hand in helping make that decision.
The game must reach compliant standards with certain platforms and each one will have different (confidential) guidelines for what must be achieved. QA will do complete playthroughs of the game, beginning to end, and make sure that there are as few bugs as possible left, before a release candidate is submitted to publishers and reviewers.

At least one month before the proposed launch date, publishers and reviewers receive an advanced "Gold Master" copy of the game.
This is the version that QA have spent tireless hours checking, re-checking, de-bugging and analysing to give the best and cleanest experience of the game.

If the reviewers come back with issues then you will again complete playthroughs and fix any outstanding problems. You will then resend the Gold Master and if the reviewers come back with nothing, then congrats!
You’ve made it, the game is ready to hit the (virtual) shelves!

Hit the button Devs!

But the work is not over, the sad news all QA must face is that there will always be more bugs to be found. The players and end users will have fresher eyes than you and will inevitably find one small thing you glanced over.

This isn’t the end of the world though and is easily solvable.
By engaging with your community and responding to feedback, you will decode these, most times, vague comments into bugs that you will be able to reproduce and that the developers and programmers will fix.

After launching The Pale Beyond we had a particular peculiar bug rear its head.
A comment on our Steam Community Hub mentioned that a player could not advance the game past the Intro sequence.
Each time they deleted saves and replayed the first Ice Segment, the game would encounter a soft-lock and not allow them to interact with characters or progress to the following in-game week.
This being a particularly important issue, we attempted to experience this bug for ourselves on our own PCs (both home and work).
After a series of attempts, we were struggling to reproduce the same bug that at least 15 different people were now reporting.
We asked if there were any who could send us the exact save files that were experiencing the issue and again were unable to recreate this problem.
After engaging and communicating more with these players, we soon discovered they were all from a similar region.
This opened an entirely new perspective on the issue!
We then swapped our OS languages to theirs and within seconds of playing the save files we encountered the problem!
After a brief google search, we noticed that certain regions had numerous variances of the letter "i" and for a game about ice, you can see how this would be a problem.

This wasn't the only bug found post-launch but certainly a more memorable one.
As time went on and more bugs were found, more and more patches were sent out.
This is normal practice for any QA and as time goes on, once the base game hits a stable point, the whole dev team can decide to release further content or DLCs.
If this is the case, then QA will unavoidably have to begin their whole process over again.
Questioning theoretical issues, prototyping the DLC and content, maintaining a bug board during production of the DLC and again providing post-launch support for the new content.


Useful Resources and Final Thoughts

I have increasingly enjoyed my time as a QA Engineer and Game Tester and know that it can sometimes be a gruelling task to undertake.
Within the indie space, and as someone just beginning their Game Dev career journey, it's a remarkably insightful look into all avenues of the industry.
I work alongside wonderfully talented writers, artists, animators, sound designers and coders and continue to pick up invaluable knowledge from them daily.
QA is a time consuming but rewarding job and though it's not talked about as much as other pursuits, it's a discipline and skill all of its own.
I would certainly recommend anyone who has an interest and drive to make their way into the Game Dev Industry to consider a career in QA, as you will touch every part of the production cycle in some way.

Over the past while, it has become clear to me as well, that in the AAA scene there has been an overall loss of collaboration between departments and that has led to numerous issues. The QA process is too often outsourced for cuts and for profit.

A memorable quote by Kosmas Stocking from Modus Games highlights just how integral QA is within the development process.

By Kosmas Stocking- August 23, 2019

“QA, or Quality Assurance, is an oft undervalued part of the game development process. Due to its nature, its greatest contributions are completely invisible while its greatest failures can render a game unplayable. Though it may not shine as brightly as art, music, or design, a good QA process can vastly improve the end user experience of a game.”

If you are still interested in becoming a game tester here is a final list on some valuable resources and books/articles for Quality Assurance -

🛠️Resources and Sites

https://www.udemy.com/course/kick-off-your-gaming-qa-career-basics-of-qa-for-games/?matchtype=

https://www.gotestify.com/

https://trello.com/home

📚Notable Books

THE GOAL
https://www.tocinstitute.org/the-goal-summary.html

SIX THINKING HATS
http://dspace.vnbrims.org:13000/jspui/bitstream/123456789/4746/1/Six%20thinking%20hats.pdf

WRITING BETTER DEFECT REPORTS
https://www.stickyminds.com/sites/default/files/presentation/file/2013/T7_02STRER.pdf

📽️Useful Videos