This column isn't for you; it's about you. Linda Hayes wants to find out what it takes to be successful in the testing profession these days—if such a thing is really possible. Too many good ideas, such as incentive and recognition plans, have backfired. Linda feels there are a few good practices out there, but she needs your help to find them.
One of my best friends manages a software QA team at a company that is legendary for being a fun place to work. But her job is sucking the life out of her. She knows her stuff and is good at it, but she is being ground down by long hours, absurd expectations, and management frustration. It's like she's expected to bend the rules of reality to magically make schedule delays disappear and missing deliverables appear—which she can't do. After a long career in software testing, she is now actively evaluating alternate professions.
Which brings me to wonder: What does it take to succeed in software testing in the sense of enjoying your job, feeling a sense of pride and accomplishment, and being rewarded through both recognition and compensation?
After founding three software companies myself and spending over twenty years in testing, I'm embarrassed to say I still don't have the answers. We all know the drill: Testing is inevitably squeezed at both ends of the schedule by scope creep and deadlines based on wishes and not work. Finding problems does not make you popular, but neither does not finding them. Customers don't call to congratulate you for the issues they never encountered. It often seems your only measure of success is that nothing terrible happens.
Yet bonus programs usually backfire. If you base rewards on finding bugs, you create an incentive to dive into the weeds but not to run regression tests that usually work. Anyone can find a problem if they try hard enough, but exposing errors that are far outside the envelope of expected usage often brings derision from developers and risks diverting resources from higher risk, yet routine activities.
Rewards for reducing post-release defects only work if testers have all the time and resources they need and have a say in when the product is ready. Yet, they cannot be the sole arbiters because in the end it is a business decision. And, to be honest, it's not often that testers are ready to pronounce a product defect-free—if for no other reason than you can't prove a negative.
Bonuses for making schedules create conflict as well. Developers are motivated to expedite code delivery, but low-quality code slows everything down for testers as they are forced to spend their time documenting issues and re-testing fixes instead of completing or expanding their coverage. Assuming there is some objective criterion for release, such as "no high severity defects," the end result is often a debate about severity rankings and whether the loss of the bonus outweighs the risk of release.
But surely there must be ways to provide incentives to testers that motivate, recognize, and reward them—right? If so, I would like to find out about them and let the rest of the world know.
To end what otherwise might be a whiny, depressing column on a high note, I really look forward to hearing from you. I harbor the hope that others have broken the code (so to speak) and have discovered a formula for making the software testing profession an attractive and rewarding career. Please, prove me right.
Editor's Note: Find out if readers proved Linda right or wrong in State of the Industry.
