image credit: http://j.mp/JSuYkO

As the title might suggest, there is a mix of different ideas and questions in this post. We may even have Virginia Satir coming for a short visit. But at the end you will see - I hope - that everything is connected.

Very recently

I am not the only one who is convinced that reality is a social construction. There is no truth as such in pure form. Or as the saying goes, there are 4 truths; mine, yours, “The Truth” and what really happened. For those among you who understand German, I highly recommend episode 23 of the excellent Alternativlos podcast. You may listen to “Verschwörungstheorien, die sich später als wahr herausstellten” here.

What concerns me, is the major consensus narrative. It is what the majority has agreed on to be true. To link that to the context-driven school of software testing: Are we in love with the idea of having found “The Truth”? Do we run in danger of reciting self-enforcing mantras that might be wrong? How do we know if we wander astray?

These are important questions that need to be asked. Martin Jansson - on the other hand - reported on his test lab experience at Let’s Test conference and told how some of the more seasoned testers almost brought his efforts to a halt by not stopping to ask questions. Paul Holland told the story of James Bach having become an unstoppable questioner at a peer conference.

Is it always good to ask questions? How long and how many? When do I stop? Is it a “Just because I can” attitude to prove that I am hyper-smart? I have a potpourri of questions I recently asked myself:

1. Is there a moment when asking questions becomes counter-productive?
a) If yes, when exactly and what does happen then?
b) If no, how do you know?

2. Does puzzle solving make you a better tester?
a) If yes, what exactly is the mechanism?
b) If no, is the effect neutral or negative?

3. Should we bash certified testers who are proud of their certifications?
a) If yes, what do we want to achieve with that action?
b) If no, why do we let these people spread ideas about bad testing?

4. Is having a high intelligence level a prerequisite for being a good context-driven tester?
a) If yes, what definition of intelligence is applicable?
b) If no, how can it be substituted and by what?

5. Is it true that many tester struggle with what a heuristic and an oracle are?
a) If yes, what is your explanation that it is so?
b) If no, where is your data?

6. Can YOU give a quick explanation to somebody who doesn’t understand the concept?
a) If yes, how do you know you were understood?
b) If no, what part are you struggling with?

7. Is there a subject/topic that has no relevance whatsoever to the context-driven software tester?
a) If yes, can you give an explanation that entails detailed reasons of its inapplicability?
b) If no, how come?

I have my answers to the questions. But, please, my friends, post YOURS in the comments below. I would love to see a variety of reasonings.

You may have asked yourself at the beginning of this post what the fragment “Very recently” was doing there without culminating in a full sentences. That is a valid question. You might even have formed a hypothesis about what it was doing there. “Just an editing error”, “probably a section title”, “haven’t noticed”, “maybe it is clickable”, “semantic ambiguity of hypnotic language” could have been some of the guesses.

I promised in the entry sentences that at the end everything will be connected. Actually, it is not at all; this post is very messy. Please, don’t shout at me because of that. And Virginia Satir might be in one of the next posts. I’d definitely like to talk about her.

tags: testing, context-driven, truth

Many of us have put on weight during Let’s Test because of a combination of fantastic nordic cuisine and an abundant availability of Swedish micro-brewery beers. For me it has been an overwhelming experience and I feel very privileged to have been part of the first Let’s Test conference.

But, what is it that made it great? What’s the secret sauce?

One approach could be to list elements such as:

• fabulous location and facilities
• good food
• great beers
• interesting sessions
• format of the sessions with facilitated discussions
• cool people
• the nicely foldable program
• perfect WIFI coverage
• friendly approachable organizers
• the sunny weather

Only that I don’t think that explains anything. In order to perceive it as great, there must be something else. And I think it is the dynamics created by a combination of factors. Like a tasty sauce, it is the balanced combination of ingredients in interaction with each other, which makes it mouth-watering.

Many of us know each other on Twitter, we have had conversations on blogs and discussed stuff on a Skype chat. At Let’s Test I have met many of my tester peers for the first time in person. There was already a lot I knew about these people. Some of them had sessions and my excitement about it was already great before they started. Also, during a session it was well possible to have e.g. my BBST Foundations instructor Ru Cindrea to the left and Anne-Marie Charrett, with whom I have discussed Skype coaching a lot, to the right. Hence, it was like a family & friends gathering.

A unique aspect was the extensive evening program with art tours, test lab, social gathering, XBox games, free beer and a mind blowing band that played some sort of beautiful eastern style klezmerish music and had a violin player who made my jaw drop. Now, this was combined with having taken place in a room that looked like a massively oversized living room with candles on the tables. At the same time there were Oliver Vilson’s metal and wood puzzle making turns among the people. Hence, it was like a family & friends gathering.

Free beer can help to become sociable. The guy at the bar was a friendly tall Swede with a goatee and oversized earrings. I am no longer in my 20s, but Let’s Test made me behave like one who is. Long, beer-saturated nights that created difficult mornings, where people were glancing at each other knowingly. Oh, man, what a laugh we had during the late night conversations. Hence, it was like a family & friends gathering.

If you gather a group of people and everybody just wanders off after the sessions, then there is no soul to it. Runö is somewhere out in nowhere and it kept the whole group together. Interaction was inevitable. Wherever one walked there were people to meet. Smiling was a facial activity that was used extensively. Hence, it was like a family & friends gathering.

Are there dangers for the future?

I guess there were roughly 150 people at this year’s conference. Many of them will go back to where the come from and tell their friends and colleague about their positive experience at the conference. People following the #LetsTest hash tag on Twitter also mentally constructed their impression of the conference. They will all want to come to next year’s conference. In my opinion the success of Let’s Test may become a liability.

Why so?

I think that what I perceived as the soul of the conference - a friends & family gathering - may get lost if there were twice or three times more people. I am not sure if bigger is always better. The conference would suddenly become more anonymous and that could destroy the dynamics mentioned above.

How to avoid it?

Surprisingly there is a beautiful and straightforward solution to it: Do it at Runö again. Just checked their website and it says there are 228 beds, which quite effectively limits the number of participants.

Anyway: Ola, Henke, Henrik, Tobbe, Johan & all participants, I love you all for having made this conference possible. You guys rock, and hopefully see you next year.

tags: conference, context-driven, skill

Have a look at Paul Holland’s facial expression. it makes you chuckle, doesn’t it? That is because Paul has not had a long enough rest. And that is because we had a joyful night at Runö. Let’s continue this post with some images and have the text for another time.



Ben Kelly had a both very entertaining and troublesome presentation on the testing dead.



Alan Richardson talking on testing hypnotically.



Anne-Marie and me injected a coaching session into the test lab assignment.



Runö is such a beautiful place.

tags: conference, context-driven, skill

I initially planned to write this update before the conference started but I achieved to deactivate my alarm clock at 7am when it rang and fell asleep again. That resulted in me waking up again at exactly 9am. That’s the official starting time. I jumped in my jeans, grabbed my messenger bag with my stuff and ran. I managed to arrive exactly at the time when Ola started talking.

Yeah, well, who is perfect. Perfection is unappealing anyway, isn’t it? To have shortcomings is what makes us human.

Alright, we had a very good Sunday. Oliver Vilson brought some cool puzzle gadgets to play with and Runö started to fill up with testers. We seem to have the whole compound for our sole use and it is a beautiful place because it does not feel like a cold conference center at all. It’s more like being with friends at a holiday retreat.

We discovered that Henrik Emilsson is my unknown brother. Have a look at both of us here:



Paul Holland gave a group of us a very useful introduction into LAWST-style facilitation. Every session will be facilitated and I am looking forward to the session on Wednesday I am going to facilitate. Great, haven’t done that before.

