image credit: https://www.flickr.com/photos/frenchista/7213719436

Back in 2007 I went to the StarEast conference in Orlando and among other sessions I took part in James Bach's workshop on Exploratory Testing. At that time I was working for a medical device company and I was in search for a better way to do testing. The workshop was enlightening and I thought it would be a good idea to spread the message to other testers here in Switzerland.

I sent in an abstract.

As it turned out, there was a huge interest in the subject and I ended up in front of 300 people at Switzerland's biggest software testing conference Swiss Testing Day in 2008. You can imagine the nerve-wracking experience I suffered through as someone who has never spoken publicly. I was so nervous that I had to remain seated in order to hide my shaking knees and I just hoped nobody would notice my insecure voice. What an experience that was!

There was no mentor to guide me through my first public speaking experience.

Of course I would have loved to have had an experienced person on my side giving me feedback on my slides and somebody who could teach me how to speak and handle my nervousness. Unfortunately, Speak Easy did not yet exist at that time.

In the years since my first gig I have spoken at dozens of conferences and I believe I have learned a thing or two about it. At least I now think I know how to prepare and I find speaking at conferences is a tremendously pleasurable endeavour. A little secret here: I am still nervous right before I go on stage. The difference is that I know exactly how my system is reacting and I also know how to handle it.

Sharing is a great thing and I am proud to be part of the Speak Easy mentor crew. Let's work together and make your session a success. I am looking forward to talking to you.

tags: public speaking, conference, teaching

In a book - I cannot remember which one - I read that if you print a math formula you will immediately lose 90% of your audience. I am free from worry here, because you - dear readers - are all nerds and number maniacs. So, I know you stay with me. And the ones who are about to leave soon, I’d like to offer some compassionate farewell words:

“Bye, Bye, and may you always remain unbothered and safe from formulas wherever you go .”

Ok, my dear socially awkwards, here we go. Something you often encounter in your tester life is the following:

k(a) > k(b)

whereby:
k = testing knowledge
a = e.g. Alice
b = e.g. Bob

let’s further define that “knowledge k” may consist but is not restricted to the following:

• number of books/articles about software testing or other useful topics read, understood and successfully applied in practice
• knowledge gained through collaboration with experienced masters
• empirically gained knowledge

let’s also further define that:

• Alice (a) and Bob (b) are human beings
• and more specifically testing human beings.

or to put it in simple words that wouldn’t have shied away 90% of the readers:

Alice knows more about software testing than Bob

So, both Alice and Bob work in your team. If your goal is to advance the knowledge of your people what would you do? And now comes the crucial question:

Who should teach whom?

Alice should teach Bob, of course, you might say. Now, let me tell you my dear friend that the gun shot answer to that question is wrong. Again, as you should know from your testing experience the obvious solution is at best incomplete. Same here. Of course Alice knows more about testing and can teach Bob quite a lot. But maybe Bob is a natural born coach and can therefore coach Alice. A coach is not somebody who knows more but somebody who can elicit self-learning in people.

Furthermore, they could together form a study group where the dynamics of the group helps them both to advance. And certainly advance more than if they had studied alone.

There are also some dysfunctional learning devices, such as:

• criticism: “I don’t like that you don’t know it better”
• demanding: “I want you to know that! Now!”
• ex-cathedra lecturing: “Test Plan, bla, bla, bla, bla, important, bla, bla, bla,….”

Let’s wrap up:
If your team wants to become really good at software testing it helps to constantly keep on learning. There are many possible paths to advance the groups knowledge. Choose the right paths. And: Just because you don’t like something (e.g. a formula) you shouldn’t give up right away. Be open for new experiences. There is no place for narrow-mindedness in software testing.

tags: coaching, teaching, skill, craftsman