Quality Assurance: How To Break A Game

Breaking stuff is fun; sometimes it’s smart. When a car company develops a new car, they must break it to test its emergency and safety features. Will the airbags deploy? Will they keep the driver safe? How will the collision affect the vehicle? Game developers ask similar questions of their games. How secure is the coding? If the player decided to veer into this obscure corner, would they get stuck? Why does the game crash while loading the next level? In this article I will briefly clarify the role and purpose of quality assurance (QA) in game development.

So, what is quality assurance (QA) testing? Think of it like writing an essay. When you write an essay, you compose a rough draft. You give your rough draft to someone else to proofread your work, suggest corrections, note mechanical and grammatical errors, and other relevant criticisms to improve the next draft. Quality assurance works similarly. Producers produce a game, which they send off to the QA team. The QA team is in charge of noting (in great detail) anything they find amiss with the game: coding errors, game-breaking glitches, unresponsive inputs, etc. When the QA team finishes their copious note-taking, they send their notes back to the producer, who then (ideally) revises the game accordingly.

At this point, the game’s out of the QA testers’ hands. As an aside, the reader should appreciate the QA testers’ role relative to the producer. The producer’s the boss. The QA tester reports to the boss, and it is entirely up to the producer to decide whether they will revise the game. So, it’s important to note that even if a QA tester detects a bug, that doesn’t mean producers will fix it. Sometimes players too readily blame QA testers for “not doing their job” because a game is dreadfully buggy. Hopefully, appreciating their producer-relative role assuages the readiness.

Another bit of clarification seems necessary. When QA testers are testing a game, they have priorities. They may not address every single glitch or bug. Instead, they typically look for game-breaking or progress-halting glitches first before anything else. Minor glitches or hiccups that don’t stunt progression through the game are called C-level bugs. QA testers may or may not address C-level bugs. Nonetheless, presentation matters more than testing minor bugs.

One might wonder what happens when the producer(s) neglect the testers’ observations. If the unfinished game hits the shelves, what then? I refer the reader to Sonic Boom: Rise of Lyric. Some bash the game for being unfinished. They gawk at the notion that it was even tested for quality. But it was. The trouble was that the producers didn’t listen. Perhaps they rushed the game. Perhaps the quality assurance team prioritized certain bugs over others. Whatever the case, whatever happens after testing is out of the tester’s hands.

In sum, quality assurance testing is the process by which an assembly of testers breaks a game and notes what makes it break. As such, they are observant, competent teammates who “proofread” the producer’s product. Whether the producer listens is another issue entirely.