Later on Sunday many of the people I converse a lot on Twitter and Skype, etc., arrived. Hello my tester friends:

Huib Schoots
Simon P. Schrijver
Tony Bruce
Anne-Marie Charrett
Michael Bolton
Duncan Nisbet
Markus Gärtner
Joep Schuurkes
Christin Wiedemann
Scott Barber
Zeger Van Hese
Alexandru Rotaru

Exellent conference and especially the food deserves an honorable mention.

tags: conference, context-driven, skill

My flight had a very interesting route display. Zurich has suddenly changed its name to Düsseldorf and Antwerpen was relocated to somewhere in the south. I just hope there is no connection between the passenger display and the pilot’s navigation system.



Anyway, we arrived well in Stockholm and I met James and Dessi Lyndsay at the airport. We shared the taxi to Runö. So, that’s the start of Let’s Test then. Runö is a nice and quiet retreat on the country side and I think it is the perfect location for a conference.

We had a nice dinner with Ola Hyltén, Henke Andersson, Henrik Emilsson, Tobbe Ryber, Johan Jonasson, James and Dessi Lynsey, Ben Kelly, Julian Harty, Paul Holland, Chris and … hm, what was his name again? (UPDATE: Thanks, Neil. Yes, it’s Neil Thompson. My memory would like to apologize for not remembering)

Honoring the Scandinavian tradition we proceeded to drinking and had a a lot of fun as can be seen in e.g. Ben Kelly’s Tweet:



After midnight I had some BBST Foundations work to do and I had a very hard time reading and understanding the text of the quiz. Shouldn’t do that likewise for the next deadline.

tags: conference, context-driven, skill

Checked in at ZRH and the check-in machine shut down with an error message while printing out my baggage tags and my boarding pass. At the baggage drop the lady asked me where my third suitcase is. No third suitcase. She apologized and said there was something wrong with the computer system.

Then going through the scanners, placed my boarding pass, my ID card and my flat cap in the bin for the scanner. After the scanner my ID has miraculously disappeared. Strange kind of bug. Disappearing objects. The security people helped me search for it but then the ID card reappeared; it was between my flat cap and my head. Embarrassing, but happy it was not caused by a bug.

Now waiting in the lounge for my plane that takes me to Let’s Test. Oh man, cannot wait.

tags: conference, context-driven, skill

image credit: http://j.mp/HAv17F

The best lessons to learn are the ones that happen to yourself. This week, I experienced a schoolbook example of such a thing. I was making a bunch of assumptions and didn’t care to verify them. Today, I shake my head in disbelief.

What happened?

On Monday, 9 April, Ajay wrote in a short tweet that he was disappointed with the syllabus of an online course. The course was published here:

http://www.qualitytesting.info/forum/topics/certifications-might-get-you-job-but-only-your-testing-skills-wil

and the syllabus here:

http://qualitylearning.in/software-testing-syllabus
(it has already changed to the better in the current version)

I then asked him what he meant by “disappointed”. I was also shocked because I knew that the online course was supposed to be given by Savita Munde whom I hold in high regard as a serious tester. I have been coaching Savita for some time and I just couldn’t believe what was happening.



Both James Bach and Michael Bolton followed up with their own tweets supporting Ajay. I became angry and wrote back:



Following that I had a back and forth discussion by e-mail with James Bach where I tried to defend Savita. My point was that since she is a serious tester she cannot be criticized like that. I couldn’t stop. I was angry.

Apparently my thinking was shadowed as well. All the time I did not talk to Savita directly although it was exactly what I should have done. In the meantime the syllabus was changed and when I eventually talked to Savita she told me that the syllabus was a mistake and not published by her.

Always test your own assumptions

I am glad this happened to me because it taught me again that I need to be on guard against my own assumptions.

BTW: Read also Ajay’s blog post about it. I bow to him for his deeply human and fair reaction to the whole story.

After some iterations of thinking I came up with the following decision graph. I may be of great help the next time I make an assumption. The good thing is that it is quite simple.



Has something similar happened to you? Tell me in the comments below. I am very much interested.

tags: testing, assumptions

image credit: http://j.mp/HcxgtA

If you don’t live in a box shielded from everything I am sure this has happened to you: You tried to understand something and your brain just doesn’t get it. This may be uncomfortable for a context-driven tester as learning new things is quite essential to being context-driven.

There is a fabulously simple solution: Just give up

Assuming that you do not see this short and easy solution as a fit for your character disposition I guess we would have to go on with a longer elaboration.

Now, a common misconception is that your brain works like a hard disk. Here data, there hard disk, file -> transfer. And voilà, you’re set. Just not so.

If you don’t get something, then the following happens: As soon as your brain gets input the synapses start to fire happily their little electrons and look for pre-existing structures to attach your new input to. But in this case there just isn’t any place to be attached to because the input is new and different and weird and difficult and doesn’t quite fit anywhere. Then your brain becomes sad. No place to go. The new input is like sand in your hands. Your brain just lets it trickle through. And lost it is, but not forever.

Give yourself time
Think hard, then sleep, then wake up and get the solution for breakfast. Our brain acts in mysterious ways. We are not general statement solvers that always evaluate an input to a correct solution right away

Go for a walk and continue thinking
There is a whole thought school on walking and thinking called Peripatetic School. It originated with every tester’s old friend - Aristotle. Follow the link and read about them.

And with walking comes fresh air and you have the liberty to choose a good discussion partner and decide on where you want to walk. Isn’t that cool?

Not only the greek liked walking and thinking, Rousseau liked it, too. He might have had the idea from the greeks, though. But who cares where something comes from if it works.

"I can only meditate when I'm walking. When I stop, my mind ceases to think; my mind only works with my legs." Jean-Jacques Rousseau

Go ahead and try it out. Solutions may come flying towards you. Then you just need to catch them.

Visualize
Don’t just brood over something until your brains starts boiling. Extend yourself, take your hands and draw your problem. Make it visible. Look at it. Draw again. You “see” the great feedback loop you just created?

There are different forms of thinking. You are most likely to face problem solving in a verbal fashion. You just juggle words in you head and you try to sort them. But there are other, non-verbal forms of thinking, which are:

• musical
• kinesthetic
• mathematical
• visual

Anyway, visualization may greatly help with your thinking process.

Have a whiteboard/flipchart/blackboard close to you
That would be the preferred space to visualize. Their size helps you to get your problem “in your face”. It just pushes at you until you see a path through the jungle.

Discuss with friends
Explain your problem to a friend and get him/her involved in a lively discussion. The best discussion partner would be somebody with whom you tend to disagree. They obviously understand the world differently, otherwise you wouldn’t be quarreling constantly.

Just do
How much do you really need to understand to at least start with something? As mentioned in a previous post, true mastery comes through practice. Just start with doing and understanding will follow.

Prepare a presentation and talk to people about it
Take something completely new and unintelligeble to your mind and start making a presentation. Guess what, you learn with ultra-sonic speed. The outside pressure keeps you focused.

Write down what exactly you do not understand
Again a neat little feedback loop. Writing is reading your thinking. You might want to use the Phoenix Checklist. Search on the engine of your choice and you will quite easily find it.

AND MOST IMPORTANT:
Learn to feel comfortable with not understanding
You don’t need to fully understand everything. At least not immediately. If you want that, you will always remain in your comfort zone. The comfort zone is a very dangerous area. It is the little brother of mediocrity. Who has the aspirations to be mediocre? Anybody?

A little tautology here: Difficult things are difficult. If you don’t learn to be comfortable with the slow process of understanding difficult things, you most likely will abandon your pursuit of greatness. It doesn’t just happen overnight. You need to work for it. Start today.

(And tell me in the comments below how you face your difficult understanding problems, I am very much interested in how YOU do it)

