8/31/99

"I said pretend you've got no money... she just laughed and said 'You're so funny!' Yeah... but I don't see anyone else smiling around here." - Pulp Hello Everyone, I'm back for another design update, and today I thought I'd touch on the section of development known as TESTING. Here at Interplay, we have a large testing department, also known as Quality Assurance, that handles bug reporting for the majority of the games that our company develops and/or publishes. In addition to detailing crash, graphic, program, sound, and other assorted bugs, they serve as a meter stick for the quality of the game, letting us know on a regular basis how good (or bad) they feel the game is. They essentially are our last line of defense before a title is released to the public, and their contribution to development is invaluable. All the stories you've heard about game testing are true. It's not uncommon, during the last stages of development, for testers to work seven days a week, sixteen hours a day. Often times, testers will see games in a state long before shipping, where they enjoy frequent rebooting, unplayable sections, and unfinished design. The misconception of testing being some sort of fantasy job quickly erodes when you're trying to repeat a crash bug for ten hours on a section of game you've seen, every day, for the last three months. However, most testers are avid game fanatics who one day envision creating titles of their own, and there are few places better that a QA department to introduce the world of game development. Often times, especially if a title is developed in house, testers will get a first hand look at what goes into making a computer game. Consistent interaction with the development team, working with titles as they come together, and overall design atmosphere are what testers benefit from for their long hours, and occasionally, strong motivation and initiative pays off in the form of a position on "the other side." QA teams that test role-playing games arguably have the toughest jobs, as the depth and amount of material they will have to keep track of can be immense. Planescape:Torment is definitely no exception to this rule, and our QA team has been on the bug hunt since the early months of 1999. Led by Damien Evans, Planescape QA has taken to the task of making sure we have a solid, stable, and entertaining game with commendable effort and diligence. Several of our testers are avid role players themselves, and their experience with the Planescape world and other RPGs has made their bug reporting and suggestions invaluable to the development of the game. You're probably wondering how this bug reporting business works for a game like Planescape:Torment. Well, here's a little look into how things get sorted out, eliminating those pesky bugs: 1. Testers download / receive a weekly revision of the game. As the end draws near, this changes from weekly to everyday to every few hours. 2. In a game like Planescape, testers are often assigned certain areas of the game to sweep, searching for any potential problems and actually attempting to create them as well. Along the way, they detail these problems/bugs as they occur, writing down as much information as possible, and attempting, if possible, to find a bulletproof way to reproduce the bug on multiple systems. 3. Sometime during the day (generally at the end of their shift,) testers will stop testing the game and start up a specially designed database that helps organize and keep track of bugs. This database allows them to enter information like revision numbers, frequency, area numbers/locations, type of bug (crash, graphic, sound, etc.,) hardware configuration, bug detail, and bug amendments. It also allows them to quickly query the database, narrowing down bugs into specific categories for easier reporting and access (testers generally want to check to see if a bug has been written up before so that the database isn't littered with duplicates.) 4. The database is then accessed on our side by THE MAN Ken Lee, who organizes the bugs by the individuals responsible for them, and passes them out accordingly. The design team then grumbles, moans, and says things like "That's not a bug, that's a FEATURE!" and "What do you mean you don't like the exploding Brahmin!" until Ken Lee comes back with a whip and forces us to address the bugs at hand. 5. Ken then assembles a list of bugs reported as "fixed," which he passes off to QA to confirm. If the bugs are confirmed by QA as fixed, they're marked off to oblivion, and if they're not, well, then Ken puts down the whip, grabs chairs, and regulates. :-) Anyhow, I hope you've enjoyed my insight into the world of testing, and stay tuned for my next update where I will detail the finer points of "camping in your office!" (Colin will provide the Smores!) Take care, Scott Warner swarner@interplay.com

Planescape: Torment & Design: © 1998 Interplay Productions. All Rights Reserved. © 1998 TSR, Inc. All Rights Reserved. Planescape, the Planescape logo, Advanced Dungeons & Dragons, Torment, the AD&D logo, and the TSR logo are trademarks of TSR, Inc. and are used by Interplay under license. TSR, Inc. is a subsidiary of Wizards of the Coast, Inc. Interplay, the Interplay logo, Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Productions. Exclusively licensed and distributed by Interplay Productions. All other trademarks and copyrights are property of their respective owners.