One of the few tenets of Extreme Programming that I agree with is Pair Development. That's where you've got two people at the machine during coding...one writing code, another analyzing the code while it's being written. You often end up with higher quality code because of the additional analysis.
Testing has something very similar called Buddy Testing. If you haven't tried it, I highly recommend that you try it at least once.
Buddy testing consists of one (or more) drivers and one (or more) observers. For a multiplayer game, you'll want at least one observer per driver.
The sole purpose of the driver is to use the product. He's not looking for bugs, he's just acting like a user. If he happens to find an issue, he'll verbally call it out, but his goal is just to use the product.
The observer has two roles. The first role is to capture any callouts from the driver. The second is to look for bugs.
This may seem like a waste of manpower, and if it's the only way that you are planning on doing testing, it can be. However, for brief periods (one hour a day), it can be invaluable.
People use products differently than they test products. By just using the product, the driver is exercising different code paths than he normally would, so he's getting better coverage.
People also act differently when they test products. They're so focused on making sure they know what led up to where they are that a blatant bug can stare them in the face and they'll miss it. That's where the observer comes in.
The observer isn't using it. He's just looking for the bugs. Because he doesn't have to dedicate any brainpower to driving, he can focus more energy on the act of seeing what's wrong.
On "Sin Episodes," about 5% of the total bug count was found via buddy testing, but those 5% were some of the strangest bugs in the database.
If you are currently working on a product and haven't tried buddy testing, give it a shot. The results may surprise you.
gross less e-teen
No comments:
Post a Comment