tags: skill, education, learning

Have you ever presented at a conference without you actually being there? I did. It was fun. Of course I could not even see the audience as I was not there. I did not hear a word from them.

By now you might ask yourself: “Has he lost his mind?”
That could be a valid explanation but it is not correct.

The conference I am talking about is Software Test Professionals Spring 2012 (STPCon) in New Orleans. I did the second part of Anne-Marie Charrett’s track on coaching testers. It was a live Skype coaching session I did with Vernon Richards who was my student. The audience saw our transcript unfolding while Anne-Marie identified patterns and commented on what we did.

See? I am not crazy.

We only had half an hour which is unusually short. So, we had to skip many elements of a typical Skype coaching session. But Vernon did great under the time constraints.

The exercise we did was an observation and description task. I won’t say too much about it because I do not want to spoil the experience for students who want to do it.

Anyway, it was kind of unusual to know that there is an audience watching us while we unfold our session. I hope there is a video recording. Will have to talk to Anne-Marie.

So, dear audience at STPCon, I hope you liked what you saw.

BTW: For free Skype coaching go here

tags: conference, coaching, skill

Some weeks are boring, some weeks are frustrating, some weeks are just regular. But once in a while there is a week filled with exitement, learning opportunities, joy and intellectual challenges. I am a lucky guy because I happen to have lived such a pleasurable week recently. James Bach came to Switzerland for the first time.

His flight was coming in from England where he attended several appointments in Cambridge. I was waiting for him to exit into the arrival hall. As expected it took not long for James to drop a puzzle bomb on me. It goes as follows:

1. You have a range of integers from 2-180
2. Two integers x and y are chosen from the range (x and y may be equal or different)
3. A person A is given the sum of x + y
4. A person B is given the product of x * y
5. First, person B says to person A: “I don’t know your sum”
6. Then, person A says to person B: “I already knew that you do not know my sum”
7. To which person B replies: “Now I know your sum”
8. And then person A says: “And now I know your product”

Question: What is the sum of x + y, what is the product of x * y and what are the values of x and y
A hint: It is possible to solve it by the sole use of your brain, a sheet of paper and a pencil

IMPORTANT: Please do not leave the solution in the comments below

While driving James to his hotel I tried if there was a simple solution to the puzzle but I could not find one so I decided to attempt to solve it as soon as I got home. Also, it is not such a good idea to try to solve puzzles while driving.

In the hotel we had some more testing discussions before James retired to his room and I was very eager to get back home to solve his puzzle. I think I was on a good path towards the solution but I decided to give me a break because I was stuck somehow.

Interesting enough, the brain seems to have its playful free time during sleep. My brain decided to wake me up at about four a clock in the morning giving me a hint about how to solve it. I decided to get some more sleep and just took some notes on the general idea. Later in the morning I solved the puzzle which made me kind of proud. Tricky one, this one!

Sunday afternoon I picked up James from his hotel and we strolled through Zurich while he entertained me with a lateral thinking puzzle involving a waste dump. Again I enjoyed it very much and it gave me the appetite for the dinner. James is very good at challenging your thinking.



Monday morning we took the train to my workplace Phonak AG, where James spoke all day about tester self-education and did many puzzles with the audience of about 50 people. The astonishing thing was that there were more developers present than testers. What a great success for software testing. Developers become more and more interested in what we do. We testers have won! (Just joking, I love you all, dear developers)



This year’s Swiss Testing Day saw an amazing record breaking number of 800 participants. James had the first of the keynotes in the morning (you may see the video here) and I hope he inspired many testers to become interested in the context-driven school and self-education. I expect to see more Swiss testers working on their reputation in the future.



We sold James’ excellent book Secrets of a Buccaneer-Scholar at our conference booth and every 10th person at the conference bought a copy. That, too, gives me hope that there are more context-driven people in Switzerland. If you - dear reader - are one of them, please contact me immediately. I want to get to know you and talk to you. James talked all day to many people, there were dice games and his hand must have been tired from all the book signing.

Thursday was a work day, we went through some of my Skype coaching transcripts and James gave me a lot of valuable feedback. We did that in one of my favorite coffee shop/book store Sphères in Zurich. It is the perfect place for productive work.



Friday came and James was very eager to learn about Swiss cheese. We drove to Engelberg where there is a public display of cheese making located in a monastery. In the middle of a room there was a kind of glass igloo where a cheese maker was doing his stunts while the visitors pressed their noses flat on the outside. A bit like in a zoo, but without animals.



In Engelberg we found the wonderfully victorian Hotel Terrace from where we had a beautiful scenery of mountains. Again we went through more coaching transcripts and tried to identify patterns.



After coming back to Zurich, we ended our day with a dinner at the Prime Tower on the 35th floor and challenged each other with some more lateral and mathematical puzzles. James also made fun of me because I was eating my hamburger with fork and knife. See, that’s us Swiss people behaving at a fancy restaurant. Anyway, great day, but then we were both tired at the end. It was like in Monty Python’s “Just a thin mint”-scene (Caution: this link is not suitable for the faint-hearted), one more puzzle and my brain might have exploded.

James headed off to Stockholm on Saturday, I said good bye at the airport and I hope he comes back to Switzerland soon. You’re always welcome, my friend.

BTW: Here is the link to James’ view on his visit to Switzerland.

tags: conference, context-driven, skill, education, coaching

image credit: http://j.mp/Aoky2E

Recently I saw three enormously fat men standing close to each other and the feature that caught my eye was their huge bellies all three guys put on display for the world to see.

If they had moved a tiny bit closer, the bellies would have met with a gentle touch.

They did not do that but they were discussing stuff. They were chatting and telling jokes. In short: they were being human with all the pleasant properties as well as the flaws humans tend to have.

Test automation hasn’t got a belly at all. Neither does it crack jokes. Why should it? It would not be of any use. Test automation hasn’t got any humor but it is lighting fast and incredibly accurate.

It is kind of obvious: Humans and computers are different. Both are good at some things and have their shortcomings somewhere else.

You certainly know testers who say that test automation should not be considered at all for testing. They say that it does not help doing a tester’s job and by saying that they are - in my opinion - fundamentally wrong.

I am sometimes amazed by the inaccurate thinking of some people. Just because test automation cannot do some things it does not mean it cannot do anything. That’s like saying: “This car is useless, it cannot fly”.

What test automation is good at:

• Fast checking of huge amounts of data that is prone to change and therefore to errors
• Doing repetitive procedures over and over again
• Access code that is not easily accessible through the UI
• Do basic sanity checking on an regular intervals

Test Automation is very, very good at the above. Beer bellies aren’t.

The excellent book Mind over Machine by Hubert L. and Stuart E. Dreyfus describes it accurately:

Computers are general symbol manipulators, so they can simulate any process which can be described exactly.

On the other hand humans are splendid observers even if they don’t anticipate beforehand what they are going to discover. A tester who finds a bug during an exploratory testing session and who is asked how he/she found a certain bug will sometimes reply: I don’t know. Finding a bug without exactly knowing how it was done differs enormously from the definition of a computer above.

What humans are good at:

• Collateral observation
• Rapid change of direction if new information demands it
• Acquisition of knowledge in general
• Taking advantage of the wisdom of crowds
• Using intuition

Beer bellies are very, very good at the above. Test automation isn’t.

I think our western culture is very much imprisoned in a dichotomous either-or-mindset. There seems to be a need for a constant opposition between two positions. Hence you either do manual testing OR automated testing.

This is a silly standpoint. Use both. And do it the same way a good manager distributes tasks among his different directs. Every task according to the individual strengths of the people.

There wouldn’t be any machines left if the fat people finally took over. And this is also true the other way round. It would be a sad world.

tags: automation, testing, balance

