A GLOSSARY OF SOME TERMS FREQUENTLY HEARD IN QA

A GLOSSARY OF SOME TERMS FREQUENTLY HEARD IN QA

'A' bug -- The 'A' bug is the very worst kind of bug. This type of bug can be summed up thusly: "It would be an unthinkably bad disaster if the game was released with this problem unfixed." Some examples:
   - the game crashes;
   - there is a virus in the game;
   - there are obvious spelling errors;
   - there are obvious graphical or audio problems;
   - a feature (in a menu or accessed by pressing a button) does not function;
   - there is no copyright language in the game anywhere;
   - the game is not fun to play.
Releasing a game with this sort of flaw would generate very bad public reaction and bad press, or there could be legal ramifications against the company.

'B' bug -- The 'B' bug is not quite as bad as the 'A' bug. It can be summed up thusly: "It would be unfortunate if the game was released with this problem unfixed, but the game is good regardless." In a pinch, if the company has a need to release the game and stop spending money testing and fixing it, and if Customer Support, Sales, Marketing, QA, and the executive staff all agree, the game may be released with minor flaws. For example:
   - bugs which do not ruin the experience of playing the game;
   - noticeable graphical or audio problems (especially if you know where to look for them);
   - highly desirable features were left out (and are not mentioned anywhere in the game).
'B' bugs will likely show up in press reviews of the game but are things that are probably hard (expensive; time-consuming) to fix. The playing public won't be happy with these problems, but the overall playing experience is not ruined by the existence of these problems.

'C' bug -- The 'C' bug can be summed up, "It would be nice to fix this problem." The tester may feel strongly about this problem s/he has identified, but when weighed against the company's larger need to release the game, the bug isn't that big a problem in the decision-makers' view. When push comes to shove, 'C' bugs may have to fall by the wayside (if they're hard to fix, that is -- a 'C' bug that's easy and quick to fix is likely to simply get fixed, unless the project is coming down to the wire).

'D' bug -- "It would be nice to add this feature." Especially when reported later in the test process, 'D' bugs are likely to remain unfixed.

"All bugs should be fixed." -- Ideally, of course, this is true. But some games are so big and complicated that the fixing would simply never end. And some testers are pickier than other as to what constitutes a bug that needs to be fixed. There have to be checks and balances in a game company (just as there are in a governing body).

"Alpha" -- The terms "Alpha" and "Beta" are defined differently by every company. Especially, developers' definitions of these terms may vary from publishers' definitions of these terms. Some developers may prefer to define Alpha as "code that demonstrates how the game will play." But most publishers (specifically a publisher's QA department) would prefer to define Alpha as "everything has been implemented in the game but there are bugs and the gameplay needs tweaking."

"Beta" -- Some developers may prefer to define Beta as "everything has been implemented in the game but there are bugs and the gameplay needs tweaking." But most publishers (or their QA departments) would prefer to define Beta as "everything has been implemented and as far as the developer knows, there are no bugs and the gameplay has been fully tweaked."

"Beta testing" -- Quality Assurance testing is a different thing from Beta testing. We usually use the term "beta tester" to refer to volunteers who test for free from their homes. Q.A., on the other hand, is a full-time position, a paid job. Beta testing is a good way to break into real testing. Look for opportunities to volunteer when you see that a game company is seeking beta testers (usually in an online game bulletin board or something - it's hard to seek out beta testing opportunities, you just have to be active in the game community's online forums. I also hear fileplanet is a place where beta testing opportunities can be found, if you really want to do it). Do the beta testing well, and you might get offered a real testing job.

"Can Not Replicate." -- Sometimes a problem will happen to a tester but he can't provide steps to replicate the problem. If the programmer can't cause the problem to occur, with the debugger running to reveal the source of the problem, it may be difficult to fix. A good tester will try to make the problem happen again or figure out why it happened.

"Gold Master" -- The CD or DVD released by QA to manufacturing. This disc has been verified and virus-checked and has gone through an extensive checklist before it's sent out the door.

"It's a feature." -- The corollaries to this one are "Not a bug" and "Works as designed" (below). Sometimes what the tester expects the game to do, and what the game does instead, cause a bug report to be written. The bug report goes to the designer, who says "that's not a problem -- that's the way I designed it to work, and here's why it should remain as is ..." If the testers can present a convincing argument that the "feature" is counterintuitive or unfriendly, then perhaps it needs to be changed.

"Need more info (NMI)." -- This comment is likely scribbled on a bug report that doesn't tell the programmer enough information about how to replicate a bug, or why the tester feels that it is a bug.

"Not a bug (NAB)." -- See "It's a feature" (above).

"Psychotic user behavior." -- Term used to characterize a problem caused by unreasonable user input. For example: "The game crashes if you press F10, then Esc, 30 or 40 times in a row." No reasonable user would do this, and even if someone does do it, it would be unreasonable to fault the game for crashing under these circumstances. If the problem is hard to fix and the project is coming down to the wire, it may be simply written off.

"Release" -- QA signs off on the game and puts their stamp of approval on sending the game off to be manufactured.

"Ship it." -- This phrase is heard at the tail end of the test process, when the test team is starting to see the light at the end of the tunnel.
   - Tester: "I found a bug."
   - Lead tester: "What kind of bug?"
   - Tester: "It's just a 'C' bug, not a biggie. Psychotic user behavior."
   - Lead tester: "Ship it!"
Finished (tested, quality approved) games are shipped by Fedex or other courier service (or sometimes, if really important and timely, delivered by a member of the team) to the manufacturing facility. Manufactured product is shipped by truck to the stores. "Ship it" is the mantra used to seal the importance of cutting off testing and releasing the game into the wild.

"Tweak" -- Synonymous with "adjust."

"Will not fix (WNF)." -- When time is running short, and minor bugs are reported, the programmer or the designer or the producer may scribble this cryptic note on the bug report. All bugs have to be "closed" (resolved) before the game can be released.

"Works as designed (WAD)." -- See "It's a feature" (above).