For the second time this year, James Bach came to Switzerland. After having had one of the Keynotes at Swiss Testing Day in March (see the recording here) and spending time with me on solving puzzles, intensive discussions on testing and reviewing Skype coaching transcripts (see my previous post here), it was time for Rapid Software Testing at eBay.

As usual, James arrived in Switzerland a few days earlier in order to re-balance his jet lag. Knowing that James loves the mountains, I just had to show him Jungfraujoch, which is a spectacular ride on the train and also the highest train station in Europe. We walked on ice and worked out a graphical proof of the addition of ascending odd numbers starting with 1 being n^2 for n being the number of odd numbers added. (Send me your solution, if you feel inclined to solve it graphically)



We at eBay International are a team of 13 testers. As we also wanted to connect with other testers, I extended my invitation to RST to other testers within the eBay family. The enthusiasm level was high and we ended up being 24 people from eBay, marktplaats.nl, mobile.de, brands4friends.de, tradera.se, dba.dk and two developers from eBay, who all found it important enough to spend 3 full days on software testing education.

James jumped right into getting our brains to work with an assignment on how to test font sizes in Wordpad. Appears to be a straightforward task until you spend some time thinking about it. What exactly are sizes of fonts? How do you measure them? On paper? On the screen? What screen? Is it even relevant for Wordpad? How relevant? Good testers immediately start with asking questions.

“If you talk about the number of tests without specifying their content, the discussion becomes meaningless” -- James Bach

Many of the exercises and ‘hot seat’ situations exemplified, that software testing is a demanding and intellectually challenging activity. The hot seat situations consisted of one participant being engaged by James into solving a task. This was tough, since James is very skilled at spotting inaccurate thinking. And once he has done so, he is in your face and all over you. One needs to have nerves of steel in order to successfully navigate through the traps set by James; and the eBay testers mostly proved worthy.

As much as one needs good technical understanding in software testing, there are other qualities equally important. An exercise on ‘shallow agreement’ - a state where you believe that you are talking about the same thing - demonstrated, how important the clarification of assumptions is in software testing.



And why can’t you just automate everything? Simple reason: you can only automate what you know (and even in that category, most would be impractical since of the costs involved to automate it would be too high).

In non-human systems there is a fundamental absence of peripheral wisdom, which is what allows collateral observation. Humans are very good at detecting violations of expectations they did not even know they had. Does that sound obscure? Talk to me on Skype (ID: ilarihenrik) and I can show you with an exercise.

I am very happy that we had the opportunity to spend 3 full days on deep and active reflection on software testing. It is important to acknowledge, that software testing consists of more than just writing scripts and fiddling on automation frameworks. A skillful tester chooses his/her tools according to the needs presented by the testing challenge, and not blindly by following some imaginary ‘best practices’.

Two areas I will focus on with my team in the near future: modelling and reporting. Modelling for its necessity to grasp the complexity of a big system like eBay, reporting out of the need to be able to explain what we do. You not only need to be good at testing but also at explaining what you do. A good report should give an accurate impression on what I as a tester did during the period I tested.

I believe it would be a good idea if more executives in large companies attended Rapid Software Testing. It might clarify some of the misguided assumptions on what software testing is all about.

tags: skill, education, testing

There was a civil defense educational film back in the 50s that taught children to duck and cover in the event of an atomic attack. People lived in constant fear of annihilation and searched for behaviors that could be helpful. Although, in the face of the enormous destruction of such an attack, the behavior they were taught wouldn’t probably have been of real use.

But that was not the point. As the real problem was outside the capabilities of the people, the belief in the effectiveness of the behavior was good enough. The advocates of this educational initiative must have known quite well, that there was no point in ducking and covering. But it was much easier to achieve than to really solve the problem.

Such was the world in the times of the cold war.

In the testing world, the factory schoolers also do their ducking and covering by focusing on secondary work products such as reports and plans and test case counting and not on the testing itself. Same here, it is much easier to create templates, processes and standard operating procedures than acquiring the skills of an excellent tester. It is much easier to proscribe actions that can be followed like check lists. And the production of piles of paper is intimidating, it covers your ass and it bores intelligent people.