image credit: http://j.mp/z6Y8PL

This week there was quite some ruckus about the alleged passing of the context driven school. All this was caused by what Cem Kaner wrote on the about page on www.context-driven-testing.com:

However, over the past 11 years, the founders have gone our separate ways. We have developed distinctly different visions. If there ever was one context-driven school, there is not one now. Rather than calling it a “school”, I prefer to refer to a context-driven approach.

Oh, no! We have lost our safehouse where we found warmth and shelter. Now we insecure testers are again out in the cold and wandering about aimlessly. Let us therefore all shut down our brains and immediately join the factory school.

Honestly, I am surprised by this eruption of un-coolness. Cem just decided to do something else. He is a free man. He can do whatever he wants. That is not a problem at all. A school does not just disappear. Maybe if it is a school-“building” and you - let’s say - blow it up with a few strategically placed sticks of dynamite. And even then it does not completely disappear. On the other hand schools of thought are immune to dynamite and very rarely disappear just like that. And even less so if there are many people still acting according to the principles every day.

What is a school of thought?
A school of thought is a collection of people who share the same or very similar beliefs about something. So as an example: Zen Buddhism is a school of the Mahayana branch of Buddhism. They share some beliefs. And the context-driven school consists of people who subscribe to the following beliefs:

The seven basic principles

1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project’s context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

How could these principles possibly have become invalid just because 1 person (albeit an important one) wrote the school is no longer. And now comes the crucial point: That is not even what Cem wrote. He wrote “If there ever was one context-driven school, there is not one now”. This only states that the founders have developed differently over time and may have even been different from the beginning. Not so surprising. I do not know of any two people with redundant brains. Well, maybe Thomson & Thompson from Tintin. But that is the comics world.

Stanislaw Lem said it perfectly in his advice for the future: “Macht euch locker und denkt ein bisschen!” (Take it easy and think a bit)

Therefore here is my advice: “Stay calm, get another beer and keep on thinking.”

BTW: Almost all domain name combinations of www.context-driven-school.com / .net / .org / .etc are still available. I am sure somebody among you has a good idea what to do with it.

tags: context-driven, testing, insecure, self-confidence

image credit: http://j.mp/y6XGfm

Many people have wanted to look in the future and see how things are going there. This is what I am about to do right now. I can tell you exactly how software testing will be in the year 2032. Want to hear more? Ok, here we go:

It will be different

I have to admit that this was kind of anticlimactic and maybe even a bit disappointing to the ones among you who are always keen to get all the nice little details served on a dinner plate and spoon-fed to your mouths. Sorry, I have to let you down. Well, to be honest, no, I am not really sorry.

Go back to 1992. Almost no internet. No smart phones. Very few testers. Mostly highly scripted test cases in waterfall processes. Who would have thought how today’s testing world would look like. Although, this video is kind of interesting. (As a side note: it also reflects the role thinking of 1969.)

Assuming that there is an acceleration in the development of new technology and a somewhat less speedy development on the human side it would be crazy for someone to “know” about the future. This highly dynamic and complex system is not very transparent for crystal ball predictions. So, don’t fool yourself into believing that is possible.

What is thinkable?
Computer science realizes that it is inherently a human and social science. Therefore a lot of thinking will go into how teams can collaborate better. The stereotype of the non-communicative nerd developer will eventually prove to be wrong.

Software development practices most certainly evolve in a direction that becomes even less error prone. Future compilation mechanisms will prevent many more of the errors from happening. Hence, less of the “stupid” sort of bugs. That means it will be more difficult to find bugs.

Testers on the other hand will have fully understood the concept of applied epistemology and will use a rich set of heuristics during every testing activity while having stopped completely to whine about their poor state of affair.

Hm, some spacey element is still missing here. Ahm, ok, let them all have a huge gadgetry of enhanced reality goggles and exoskeleton support with intelligence enhancing psycho pills implanted directly in the brain. And maybe find use for some of these, too. Or something the like.

What won’t happen?
Everybody who thinks there won’t be any testers in 20 years is indulging in crazy talk. No, we won’t have everything automated because thinking cannot be automated and therefore the design of automation needs human brains. Ideally, brains with a tester’s mindset. Running automated tests is checking, not testing.

Automation is important, too, but it is not everything that is needed for wholesome testing. And just think of it: Writing code in 2032 will still be a very, very manual process in the deepest sense of its meaning, assuming that developers still use their hands to write it.

What can we wish for?
I would wish that testers in general develop a pride for their craft. Whenever somebody with the title “tester” says she/he hasn’t read anything about testing it will be as if somebody was swearing filthily in a church while the pope himself is present. Unheard of.

So what is my message here?
I think it would make sense for all us testers to spend some time reflecting on where the journey is about to go. On the way we should all keep learning new stuff and keep our senses alert and our brains busy. Let’s learn new stuff every day.

This morning testing was somewhere, then the day passed and already now it has progressed to the next stage. I am very curious to know how it is going to be in the future.

What’s your view? How do you think software testing will evolve over the next 20 years? If you could influence it, what spin would you give to software testing? What is it you would like to see more? What less? Tell me more in the comments below.

tags: testing, future, skill, craftsman

Q1. Can I write a blog post that is inspired by a comment on a previous post?
Q2. Can I name the person whose comment inspired me?

Ethical questions these are. And fortunately they are quite straightforward to handle:

A1. Now that is the beauty of being in charge: I can do whatever I please here in my hood.
That would be a YES.
A2. This one’s trickier: If I had a comment by someone I know but who preferred to stay anonymous in her/his comment, then probably no. If the commenter has stated his real name, has a picture of himself as an avatar and will be stated as an example of asking a very good question, then with high probability YES.

Who is it? Who is it? What’s the question? What’s the question? It is my friend Jesper L. Ottosen from Denmark and his question on the previous post was:

Where is the semantic definition of the ">" operator, it seems it operates on "k" functions?  In layman's terms: how do you determine "more knowledge"?

First of all I would assume that within our context-driven family there is a consensus on that there is no such global thing as “more knowledge”. Let’s explore some dimensions:

People Skills/Supporting the Team
I put this first. Not just so, but because I believe that testers who do not have a sensorium for the necessity of interpersonal skills will never achieve anything of long term value in organizations that are inherently built on team work. And team work means - well - working together.

Test Techniques
Now, this might create the impression of being a parrot who is able to list the names of test techniques as they are requested by some multiple-choice questionnaires . That’s not what I mean. What I mean is the ability to approach a testing problem with the mental tools necessary to solve a problem. Which leads to the next dimension:

Problem Solving
There are (at least) two fundamentally different areas of problem solving. First: At school where the problem might be served as a well defined question and might sounds like this: “How long was the Thirty Years’ War?” The answer to that question would be: “30 years”. Problem solved. Second: “Test this!” Answer: Well, there is no answer to that. There are just many more questions that need to be asked. Or in other words: The problem field is only fuzzily defined. You need to find a way to make sense of it. And you don’t get 10 points for a correct answer neither.

Software Development Abilities
No, it is not a disadvantage if you know how to code. But that’s something you already know. And one shouldn’t use double negatives. They take more time to interpret and are error prone on the sense making side. [Refactoring the sentence]: Yes, It is an advantage if you know how to code.

Fast Learner
I was recently asking myself if there is a correlation between fast learning and general smartness and it took me virtually no time to decide that: Yes, there is a correlation. In what way does smartness help being a better tester? Well, if you learn fast, you may use your learned content faster to do testing. And if you do testing sooner, you start to find bugs sooner. Actually not only sooner, but you actually find them based on your knowledge you just acquired. If you’re not a fast learner, you might miss them completely.

