Huh? Really? So?

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"...

Best Practices (NOT!)

I've been a lazy boy with updating the English version of my blog. I'll whip myself into blogging frenzy and update the blog as often as possible. My first addition to my posting is my most frequent blogging on my Finnish blog.

For some reason I stumbled upon the JMB blog about maturity models and the critisism thereof. Within the posting there was a link about No Best Practices.

Our company has recently began its Quality Assurance project which is designed to raise the quality of all aspects of the company, from management and sales to code development and support. The thought struck me that "hey! We could improve the quality of testing as we increase the overall quality" and thus I started to think improvements through the company as a whole. The testing organization within the company should be revised and to make it more coherent and more effective. After a little brainstorming I ended up refining testing process, clarifying roles, increasing the testing skills and increasing the visibility of testing as a craft within the company.

Thus became the idea about testing architect and testing steering group. (Yeah, we aint that far in testing yet...) We already have a plethora of steering group and their main goal is for

sharing best practices, tools, frameworks and code.

Yay! Fun fun! Best practices! When all developers go by the best practices things can't go wrong, can they? Can they? Will they?

I myself strive towards continuous improvement in testing. Everything should be better than one done before. Besides I'm a bit of a context-driven test enthusiast and I like to hear what ye olde JMB has to say about stuff. (No offence, Michael Bolton!) Every single pratice, method and technique is attached into relevant context and time. With both of these being variable is it possible to say that a practice is best? Is there a practice that is better that the Best? If so can it really be said that a pracitice is best?

Could it be so that men (and women also) tend to veer towards practices that are already developed in some context and in their laziness or schedule pressure take these practices as graneted? Some people may use a certain method in his or her work and ignore more effective, more reasonable models and practices. Some people base their work on ".Net Best Practises" and nothing else and make that kinda code all their life.

Then there are people who innovate; break habits, patterns, prejudice; and challenge authorities! These "better practicists" and the force that drive every industry forward: they don't linger inte the artificial Best Practices but push through and take their work into another level. The others may imitate them and claim their practices as BEST. Just then the innovator carries on his or her work and strives for higher and higher.

Which one you are: Best practice person of Better practisist?