Listening Vs. Hearing

Yesterday I wrote about the role of Testers and how Testers should listen. Pretty straight forward, no? Just listen. Simple.

I find the challenge to be actually listening for what is said. Not for what you think is being said or what you want to hear.

Did you ever play "The Telephone Game"? The one where a person whispers a sentence to another person, then they pass the message on to the next person. They tell the next person and it goes on until it gets back to the first person.

Usually, well, pretty much always, there is no resemblance to the original sentence.

Our challenge - Our biggest problem - is making sure that the message that we are hearing is what is really being said.

I recently had the opportunity to play a testing game with some other testers. Not the dice games of Michael Bolton (and others) and not the card game of Lynn McKee and Nancy Kelln. This game was a simple word game.

I gave clues to a puzzle and then had them ask Yes/No questions around those clues to get the solution. These testers did eventually get the correct answer.

The interesting thing was that when they repeated the puzzle, they stated it differently. It wasn't wrong, just, different. Things that were actually answers to questions were integrated into the "original clues." This changed the dynamic of the puzzle slightly, but not terribly.

It struck me that if a simple game like this can go awry, how much easier is it to get requirements or "business purpose" wrong when you may not be terribly familiar with the field or industry? Can we, as testers, test our own suppositions about what is "right" to the point where we can arrive at the same conclusion of the need as those on whose behalf we are working?