Creativity/Lateral thinking
Get your lateral puzzles rockin’ your brain cells. It creates agility on your ability to come up with good tests. And good tests of course find good bugs. Obvious, isn’t it? Now, go and find instances where this is not true. Or only half true. Or something completely else. Turn it upside down and then back again. What do you have now? Did you follow me? If so, can you explain?

Good Observer
Some time back I bought new glasses. One of my testers immediately noticed. He was the only non-glasses-wearer who noticed. (People who wear glasses seem to notice more often if somebody else wears new glasses). He does not only notice glasses, he notices a whole lot of good bugs in our product. He is a good observer.

Explaining/Teaching others
That is an ability you should either have yourself or if you don’t have it, then you have to fly in James Bach or Michael Bolton.

Inspire others
This one goes very much with the first category, the people skills. Testers who are able to inspire other testers to become better at what they are doing, are very valuable team members.

Curiosity
Don’t click here.

Experience (Been in the business for some time)
Ever heard of the 10’000 hours rule? It states that if you deliberately exercise something for 10’000 hours you get really good at it. Ok then, let’s do some 10’000 hours of testing.

Reader of Books & Comics
Can it be that readers of books & comics are just better testers? Who knows, it might be true. And I am sure I have a scientific study somewhere here that confirms my theory - let’s see….hm, just cannot find it right now. I am sure it is somewhere.

Resistance to Stress
If you’re resistant to stress, your heart keeps on beating instead of attacking you in the middle of a test cycle. Having a heart attack makes testing really hard. I put this in the “knowledge” section because handling stress can be learned.

Resistance to Stupidity
You know it when you see it. My take on this is that humor helps a lot. People should nevertheless have a finely tuned bullshit barometer in order to detect it in a timely manner.

So, whenever you employ new members to your team, I would recommend to test them on the dimensions above. And please, tell me your dimensions in the comments below. Thanks.

tags: skill, knowledge, craftsman, education

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

I assume you are a professional software tester. If that is true, then it means you are good at at least two things. You ask good questions and you are an excellent observer. So, here is a small puzzle. You’re ready? Ok, you’ve got 5 seconds time to come up with the answer. Below are two images of knots.

What - in your opinion - is the single most dramatic difference between the two?

1…2…3…Go!

Here’s one

and here’s another one

Time is up! Did you notice the difference?

No, the most significant difference is not that the first image has rougher string edges, that is just because I am not such a good photoshopper and because I was a bit sloppy with the magic wand when I synchronized the color hues of the two knots. I decided to leave this small flaw in the image to mislead some of you.

The proficient observers among you have of course immediately noticed the different path the string takes:
1. Over-under-over-under-over-under
2. Over-under-over-over-under-over

The first knot is a so called granny knot and the second one is one that is called a reef knot.

And now comes the important part: Although both knots look almost the same, the first one (granny knot) is much inferior to the second one (reef knot) when it comes to the strength of the knot. The granny knot easily becomes undone if you pull on the strings. Or, in other words, if you challenge the knot, it falls apart.

Hah! And now it is easy to make the connection to software testing. There is a lot of testing that looks like testing but isn’t. It is just playing testing and not the real thing. These are the granny knots of software testing.

Some examples:

• Calling something exploratory testing that is actually only mindless clicking about
• Rigorously following the steps in test cases without switching on the brain
• Any record and playback test automation
• Reporting tons of metrics that fail to answer any meaningful questions
• Talking about 100% coverage without answering: “Referring to what?”
• [your own example here]

If anything, please, be aware of your testing granny knots. Examine your testing practices thoroughly in order to identify areas where you only superficially test or where your practice is simply wrong. Stop doing them or, if possible, correct them.

BTW: Are you somebody who is constantly re-tying your shoe laces because they undo themselves? The reason for that could be that you use a granny knot instead of a reef knot. Have a look at this instructional video to find out.

tags: disfunctionalities, review

image credit: http://j.mp/zgdpTY

Shall we open our philosophy bag and draw out three beautiful, albeit difficult sounding words? Yes? Ok, here they are:

• Episteme
• Phronesis
• Techne

Given you are not a philosophy-historian-tester I assume that you are currently thinking: “Gee, what the heck does that have to do with testing?” The brief and crisp answer is: nothing and everything.

None of the three concepts is related to software testing directly but they are all very relevant when doing software testing.

Let’s clarify: Episteme, Phronesis and Techne are three different forms of knowledge.

1. Episteme is what is commonly known as knowledge you can e.g. read in books, or what is known as propositional knowledge
2. Phronesis is the knowledge of familiarity or practical wisdom
3. Techne is the knowledge of application or craftsmanship

For the sake of honesty: I am pretending here a slight bit as I have not read the primary source itself which is The Nicomachean Ethics by Aristotle. (Although I have ordered the book and it should be delivered to me soon)

Let’s say you read a book about software testing. The writer is a nice and knowledgeable person who really well describes the most fascinating testing techniques. At the end of the book and after having highlighted the key parts with a highlighter you close the book. What has happened inside you? How is your brain re-wired now? Can you actually have your hands do what you have read about? Could you teach it to others?

Now, this is the beauty of software testing. You need to do it in order to become good at it. It is not sufficient to only read about it no matter how much material you work through. The portion of tacit knowledge is huge with an experienced and skilled tester.

And this is for all the certification sectarians among you:

Scribbling a check mark at the answer some insignificant people with an outdated view on software testing have claimed to be correct in a multiple choice questionnaire is the lowest and most useless form of proving knowledge.

And it is skyrocketing on the stupidity scale. How dare these people speak about professionalism in testing when in fact they are a greedy bunch of money makers selling their overpriced pretentious courses and at the same time do not have the slightest clue about what software testing is.

OOOOOk, cool down again. I get heated up by this subject a bit too easily but it is one I simply fail to ignore because of its damage it does to our profession. May Techne be our guardian angel to protect us from ignorance.

Whenever you start applying knowledge you have just read you feel clumsy and insecure. This for many people would be a reason to not pursue it any further. Just embrace the feeling because in order to ever master anything you need to overcome this first dip. Milk, honey and chocolate await you at the other end.

tags: philosophy, knowledge, craftsman, certification

During the past few months I had Skype coaching sessions with James Bach on a regular basis. Recently, we started to reverse our roles (I was the coach and he was the tester asking for coaching). I have gained a bit of experience in coaching testers. Now, I would like to sharpen my saw and that is why I have this offer for you:



How does it work?

• You contact me and we try to find a date and time (my Skype-ID: ilarihenrik)
• We use the messaging system of Skype
• We’ll work on what you are interested in. If there is nothing specific I will come up with something on my own
• I will do this by the use of the socratic method. That means I will try to keep your brain busy by asking demanding questions
• This offer is without obligation for neither part
• As already mentioned: it only costs your time; not your money
• You allow me to use the coaching transcript for my purposes

Here is some feedback from participants:

Thanks a lot Ilari Henrik for the session and pointers to communication model.
If that is the case then I would like to give feedback on the session.
1. Very interactive
2. showed patience
3. Very well received because I was little nervous
4. built good repo
5. Helpful
6. Encouraging
Looking forward to make a difference...
Thanks,
Savita
http://savitamunde.wordpress.com

tags: coaching

You lean back in your expensive executive leather chair puffing your H. Upmann cigar smoke in the face of your subservient employees and then you laugh far too loudly while lifting your legs and placing your expensive bespoke brogues on your desk.

You have successfully changed sides. Yesterday you were a tester, now you are a manager of testers. Great, isn’t it? And while you indulge in complacency in your splendid new corner office, what might soon happen to your testing skills shall be exemplified with the following image:

image credit: http://j.mp/wHvCiA

