[quote][b]Part 1: Known Issues.[/b][/quote]Don't read your bugs. Read only the first five words of the bug, and then route it to other people on the team based on those five words. Send back random bugs as fixed without reading the bug. When they're returned open, send them back as not a bug. Write "That's a known issue" on a bug and send it back, thinking the tester will close the bug because now you know about it. Write "It works fine for me" in the comments and send it back. Write "It works fine for me" in the comments and then sit on the bug for the rest of the project. Let the bugs pile up in the database for months. Then, when you finally do get around to looking at the bugs, throw up your hands and say, "I don’t have time to deal with these!" Afterwards, ask the testers to do a full regression pass on anything that's open in the database. Tell the testers to come in early so they can have a build report ready by the time the rest of the studio gets in. Don't pay attention to the build report. Waste time getting builds that were indicated as broken in the build report. [quote][b]Part 2: The Issues.[/b][/quote]When the testers raise performance issues, say “Well, duh, we haven’t done the optimizations yet. Wait until we do optimizations to flag this as a problem!” Don’t do any optimizations until the last possible moment. When the optimizations fail to fix the performance issues and it’s too late, say, “We should have been testing this.” When they raise compliance issues, write, “That won’t be an issue.” Forget that the discussion took place when the game fails its certification. “When they raise game balance issues, tell the testers to stop raising game balance issues. [quote][b]Part 3: Thwart Progress.[/b][/quote]Create an achievement that can be unlocked only by playing the game actively for 300 hours. Create achievements that reward completion on the hardest difficulty setting in one sitting in a game with one-hit kills and no checkpoints. Don’t put in any debug commands to unlock them. Ask the testers to do a pass through the full game progression, in all modes and difficulty levels, and then update the build with a small code change as soon as they’re done and ask for it again. [quote][b]Part 4: Word Games[/b][/quote]Call the QA team “The Q and A team.” Ask them, “So you guys just sit around playing games all day?” Ask them, “So do you fill out, like, a form or something when you’re done?” Jokingly ask if they can smuggle you a pre-release build of so-and-so upcoming game- they’ve definitely never heard that one before. Ask them if they watch PlayStation Network’s “The Tester.” Ask if PlayStation Network’s “The Tester” is what it’s like to test a game. When reviewing games, assume that any bug found by a tester is automatically being fixed by someone. Ignore the idea that hundreds of bugs could be found and documented by the test team and not fixed by the development team. In your review of the game, write, “I can’t believe the testers didn’t catch this problem!” or, “What were the testers doing over there? Not their jobs, clearly.” When someone says they’re a tester, smile and tell them, “Actually, testing is an important part of the game development process!” even though they didn’t say anything to denigrate themselves in the first place. [quote][b]Part 5: The Shakedown[/b][/quote]Get your bug numbers down by reducing the number of testers. Replace many of your testers with outsourced testers. Make the few testers you’ve kept try to figure out what the bugs from the outsource testers actually mean. Make your in-house testers retest the bugs written by external testers. Split hairs about the difference between code and content. Say, “At the end of the day, isn’t code just another kind of content?” Mention that the final spec of the game is in state of flux. Mention that all the features that the testers are testing could change at any moment. Tell the testers that all your documentation is out of date and that there is no up-to-date documentation on how the game should actually work. When you encounter a particularly difficult bug, send it back and tell the tester they must be lying. Question the tester’s testing methodologies. Question the tester’s eyesight and ability to perceive what actually happened in the build. Accuse them of flat-out lying. Challenge them to reproduce the bug right in front of your eyes. When they do, fume impotently, but don’t ever credit them, even in your own mind, for exposing the holes in your grand design.