Testing Top Ten

Since I'm going to be returning to my roots as a tester after fifteen months as a developer for my home town, I've been trying to...well...revive my testing skills.

While the best developers and testers have similar mindsets, there is one core tenet which differs between testers and developers. A developer asks, "How can I make this work?" A tester asks, "How can I make this break?"

My manager here at the city has even pulled me aside on several occasions and complemented me on the quality of my work, although he did it in a bit of a backhanded way. He said that I'll often hold a product back until it meets my quality bar, even though it's fully functional. Personally, I see absolutely nothing wrong with that. While I built auto-update functionality into every product that I've released here at the city, I think that the perfect measure of our quality is how often we have to use it for bug fixes rather than new feature releases.

So, now that I've lived some time in both sets of shoes, it's time for a top ten list.

Top 10 Things That A Tester Needs

10. "How to Break Software: A Practical Guide to Testing" by Dr. James A. Whittaker. If you are a tester and you have not read this book, you have a choice. You can either a) go out, buy the book, read it and improve ten-fold, or b) wallow in your own mediocracy.

9. An extremely durable stress ball. Testers are the bearers of bad news more often than not, and as such receive massive amounts of abuse from other team members. A stress ball gives you a means of relieving your stress without killing someone.

8. A large pad of paper and at least three pens. Never give a tester a pencil. A tester should write his or her first impressions of anything. A tester should make notes of all steps that he or she takes. If a tester second-guesses himself, there should be a permanent record of that second-guessing. Whenever a tester erases something, a tester eliminates the potential to go back to an earlier assumption.

7. "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins. The more information that a tester can give his or her developer, the better. This book is by far the best guide to debugging Windows programs I have ever found and includes not only tips on managed debugging but massive sections devoted to debugging native Windows applications.

6. A wall or desk calendar with plenty of space to write notes about upcoming deadlines. Yes, you may have everything in Microsoft Project, but I don't care. Having the calendar also gives a written history of the project so a tester can have more information available to properly attempt to forecast things such as the zero-bug bounce.

5. A stopwatch with a large, readable display. Unless I need to time something that is going to take less than a second, I'd rather rely on a stopwatch than your timing code. Why? The stopwatch won't inject additional code and page faults into your application.

4. A constructive hobby. The testers that I have found have the most longevity are ones who have had hobbies where they make something. Programming, woodworking, miniature painting...anything where you are not actively destroying something. A tester without a constructive hobby is a tester who either burns out in six months or a closet sadomasochist.

3. At least two computers. One computer should contain the tester's mail client, bug tracking software, music, IM, Office, Visual Studio for remote debugging, etc. The rest should be a test-only machine that can be wiped and re-imaged at a moment's notice. (Two monitors are also nice, but if you get a KVM, try to turn off the ability to switch machines via keyboard commands. I've had several manual tests ruined by the keyboard shortcuts included in major KVM's.)

2. A VCR that can record the video-out of the test rig. Having a VCR that records your actions has three benefits. First, you can go back and verify that you didn't do anything you didn't write down in your notes. Second, you have definitive proof that the bug occurred, even if you can't get it to repro. Finally, when you go talk to your developer and hear, "It works on my box," you'll have something hard to throw at him.

1. A dog-eared copy of "Soldier of Fortune" magazine sitting on the corner of your desk. Nothing makes a developer think twice about resolving one of your bugs "Not Repro" than the nagging thought in the back of his or her mind that a tester will remove a panel from the ceiling above them, slowly lower themselves down and drive an eight-inch hunting knife into their lower skull...or so I've heard.