Michael Bolton mentioned his collegue James Bachin to be using an extremely effective questioning technique: "Huh? Really? So?" I decided to have a go with it and I've been using it to question my own preaching and blogging.
Huh? Say what? Excuse me?
Have you ever sat in a meeting where some a "development hero", ranting like a king, explains fancy processes or summarizing a thing you've never heard of? You've been invited to the meeting because the subject MIGHT have importance in your doings or might fall in your area of expertize (the normal criteria for meeting invitation). The person in front of the white board talks, points out graphs of flow charts, and every other person in the room either doodles stick figures in their note books or is playing with their mobile phone. Some might even be looking at the "hero" believing they might understand something.
At this point a tester says "Huh?". Every single person in the room looks at the tester as if he/she had said something really stupid - especially the "hero". "What does all of this really mean? What is the point? Can you explain this in a way that a tester understands? I may not have gone to every technical school and university or done development for decades so I don't understand everything you say. Is it even neccessary for me to know these things? Judging from my presence here I believe I should understand these things. So, can you spell it out for me?" At this point doodling stops and the mobiles vanish.
The others might think "That's a clever tester. Darn! I wish I had asked those questions 'cause I really don't have a clue what's this all about." Probably none is thinking that tester is stupid for asking such ovbious questions. Pehaps the "hero" will explain the things a bit more clearly, in higher or lower level (which ever is more clear in his opinion)r. After this most people in the meeting lean back on their chairs and start doodling... "Sorry... I still don't quite get how this works. Does it really go like that!"
Really? Are you absolutely certain?
The "hero" looks at you disbelieving and says "Yeah, it goes like this." When asked for an example in practice the attention comes back to those who just previously lost it. Now the "hero" explains the process in more practical level or from another point of view. At this point the tester asks "Have you thought the case X? Or the cases X1, X2 and Y8?"
The others are probably thinking "Should I have known these things as I was with the Hero developing this stuff? Should I have asked those questions already? Am I as smart as I think I am?" The "hero" is most certainly asking these questions (or becoming irritated with the tester). When the "hero" has managed to asnwer the questions or skillfully dodged them the crowd relaz again. "Hero" might make an action point to look into the questions later, who knows... "So what is the essence of all this? Why are these thing even presented/teached/etc.?"
So? Where does this all lead? So what?
And once again the groups attention grows. "This might be interesting. The next sentence may just affect my future and my work."
Testers job is to raise questions and issues that others have not yet thought of. The job is to offer information related to the context to the stakeholders that are interested on the subject. Testers are stakeholders so lots of things should interest them and their job is to demand the information that they need. There are no stupid questions - there are just questions thought to be stupid until someone asks them. Usually it's even more stupid not to ask! These "stupid questions" have a tendency to raise more important questions that need to be asked - questions no-one has asked before. Use this heuristic in the future meetings and be critical. Question your own work where you question others.
Most probably the crew will ask the things from tester after the meeting rather than the "hero"...