If you cannot do the real thing, engage in ersatz behavior instead. That would be cute, if all this testing was just a game and software was something that was presented as a spectacle in a circus. But there are many areas - especially in the medical software domain - where people’s lives might depend on the robustness of applications. That is not something to be handled with a cover-your-ass mentality.

Just recently, there have been two elaborate blog posts by Huib Schoots and Johan Jonasson on the subject of adaptability vs. context-driven. Quite interestingly, a discussion between a TMap advocate and Huib evolved. As expected there was no agreement because both spoke about different things.

As an example lets take the word ‘test’. In the context-driven world ‘test’ is a verb. It is an action that yields information. The factory schoolers understand ‘test’ as ‘test case’ or ‘test case document’. A test is something that is handled in a tool and proves coverage of something. So, when a factory schooler discusses testing with a context-driven person, they won’t understand each other because they speak about different things.

Whenever we do testing, let’s never duck and cover.

tags: context-driven, skill, secondary work products, factory school

(IMPORTANT: If you think comics are for children, please contact me on Skype before you continue reading. I’d like to have a clarifying chat with you. My ID: ilarihenrik)

Osamu Tezuka has drawn a lot in his short life that unfortunately lasted only 60 years. The mangas and gekigas above are from my Tezuka section and they represent only 8.2% of what he has created in his lifetime. Osamu Tezuka is one of the most incredible practitioners, not only by the standards of the manga industry.

We test software, Osamu Tezuka draws stories. Is there anything to learn from the great man? Or is this just some forced analogy? Maybe, maybe not. Let’s see if there is something we can make use of.

Do it every day
Osamu Tezuka has drawn every single day of his life. There was no day where he just sat around idly. He has drawn more than 700 tomes of manga with a total of about 150’000 pages and he was involved in countless films as well.

Shouldn’t we consider practicing our craft every single day? What have YOU done software testing wise today? Regular practice is the key to greatness.

Be a good story teller
Reading Tezuka makes you aware of his incredible story telling abilities. Some of his mangas stretch over more than 2500 pages (e.g. the great Buddha series — on the picture above on the lower right corner), and there are simply no passages that are boring. His stories are fantastic.

In order to practice bug advocacy, you essentially need to be a good and convincing story teller. Testing still often needs to be “sold”. The better you can come up with a convincing story of why it is important, the better your life as a tester will be.

Assemble people who help you
In order to keep up the pace, Tezuka had a big group of people who helped him with his stories by doing the blackening or the application of patterns or drawing the less prominent characters in the background. Tezuka acknowledged that he could not do everything himself and that it is helpful to have friends in his proximity who not only helped with the texturing but also criticized his work.

I believe that is something which makes the context-driven school of testing very strong as well. We tend to watch ourselves and give constant feedback while pushing ourselves to become better every day. It is a value we should be aware of.

To have some additional educational background is helpful
It might be a lesser known snippet of fact that Osamu Tezuka was a medical doctor. Although he never practiced as a physician, he has actually graduated as a doctor. This resulted in him being able to draw physiologically correct and fascinating details in some of his stories. I can highly recommend his collection of short stories about the outlaw doctor Black Jack. These short stories are outstanding. And they are outstanding because Tezuka included a second skill into his art. The fusion resulted in something far more remarkable.

That’s why it would make sense for us testers to educate ourselves in a wide variety of other topics. We should read about social sciences, immerse ourselves in ethnological methods of qualitative data gathering, psychology, cognitive sciences and of course mathematics should become our friends. And a lot of other matter, too.

Not being certified allows you to be great
Ha! Who would have thought that Tezuka is with us in this regard. Again, his outlaw doctor Black Jack is NOT CERTIFIED. And he does not even want to be certified because he has trained his skills to become the greatest surgeon on the planet.

Mushi Production
Well, the translation of the name of his animation studio - Mushi Production - is: bug production.

(An irrelevant yet interesting side note: While writing this post, my editor constantly tried to correct “mangas” to “mangos”, which I found hilarious because of my automatic spell checker’s complete unawareness of context)

tags: practice, skill, testing, learning

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/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/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

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

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