How well do you know your testers? There are several tester stunts I have been tempted to pull (and sometimes have). The act of testing is difficult to monitor so it is easy for testers to spoof productivity. If you catch yourself doing these…don’t.

Whenever team members stop by your desk, make sure you have a GUI automation test running on one of your boxes. It looks really cool and gives the appearance that you are an awesome tester (they’ll never know it’s just a looping record/playback test with no verifications).

Your manager needs to see test cases. How about just copying the requirements into something called a test case?

You didn’t stumble upon that bug (yes you did). It came from a carefully planned test.

There is no evidence of what tests you executed because you kept track of them locally (not really). You will upload the tests to the repository when you have time (yeah, right).

You didn’t forget to log that bug your dev is asking about (yes you did). You are still reducing the repro steps down to the bare minimum due to some variables that may be related.

You didn’t forget to execute those tests (yes you did), you choose not to execute them because you performed a risk assessment matrix resulting in a lower priority for said tests.

When running performance tests using your wrist watch, record time span values out to the millisecond. It appears more accurate.

Does your manager review your test cases or just see how many you have written? If it’s the later, find the copy/past option in your test case repository and change one value (e.g., now pass in “John”, now pass in “Pat”, now pass in “Jill” etc.). Dude, you just wrote 30 test cases! It looks great on the metrics summary page.

If you’re lost at the Feature Walkthrough meeting, periodically raise your hand and ask if there are any “ility” requirements (e.g., Scalability, Usability, Compatibility, etc.)…it just sounds cool to ask.

You don’t have a clue how this feature is supposed to work. If you wait long enough, another tester will take care of it.

This seems a great way to make sure you aren't measuring things that don't matter. None of these build tester reputation that lasts. That takes good test ideas that work over time and consistently finding important bugs, or even better, preventing them or finding them early so that developers will vouch for your testing abilities.

Eric, none of those stunts would work with me, but I suppose that's because I've Been There, Done That. So perhaps your blog should have mentioned that the person you're trying to impress needs to be Clueless. Otherwise you could end up drawn and quartered in public to serve as an example to your peers...

In the projects that keep track of testing using tool like Quality Center (Test Director), while doing a retesting just click on "Pass All" button. Shows how efficient you are. And obviously you trust the tester who tested before you, else you can always blame the nightly build.

:D

Don't log all the bugs that you find. Save some for a rainy day. (unproductive day)

Who am I?

My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.