|
Tester Tips
Beta testing a product can become very tedious for the designer to do all by himself. It's also not recommended because it's likely that you'll overlook several things. That's where us beta testers come in! You send your product to a select few of the general public and HOPE we get back to you. Though by doing this you'll always catch those "unreliable testers" that just USE your program for their own benefit, you'll hopefully, thanks to the "reliable testers," find out where the bugs in your program are. Beta testers should do certain things when they're testing a product. The designer (or lead tester) should also do some things to prepare for testing and communicate this to the tester; they need to keep the tester active. Beta testing is like proofreading a paper. Once you finish typing a paper there're tons of spelling, grammar, sentence structure errors, etc (for me at least). For some reason when you proofread it by yourself, you tend to pass up a lot. That's why I try to have a friend proofread it also because they'll have a fresh look. The designer is probably so used to his (or her) creation by now that he's VERY likely to overlook MANY, MANY things that a person with a fresh look on the project won't. When a product has finally gone through its design and alpha stages it may function, but it's not going to be used by the public (much less purchased) unless it's absolutely flawless…well, for the most part at least. Sometimes it's impossible to get every little bug out of a program, but if one thing (even a little thing) doesn't seem right then the person that's using it will probably get the feeling that the entire product is flawed, especially if you haven't established yourself as a company. That's why it's important for you as a designer to get multiple testers on your project and for you as a tester to catch these bugs and report them. Some people think they can't get into a competitive beta unless they have the newest model computer, best graphics card, etc. This is not at all true. The company wants to make sure that their product works well on EVERYONE'S computer. They want a DIVERSE group of testers with all kinds of different hardware, not just people that have the latest stuff. Depending on the game and the number of applicants, a beta test can be HIGHLY selective, but your inclusion into these "HIGHLY selective" tests don't depend on your system specifications as much as it does on the kind of person you are. To get into some of these competitive betas you need to prove to the company that you're a dedicated tester; that you're willing devote lots of your time to TEST not just play games. The more enthusiastic you seem the more they're gonna want you. A Company also wants someone that knows about games. They wouldn't want someone testing their RTS game if the person doesn't know what an RTS game is, now would they? Same thing goes for RPGs, or any sports game…or ANY OTHER type of game for that matter. You should have a basic background on the genre to be an effective tester. If it's not a game you're testing then you should have a basic knowledge of the program and how it can be used or what it should be used for. Don't just blindly sign up for anything you see. It's a waste of time for both you and the company and isn't a way to gain experience. Alpha testing is quite a bit different than beta. The general public doesn't usually participate in this testing phase. Generally this is done in-house with the programmer and a few of his friends (employees in some cases), however there will be some chances for the public to get in on an alpha test. Alpha testing usually comes in after the basic design of the program has been completed. You will look over the program and make suggestions or give ideas to the designer to help improve it. You'll also report and give ideas to help get rid of or work around any MAJOR problems. Don't report the little things. There's bound to be a number of bugs after a program is created and the designer most likely knows about many of them. This isn't the main concern in alpha testing. When beginning a testing phase it works best for testers to have a set guideline, a summary, or checklist of some sort. If you're starting a testing phase for your product, try to implement this and let the tester know beforehand that they'll be expected to go through a specific series of tests. This way they're more likely to spend their time TESTING the game instead of just playing it. If you’re a tester and haven't been given any guidelines for testing, make up your own. It'll impress the designer if you write up a little report of the things you tested. It's also extremely important to COMMUNICATE with your testers. Even if there's not much to say just let them know that you haven't forgotten about them. Otherwise, most likely they'll forget about you. Sometimes those "unreliable testers" weren't really "unreliable" at all. It's just that they didn't think they were needed anymore. In many cases it's the designer's fault if a tester has become "inactive." I've been through my share of beta tests, and it's a different experience each time. It ranges from very pleasant and rewarding to "They must have forgotten me!" It's a rewarding experience when the producers communicate with me, acknowledge any ideas and bugs I've reported or testing reports submitted, and notify me of when the product's been released. It's also really nice to see my name in the credits or get a free final copy of the product (hehe). Discuss this article in the forums
See Also: © 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
|