Snaring Black Widows in Ladybug Clothing


Everyone on the project can play a role in preventing bad software from escaping.

So what advice would I have for the testers at Doris's company for their next release?

  1. Stop the blame: Blame gets in the way of learning. Don't accept blame and don't dole it out.
  2. Find extreme cases: Find ways to turn minor glitches and occasional anomalies into major problems or frequent errors—even if that means doing things "no user would ever do." Users have a funny way of doing what no one expects. Although the testers at Doris's company were never able to make the software crash reproducibly, they later learned from field reports that the crashes seemed to occur more often when the system was under load or the user did things at unexpected times. The testers then used this information to make the software crash consistently in twenty minutes instead of once a week.
  3. Explain the impact of bugs: Make sure the bug report describes the effect of the bug on the end user. A bug titled "uninst.isu file missing" may be correct, but a bug titled "user cannot uninstall" is much more compelling.
  4. Champion serious bugs: If you believe that a bug will cause serious problems in the field, fight for its correction. Don't accept excuses like "too risky to fix," "no user will do that," and "there's a workaround" at face value. Ask questions. "But what's the risk if we don't fix it?" "How do you know no user will do this?" "What if the workaround isn't acceptable to users?"

As a tester, I get a sinking feeling in the pit of my stomach when I hear that there's a problem in the field with the software I tested. I feel even worse when it's a problem we knew about but let go because it seemed mostly harmless.

Now I look for fangs and stingers on all bugs, no matter how innocuous they seem at first. "Oh, that's cute. You can make the program do something it shouldn't," becomes "And I wonder what side effects that might have? Let me just edit this thing here and delete that thing there. Oh look! Corrupt data!"

Whenever I'm able to expose a harmless-looking, gnat-sized bug as a blood-sucking monster, I cackle. I can't help it. I'm just elated to have thwarted the bug. "That's one more nasty defect that won't make it to the real world to hurt users. Mwa-ha-ha-ha-ha-ha." Blaming is counter-productive, but quiet cackling in the privacy of your workspace can be downright therapeutic.

Just don't let the programmers hear you.

About the author

Elisabeth Hendrickson's picture Elisabeth Hendrickson

The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at and can be found on Twitter as @testobsessed.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!