Picking the Customer s Brain (and the Programmers )

Picking the Customer's Brain (and the Programmers'!)

Some things will be obvious, and you should be able to come up with them yourself and not bother anyone, even for confirmation. Some things you'll have to run by the customer or programmer, but you can still do a lot of the work beforehand to make it easy for them. And some things will require them to really think about things that haven't yet occurred to them. This may not always be a pleasant experience, because in the process they may realize that other things they thought were done need more work.

The idea of coming up with even the most obvious acceptance detail on your own authority, without running it by the customer to approve, may be scary at first. Likewise with the predictions of how the system will work in a hypothetical situation. What if you're wrong? Who are you to say even one iota of how the system should work? Or how it will work?

Well, if you're wrong, you're wrong. No big deal. As programmers, we don't ask for every itty-bitty detail of how the system should work. We use our skills and experience to fill in all kinds of gaps; otherwise we'd never get anything done. As programmers, we get it wrong part of the time, and we will also as testers. As a tester, it's your job to fill in your set of gaps and bear some of the risk of being wrong too.

If the customer and programmers have limited time to answer your questions (which we've found is often the case), you want them to spend it answering the ones that make them think that break new ground. The risks associated with never getting to these (because all the time got spent on the easy ones) are greater than those of getting a few easy ones wrong.

Deciding which items you can feel confident about, which require confirmation from the customer or programmers, and which require you to ask open-ended questions is something of an art, but the basic approach is easy to understand.

When you have absolutely no clue about what the answer should be or how to determine what it should be, you really have no choice but to ask the open-ended question (to the customer: "What should the system do if …?" To the programmer: "What will happen if …?").

If you have a pretty good idea that the answer is one of a few different possibilities and you have reason to pick one over the other (it's the simplest, quickest, easiest …), ask for confirmation of that possibility among the alternatives ("If … happens, the system should/will …, right? Or should it …?").

And for the ones where you're pretty sure what the system should or will do, just go ahead and write those up without asking. The customer will be able to go over every detail of the tests if he wants, so you'll find out if you made incorrect assumptions.