As testers, we spend our day questioning whatever it is that we are testing. Things like

  • Is it secure?
  • Is it accessible?
  • Does it meet the requirements

are all fodder in our quest for information. What I have been finding useful the last little bit are questions of a different sort.

  • Why? – This simple question has a tonne of power. Not only does it force someone to think about why they are doing something, but it forces them to do it in a way that can be articulated. I’ve seen it a bunch of times when a developer is explaining an implementation strategy and suddenly realizes that there is a pretty big mountain in their way. I’ve also crawled my way out of a few rabbit holes by asking myself it. I suspect that “I don’t know” is even a good answer, though maybe not that great for your product. (You can, if necessary, use this one multiple times during a conversation.)
  • For how long? – This question is useful for uncovering design assumptions. Here is an illustration of a variation of this (more or less) taken from an open msn window:
    • Developer: Since there are only 4 message types, we’re going to use 1 template and fill in things dynamically
    • Me: This requirements document is changing weekly, how long until they add a 5th? Or 6?
  • (which leads us to) what would happen if … ? – This can be either an out-of-the-blue question or a follow-up to one of the previous ones. To use the preceding example, I added “When they do add another, what do we have to do? Lots of coding? Little coding? Does the design allow for that situation elegantly? Without having to kick the server?”

The common element between all these questions is that they create greater understanding of not only the product, but the thought processes and rationale of the people creating the product and if used properly, yourself as well.