It was in November 2007 when I was promoted line manager of my test team. We have four different roles: Testers, Test Engineers, Software Developers in Test and Test Managers. The size of the team has always been between 13 to 19 Testers. My team is great, I love them all. And being a line manager is very rewarding.

If somebody asked me I would say that I follow the Servant Leadership style. I am familiar with DISC (myself being a strong I and D with a significant share of C) and Process Communication Model (Base: Workaholic, Phase: Rebel). I concentrate on the “what” and I am agnostic about the “how”, “when” and “where”. I constantly try to keep on learning; currently I am an avid listener of the Manager Tools Podcast.

So, where is the problem?

There is a fundamental difference between being a tester and being a manager of testers. Given the size of your team is big enough, the line manager part of your job becomes a full time activity. Now, what does that mean? Well, if it is a full time job, then obviously you are no longer testing that much yourself, are you?

And what happens if you do not practice anymore? You become fat and ugly.

I don’t want to be fat and ugly. In the same fashion as many people start jogging after Christmas gluttony, I decided to start my own little jogging program. Only dwelling in propositional knowledge won’t make you better at all. These are some of the things I have started:

• Regular Skype coaching sessions with James Bach (next session: tonight)
• Registered with uTest.com and started testing to reeducate myself (And they even pay you but I think I am going to donate the money to charity)
• Challenge my brain with Lumosity, Khan Academy and Code Academy
• Vowed I will submit session proposals to at least 3 conferences this year
• Try to learn from testers who are active on Twitter
• This blog is actually a result of my reasoning about testing (writing == reading your own thoughts)

Here’s an invitation: If you are from Switzerland and you are serious about testing, please read on. And by “serious” I mean:

• You regard testing as an intellectually demanding activity
• You are context driven
• You strive to become really good at software testing
• You value honest feedback
• You sneer at useless certifications

PLEASE do contact me, I want to talk to YOU. Let’s form a context driven school of software testing group in Switzerland. Let’s get better at Exploratory Testing. Let’s solve puzzles. Let’s challenge each other. Let’s become world class together.

tags: skill, management, craftsman, learning

image credit: http://j.mp/wRWveO

Interviewer:
So, how do you handle your bugs?
Interviewee:
Finally, we don’t have to talk to each other anymore. Why should we? We have a bug tracking tool now. It’s called “Brave New Bug 1984” . Everything goes in there. Even the slightest suspicion is reported. Unit and integration tests that fail result in a report in the tool. That is something we the noble quality police fought hard for. And we have set high goals for ourselves. The next step will be that even if a developer e.g. makes a typo - something like: accidentally typing two closing brackets - he/she can no longer just correct it. It must go in the bug tracking tool. And then we will issue metrics and reports. About every single developer. We exactly know who the bad apples are, and then we can talk to HR directly, and we will fire people, and…[Interviewee starts to salivate]
Interviewer:
Have you lost your mind?

That’s right. This is the voice of madness. And hopefully there is no company that practices bug tracking that way. But - who knows - if it exists and you work there, then do yourself a favor and quit your job today.

Most of us use a tool to track bugs and I have a question: Why? What is the reason to use a tool for bug tracking? Hmm?

Our brains are very good at being creative, socializing with our friends, playing cards and drinking a beer. Not so good at keeping updated lists in our heads. That is where a bug tracking tool comes in handy. It outsources our list keeping. So, the bug tracking system prevents us from forgetting about things. Bugs, in this case.

But does that mean that every single little thing in every single little situation must go in the tracking tool? What about tester feedback from exploratory testing sessions at the daily stand ups in an agile environment? Is it really necessary to have it all in a tool? Maybe so, maybe not. Just decide for yourselves. Maybe even have some of the bugs tracked and others not. I don’t see it as an either this or that game.

Another made up reason for being strict about handling all bugs in the tool could be that you as a test manager are fond of reporting the total number of bugs in a project. “We have found 53’732 bugs during this project”. My reaction to that: “So what?”

Compulsive counting is something we used to do as school boys. In our case we used to brag about being in possession of 53’732 different posters from discotheques. You know, we used to drive around with our mopeds and take discotheque posters off the walls. They looked like this:



Ridiculous, isn’t it? But excused, because a weak beard growth does not really help being sensible.

So don’t become this compulsory counting freak in your company and if you feel like reporting any number then be sure it has some meaning. However, the number of bugs found does not inherently have meaning. It does not say anything about the quality of the product.

BTW: This very old article by Joel Spolsky is quite a good read and still valid.

tags: bug tracking, testing

Somewhere in between two releases we are born. At that milestone there is a whole suite of tests done with us. Boot-up complete - tested, 10 fingers - check, 10 toes - verified. Then of course our mother immediately introduces us into the mysteries of software testing by feeding us gently. We get to find our first bugs as toddlers, in the nursery school we draw our first test plans and in elementary school there is a comprehensive software testing curriculum.

During adolescence we naturally have to rebel against good practices and secretly meet with not so trustworthy people with whom we do some testing certifications. Later in life, we have to admit to ourselves that we were just young and foolish. Anyway, off we go into the glamorous work world, a master’s degree in software testing in our pockets and filled with a lot of energy to tackle even the most difficult testing problems.

All this rich life of working the software forms our fond memories we then tell the nurses in the elderly home, who are not really that interested in what we say, because software - of course - is an outdated concept and no longer being used in this future world. But that is something we won’t notice because our perceptional capabilities have already become very limited. Therefore we just sit there in our rocking chair and smile.

image credit: http://j.mp/wXYDLr

tags: skill, education

Try this: Go buy any new book. Then de-shrink-wrap it (i.e.: remove the book from its enveloping plastic awfulness). Place the book in front of you. Take it in your hands. Open the book somewhere. Meditate for a second. Then put your nose deep into the book and inhale.



Now comes the triage part. What is your reaction to that proposal? (mark your selection with a check mark)

1. That’s crazy talk! Why would I do that?
2. Yes, I know. Done it before. Ahhh, I just love the smell of new books.

If your answer was similar to 1. then stay with me and keep on reading. If you feel more intimate with answer 2. then you will probably stay with me anyway because you are a book lover and like to read.

It is amazing how many people in software testing have not read one single book on software testing. Or have even hardly read anything at all. Mostly the reason given is lack of time. But that is simply not true. Nobody can have lack of time because the flow of time is just as it is. There is no such thing as “lack” of it. It is 24 hours every single day. No deviation to that (given that you are a habitant of planet earth). The only difference is the priorities assigned to different activities and for some strange reason reading books seems to be de-prioritized by so many.

Just image e.g. a physicist, or a medical doctor stating: Bah, I haven’t had any time to read books on molecules or the human heart respectively. Would you trust such a physicist with a Large Hadron Collider? Would you trust your grandmother with such a physician?

Knowledge that may be helpful:

• Software Testing (ok, that was obvious)
• Software Engineering
• Psychology
• The art of drawing
• Philosophy
• Rhetoric and Persuasion
• How to describe well
• Literature on observation
• Epistemology
• Heuristics

Who should we take as role models? What’s the highest we could aim for? I propose the Uomini Universali. Or as Wikipedia has it:

The common term Renaissance man is used to describe a person who is well educated or who excels in a wide variety of subjects or fields.

As software testers you might be exposed to a wide variety of different programs. If you hop from project to project it is very likely that you need to educate yourself in wide varieties of domains. Furthermore, you as a software tester are better off with a questioning and doubting mindset. This is something that can be acquired. Books are a brilliant tool for that. Not the only one of course because practice should never be underestimated. Nor should tacit knowledge, that may only be acquired through socialization processes.

And: do you think that one of the Uomini Universali would have ever been caught uttering the statement: “I haven’t read a single book”?

Ok, my friends. Please leave your comments on your favorite books that helped you become better as software testers. If you convince me that your recommendation is good, I will read the book, too. And we could start a conversation. And then the world would become a better place. And happiness would spread.

