As a development team nears completion of a game’s features and assets (art, audio and text), the game starts to take its final form, but it is likely still rife with errors and problems that we call “bugs”. The term “bug” for a software error came about in 1946 when engineers traced an error in a Mark II computer to a moth trapped in a relay. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.

Development teams send off versions of their game to a fresh set of eyes for finding the bugs. These set of eyes belong to the Quality Assurance team, also called “testers”. Testers use check sheets to go through the game and ensure that all the thousands (even millions) of features and assets that were supposed to be implemented are actually there, working as planned.

When a Quality Assurance team reviews a game build and finds bugs, they write up a report for each bug found. Bug reports are generally written in an online database with the following information:

• žBug #: This is automatically generated for each new report. It is much easier to refer to Bug #725 than “you know that problem in the Valhalla level where in the green building in the back where two walls don’t quite fit together properly?”.
• Summary (Headline): A synopsis of the problem.
• žLocation or Component: Where in the game the problem occurred.

ž

• Description: More detailed information about the bug.
• žExpected Result / Actual Result: For when bug is not obvious (for example: after reloading, the gun should have been able to fire 8 shots, but the actual result was that it could only fire 6 shots).
• Steps to reproduce: So that the development team can replicate the bug. Unless a team can recreate a problem and see it for themselves, they may not be able to fix it.
• žReproduction Rate: How frequently the bug occurs. Does it occur all the time (100%)? Have the time (50%)? Is it not repeatable.

ž

• Severity: Bug severity levels are usually categorized as:
• A = (Blocker / Critical) Fatal flaw. —Crashes, freezes, can’t finish game.
• B = (Major / Normal) Serious flaw. Features don’t work properly.
• C = (Minor / Trivial) Minor flaw. —Glitches in artwork, typos, minor annoyances.
• žPriority: Does the problem need to be fixed ASAP? Can it be saved for a patch? (Priority is usually determined by the project’s producer and not the QA team).

This information is sent back to the development team. If they address the issue, they will mark it as FIXED and the QA team will retest and verify the fix when they receive the next build.

The team may also mark a bug as CAN’T REPRODUCE or NEED MORE INFORMATION if they can’t duplicate the problem. Or, if they think the game is working as designed and the QA team just disagreed with the design direction, they may mark the bug as NOT A BUG or WORKS AS DESIGNED. Finally, if the producer decides that this is a minor problem that can ship with the game, it may be marked as WILL NOT FIX.

The bug database is preserved after the product ships so that it can be referred to when making patches and updates to the game.

It is not unusual for thousands of bugs to be found during the course of game testing. And even when using a bug database to track down every single error found, some do slip through the cracks and wind up bugging the customer.