Blog: Deeper Testing (1): Verify and Challenge

What does it mean to do deeper testing? In Rapid Software Testing, James Bach and I say:

Testing is deep to the degree that it has a probability of finding rare, subtle, or hidden problems that matter.

Deep testing requires substantial skill, effort, preparation, time, or tooling, and reliably and comprehensively fulfills its mission.

By contrast, shallow testing does not require much skill, effort, preparation, time, or tooling, and cannot reliably and comprehensively fulfill its mission.

Expressing ourselves precisely is a skill. Choosing and using words more carefully can sharpen the ways we think about things. In the next few posts, I’m going to offer some alternative ways of expressing the ideas we have, or interpreting the assignments we’ve been given. My goal is to provide some quick ways to achieve deeper, more powerful testing.

Many testers tell me that their role is to verify that the application does something specific. When we’re asked to that, it can be easy to fall asleep. We set things up, we walk through a procedure, we look for a specific output, and we see what we anticipated. Huzzah! The product works!

Yet that’s not exactly testing the product. It can easily slip into something little more than a demonstration—the kinds of things that you see in a product pitch or a TV commercial. The demonstration shows that the product can work, once, in some kind of controlled circumstance. To the degree that it’s testing, it’s pretty shallow testing. The product seems to work; that is, it appears to meet some requirement to some degree.

If you want bugs to survive, don’t look too hard for them! Show that the product can work. Don’t push it! Verify that you can get a correct result from a prescribed procedure. Don’t try to make the product expose its problems.

But if you want to discover the bugs, present a challenge to the product. Give it data at the extremes of what it should be able to handle, just a little beyond, and well beyond. Stress the product out; overfeed it, or starve it of something that it needs. See what happens when you give the product data that it should reject. Make it do things more complex than the “verification” instructions suggest. Configure the product (or misconfigure it) in a variety of ways to learn how it responds. Violate an explicitly stated requirement. Rename or delete a necessary file, and observe whether the system notices. Leave data out of mandatory fields. Repeat things that should only happen once. Start a process and then interrupt it. Imagine how someone might accidentally or maliciously misuse the product, and then act on that idea. While you’re at it, challenge your own models and ideas about the product and about how to test it.

We can never prove by experiment—by testing—that we’ve got a good product; when the product stands up to the challenge, we can only say that it’s not known to be bad. To test a product in any kind of serious way is to probe the extents and limits of what it can do; to expose it to variation; to perform experiments to show that the product can’t do something—or will do something that we didn’t want it to do. When the product doesn’t meet our challenges, we reveal problems, which is the first step towards getting them fixed.

So whenever you see, or hear, or write, or think “verify”, try replacing it with “challenge“.

Want to know more? Learn about Rapid Software Testing classes here.

4 responses to “Deeper Testing (1): Verify and Challenge”

  1. […] Deeper Testing (1): Verify and Challenge – (DevelopSense) […]

  2. […] Deeper Testing (1): Verify and Challenge Written by: Michael Bolton […]

  3. Mark Tolfts says:

    “Testing is deep to the degree that it has a probability of finding rare, subtle, or hidden problems that matter.”

    What do you mean by ‘hidden’ in the context above?

    Couldn’t all bugs, to some degree, be considered hidden? A tester must explore the right areas and apply the right oracles to reveal them.

    Michael replies: All bugs are, to some degree hidden. Some bugs are more deeply hidden than others; and some bugs are hidden to some people while obvious to others. Some bugs are right there on the surface such that practically anyone could observe them (start the application and it crashes). Other bugs lurk for years without anyone at all being aware of them.

    So yes: to do deep testing and to find deeply hidden bugs, a tester must diversify and extend his/her models of coverage; must have a rich set of oracles by which he/she might recognize problems; may need a powerful set of tools to amplify his/her ability to reveal those problems; may need better testability to lift the lid on deeply hidden problems.

Leave a Reply

Your email address will not be published. Required fields are marked *