Today we finish with a poem by Thomas Moore:

Off I fly, careering far
In chase of Pollys, prettier far
Than any of their namesakes are
—The Polymaths and Polyhistors,
Polyglots and all their sisters.

tags: books, education

I love what I am doing. If I wasn’t I would do something else. Like gardening or follow a career as a beach bum. Sun tan and a lot of booze. But no, it is software testing and managing software testers and talking to developers and ship tested software that I like.

But from time to time I observe a pattern that seems to be especially endemic among software testers. It is the tendency to whine about one’s own work situation while blaming everybody around us for causing it.

Let’s bullet point what some of the testers I have met at conferences not only think but also say aloud (The last one is slightly modified. Instead of the url’ed word, another one was used):

• I am fine, they are not
• I do a pristine job, they are slobs
• I could be so much better if only they did their job
• I would immediately start testing if only they’d provide me with perfect, unambiguous, neatly versioned, accurate, testable, re-usable, superman-feature-like requirements
• I am a saint, they’re rectal cavities (caution: link not safe for work)

Isn’t it interesting to observe how this follows the usual bipolar structures usually found in western cultures? (e.g. BS like: “Either you’re with us or you’re against us”). Never a continuum nor a trinity. Or calm acceptance without assessment.

Now, please! Software Testing is not a terrible job and the circumstances are not bad at all. In order to illustrate go and read Viktor Frankl’s Man’s Search for Meaning.

I’ll wait.

See, that is a horrible situation. For those of you who couldn’t get the book or cannot read here a short abstract: The book describes Viktor Frankl’s devastating time as a prisoner in Auschwitz and how he managed to not fall in total despair and keep up his spirits to survive his personal disaster.

Whenever you find yourself in a situation, just compare to that. I’ll guarantee that you’ll always be fine.

And here’s a belief shattering secret: The world around you was not built to please your own little egoistic demands.

And here’s another: If you are one of those whining people, your are not fun to spend time with. People will avoid you. Then you will be alone. And even more miserable.

Therefore:

• smile every day
• never develop an inferiority complex
• don’t become a zombie tester
• avoid process freaks
• fight sub standard work ethics where ever you find it
• have a serious discussion with testers not willing to read books or learn anything (I think I am going to have a special post on that)

Let’s finish this post in a little bit more upbeat mood. I propose to go watch this hilariously funny short clip on youtube.

tags: testing, testers, whining

Imagine a commune of five long haired hippies. Let’s call them Andy, Bruce, Claire, Denise and Emma. And - hey - it is the time of free love so they live in alternating relationships. No room for conservative thoughts here, the hippies were free thinkers, so all pairs work. Let’s have the following pairs as a start: Anthony & Claire and Bruce & Denise. Poor Emma is not in a relationship and therefore somewhere with with the earth goddess pacha mama dancing barefootly while gently humming a tune.

But, we’re drifting away here.

Now the question: How many possibilities are there for relationships, before our five hippies get bored and become law abiding white protestant middle-class work drones?

You remember the lottery from last time? 45 choose 7? Ok, this here is a simple 5 choose 2. And there are 10 possibilities for relationships. See below.



This leads us to something powerful used in Software Testing: Pairwise Testing

But what is it?
Pairwise testing is a combinatorial testing method where within a given set of parameters with each a finite set of values all value combinations are tested and where you want to keep the total number of tests to a minimum.

When testing exhaustively with the array below the total number of tests would be five to the power of five = 3125
Hm, well, with decent automation this does not sound that unfeasible, does it?



You’re right. But now lets have a look at this. Does not look that much bigger. But actually we now have a total of 10’000’000’000 possible test cases. This is obviously far too many.



It is often stated (and there is some evidence here, see chapter 3 “Empirical Data” ) that errors happening in a program are most often in the combination of two parameters and become less likely when combining three and more. Therefore it would make sense to test covering all pairs.

With each test run you cover several pairs. So for instance with our hippies A, B, C, D, E you would already cover 10 different pairs (as exemplified above).

Assuming that the combination of A1 and H9 leads to a bug, with pairwise testing - wait, now it comes - you win your own special little lottery because you actually find the bug. That’s how you earn respect with the developers. Isn’t that cool?

Information becomes knowledge when applied. Therefore I would recommend to try it out for yourselves. Here are some tools I find useful:

• Hexawise
• James Bach’s ALLPAIRS

Now a word of warning: Some might say: “Let us declare pairwise as best practice, cast it in stone and apply it readily everywhere”. No, not at all. Just because using explosives is excellent for tunnel building (or more abstractly “to make a hole” ) you do not blow up your house every time you need to have a whole for a screw to hang up a picture. Pairwise testing is useless in some contexts. I am not going to explicitly name any, as it should be obvious.

One more thing: I would like to be the advocate of our sapient testers (often still called “manual testers” as if writing the code for automated tests was not done using the hands of the developers). Whenever possible, automate this kind of testing.

What more is there?
Pairwise Testing: A Best Practice That Isn’t
pairwise.org
Pair Wise Testing

And there is even a little conference:
Workshop on Combinatorial Testing

Now go and spread the word. Send out the links. Let the RSS feed rock n’roll. And comment like you haven’t commented ever before. I’m ready to rumble in the jungle.

tags: mathematics, permutations, pair wise testing

What is the equivalent of winning the lottery in the software tester’s context? How do you as a tester win your own special little lottery? In order to answer these questions let’s have a look on what the chances are that you win the “real” lottery. We can do that backwards, starting with the solution:

The chances for you to win the lottery (select 6 out of 45 numbers) is exactly 1 : 8’145’060

But, how do we know?

Ok, we have 45 different numbers or slots:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
For those of you who have not skipped my last post know that for each of the slots we have the following amount of declining possibilities to select numbers:
45 x 44 x 43 x 42 x 41 x 40 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
And because we only have to choose 6, we stop at 40.

This can also be expressed as:
Like: 45 x 44 x 43 x ….. x 3 x 2 x 1 divided by anything in the row below 40 as they are not needed. That is the elegance of math. Isn’t it beautiful?

I know, you have already quickly calculated the result in your head and you must have arrived with the number 5’864’443’200, which, obviously, is not equal to 8’145’060. And you are right. And I am right, too. I have not said I am finished yet. Sneaky me!

We now have the calculation of: “In how many ways can a set of 6 be chosen out of a stack of 45 including different orders of the six cards”. But the lottery does not care if one of the winning numbers is selected as a first number or as a last. Neither does the winner care in his bliss of the millions whether or not he crossed one or the other number first on his tiny receipt.

In how many ways can a set of 6 be grouped? You remember the evil mobbing bunch of memorial picture taking testers from the last post? No? Ok, here is the explanation once more: Six factorial, or 6 x 5 x 4 x 3 x 2 x 1 = 720

That is the number we have to divide the whole thing by, before we hop off to cash the winner’s cheque with the grumpy old lady behind the cashier’s desk.

Or written as a formula:

Or even more elegantly:

Or even more generally -> BTW: If you want to actually say that to - let’s say: to a person who has very dark sun glasses and therefore cannot see the formula - then say: “n choose k” and everybody will immediately believe you are a highly professional software tester.

So = 8’145’060

Which stated as a probability is:

QED

This leads us to the intriguing question: Why on earth am I dwelling on math formulas? That is because after having recommended Khan Academy in the last post, I ate my own dog food. And now I am hooked. I joyfully participate in Khan Academy’s exercises. And man, I wanna get one of those Black Hole Badges. Any would be ok, but “Tesla” is the one I fancy.



