On Guessing

by | Syndicated

While at #CAST2012, I visited each of the (maybe four?) vendor booths. I had good discussions at two of them (with test suite vendors, mind you), and even got two free shirts. (I’m a sucker for free shirts.) At the Telerik booth, I also snagged a sticker that reads “I never guess. I test.”

At the time, I thought it was cool and proceeded to stick it on my portable HDD. A few days later, it hit me differently. Is it true that I don’t guess when testing? Is guessing a bad thing when it comes to testing?

After thinking about it a bit, I realized we guess all the time in testing. For example, when you first start to test a new feature or module, you have to make guesses as to how it might work. Sure, you may have some info from dev on what the feature is supposed to do; maybe you even sat in on design discussions, if you were lucky. But when it comes down to test time, the first thing you are doing is looking for patterns to help you uncover bugs. You start out with an opinion about how the module/feature should work, without having sufficient evidence to support your opinion (otherwise, why would you be testing it?). The results of your testing ARE the evidence that either confirms or contradicts your guess.

That IS the definition of guessing.

No, really, it is. Look: dictionary.reference.com/browse/guess

  • “to arrive at or commit oneself to an opinion about (something) without having sufficient evidence to support the opinion”

When most people first begin a career in testing, they follow the recommendations of other testers, do what their developer told them to or follow a test plan/test case (without much deviation). This is fine in the beginning, as it gives you a chance to see how others do things and to understand the expectations for testers here.

In the end, we NEED to guess/speculate/conjecture/hypothesize to advance as testers, even if that goes against some of the more rigid testing methodologies out there. To make an educated guess is an intellectual activity. Testing should be a challenging, intellectual process.