Software Testing is NOT "Breaking Things"

For some odd reason, I really don't like it when software testers say "I enjoy breaking things".

copyright © 2005 by Martin Hoffmann and Fred Mellender

When you test and find a bug, you haven't broken anything - it was already broken!  If anything, the developer who wrote the code broke it.

And now that you have found a breakage, your job has just begun.  You need to dig in much further:

• Under what conditions does this break occur?  Under what conditions does it not occur?
• What steps are required to reproduce this break?  And can you express those steps in simple terms so that developers and other testers can see it for themselves?
• Can you gather related symptoms, logs, images, etc - to help make fixing this break simpler?
• How long might it take to test a fix for this break?
• Is this break indicative of a more general problem?  How will we know?
• Does the presence of this break, or a fix for this break, mean we should re-execute some of our tests?  If so, which ones?
• What risks does this break expose?
• When did this break get introduced?
• Was it possible to find this break sooner?  If so, why didn't we already find it?
• Should we modify our testing processes to find breaks like this more effectively?

If you enjoy breaking things, perhaps demolition is a good profession for you.

But if you enjoy planning, conducting, and analyzing the results from controlled experiments designed to find existing (or potential) breakages, then software testing might be right for you.