I need to add a 3rd part to this series in order to close the loop back to actionable value for software testing. Next time will be about pair-wise testing and why it is not “Best Practise”. Sometimes it is not even “Good Practise”. It may indeed be “Totally Crappy Practise” in some context.

Ah, almost forgot: In the next post I’ll also tell you how to win your own special little lottery (Justin: I’ll address your requests, too). So, stay tuned!

tags: mathematics, permutations, pair wise testing

What’s the relationship between Testers and Mathematics? I don’t know. But I know what it should be. It should be one of affectionate care and love. Let’s have a short experiment: Upon hearing the following two words: Permutations & Probability. Don’t you immediately start to smile? I do.

The subject of permutations came up when I recently had a coaching session with James Bach and we had some discussions on pair wise testing and the selection of test cases.

For today let’s start simple:

If you are a team of five fabulous testers and you are keen to have a picture taken as a memory of the equally fabulous project you just finished. In how many different orders can you place yourselves smiling towards the camera?

The blunt answer without explanation is: 5!

The ones among you who have never liked mathematics may ask: “Why do you shout? Why do you put an exclamation mark after the answer that is not such a huge number after all?”

And I reply: That’s because it is bigger than you think and because the answer is not “a shouted 5”, but 5 factorial, which is 5 x 4 x 3 x 2 x 1 = 120 possible configurations of a picture of a fabulous team of 5 testers.

Why is that so? Well for the picture of 5 testers you have five slots: _ _ _ _ _ . And you have all 5 testers eagerly waiting to get on one of the slots. One of the five takes the first slot (so there are 5 possibilities for the first slot): 5 _ _ _ _ . Then the remaining 4 testers viciously fight for the second slot: 5 x 4 _ _ _. And so on until we have: 5 x 4 x 3 x 2 x 1

That leads us to a meaner example: Let us therefore assume you were not 5 testers on the project but 6. And now it comes: One of the six testers did not contribute to the success of the fabulousness at all. Obviously, you would not want to have that 6th tester on your memory picture. You now have 6 testers of which only 5 will eventually be on the picture: But, how many possibilities?

The answer is: 720

No shouting, no exclamation marks, but an amazing amount of possible constellations for bullying one of the 6 testers out of a memorial picture. The calculation goes as follows: 6 x 5 x 4 x 3 x 2.

That’s all for today. Next time there will be some hairy examples of ordered and not ordered sets and the calculation of the probability of winning the lottery.

Do I hear your voices demanding: “Come on, give us at least one more useful link!”?
Ok, here you go: Khan Academy

tags: mathematics, permutations, pair wise testing

Quite interestingly in the quiz of Part I on observation proficiency, there was a surprising additional answer among the extraordinarily numerous comments - that there was a sleeping young woman on the picture.

By looking at it again I can now actually identify at least 2 sleeping women: a big one on top right of the picture and a small one that is lying on the belly and looking in the direction of the observer. Who knows, there might be even more! Just apply some more pattern matching mechanisms and pair it with a little bit of fantasy - and there you are!

We humans could also be defined as pattern matching machines. In my opinion that is how we survived to eventually become software testers. Let’s pause here and say a sincere “Thank you!” to our ancestors who constantly asked themselves: “Could this shade there be a nasty smilodon salivating in my direction?”

Anyway, read Francisca’s comment to the last post to also see the answer I was initially looking for. (And I say “Hello Francisca” here, because I happen to know her)

Now, in this post let’s have a walk-through with how observation and pattern matching of such an image actually works. To start with, here’s the picture:



There are different things happening in your brain now:

Stage 0: Surprise - Oh! Look at that! A picture with a mess of funny dots!
Stage 1: Reflection - Hm, what could that be?
Stage 2: Analysis - Ok, let’s see, there are some black dots and some shadier areas.
Stage 3: Hypothesis - That sure looks like a UFO up there, doesn’t it?
Stage 4: Disillusion - Oh, no! That’s not it. It is just a big mess of dots here.
Stage 5: Enlightenment - Ah, look at that! It’s a Dalmatian sniffing on the floor

And then you’re done!
And what does all this sound like? Let’s translate to an other domain:

Stage 0: Surprise - Oh! Look at that! A nice piece of software!
Stage 1: Reflection - Hm, what could that be?
Stage 2: Analysis - Ok, let’s see, there are some buttons to press and some UI elements to look at.
Stage 3: Hypothesis - That sure looks like an entry field up there, doesn’t it?
Stage 4: Disillusion - Oh, no! That’s not it. It is just a big mess of dots here.
Stage 5: Enlightenment - Ah, look at that! It’s a bug sniffing on the floor

Yes, I know, it’s obvious. This is Exploratory Testing!

tags: testing, observation, proficiency, exploratory testing

One important element of software testing is applying the right set of methods, approaches and actions in the right context in order to gain data. Another important element then is observation of the data. By observing well it is that you find potential bugs. Therefore - as a self-respecting tester - it is probably a good idea to become a good observer.

I like Wikipedia’s definition of observation:

“Observation is either an activity of a living being, such as a human, consisting of receiving knowledge of the outside world through the senses, or the recording of data using scientific instruments.”

But, how to become a better observer?

Deliberate practice leads to proficiency, and because I enjoy providing a good service - voilà - here’s an opportunity to hone your skill. What do you see on the picture below?



If you feel like it, you may let me know your solution here.

Games have always been the most efficient (and at the same time most joyful) approach to learning. It is by playing games that kids learn about life. Lumosity is an excellent website that I highly recommend if you want to train your observation skills. I like the games Bird Watching, Space Junk or Top Chimp.

tags: testing, observation, proficiency

It just occurred to me that there is a whole bunch of below standard software testing conferences out there. How to avoid them? And what exactly is it that there is to be avoided?

Here is my “to be avoided” list:
- Overcrowded with the sales people of tool vendors
- Conference is organized by a tool vendor
- Sessions were selected on the criteria: “what tool vendor is willing to pay for it”

Here is my “oh yeah, great” list:
- great speakers
- interesting formats, like unconference or coach camp
- participation and discussion instead of 45min bloody boring bullet ball battles (yes, I know, it is called bullet point, but it wouldn’t have made such a cool alliteration)

What is it that should happen at a conference?
If you are inspired for action = that is good.
If you learn something new = that is good, too.
If you are inspired, delighted, enlightened, and cannot stop smiling = then it is really great.

Make up your own mind and choose wisely. Maybe you’d like to follow @testevents. They promise to update you on testing events.

tags: conference, testing

Ok, let’s start with some thoughts on software testing. Sometimes I find it a good idea to clarify the meaning and connotation of some words for common understanding. So, here are my 3 words:

• Checking
• Verification
• Testing

Is there a difference or is it just irrelevant wordplay? I don’t know, let’s elaborate.

When I hear “checking” I immediately see a boring check list and then I fall asleep. The word “verification” evokes an image of a bureaucrat verifying that all fields on a stupid form are filled in. Now it is “testing” that gets my blood flowing. I mean, looking over the fence to another domain: they are called food testers and not food checkers and their life is filled with glamour and delicious wine. That’s where we want to be, don’t we?

And: There were some famous people named “Tester” such as Desmond Tester, Jon Tester and William Tester. Well, they were not really that famous.

I see checking, verification and testing in ascending order of skillfulness. Checking is just following detailed instruction (e.g. detailed test cases executed by non testers). Verification adds some element of inquiry to it (e.g. detailed test cases executed by testers). Testing on the other hand vibrates in full swing by skillfully questioning the product.

The company I work for calls what my group does “software verification” for the only reason that the term “testing” was already occupied by production. My next mission will be to change the name of my group to “software testing”. And, of course, become better at what we are doing which at the end of the day is far more important.

And here is a good book to start with: Lessons Learned in Software Testing

tags: testing, checking, verification