After careful consideration, I have withdrawn my submission to Swiss Testing Day 2019.

I have spoken at the largest testing conference in Switzerland several times in the past years. My experience has always been rewarding and I had a lot of pleasure interacting with the delegates. I really liked the Swiss Testing Day, and according to the delegates’ feedback, they liked my sessions, too. So, I again submitted an abstract to the 2019 event.

There is a two-phase process with Swiss Testing Day. First, you submit an abstract of your proposed session, which the programme committee then evaluates. If your abstract passes the first round, they ask you for your slides upon which they decide on definitive admission. After submitting my proposal, I received a confirmation of passing the first round. Different to past years, the confirmation email, however, contained the following sentence:

• Please be advised that if your presentation is chosen to be included in the main program, sponsoring at some level is required.

I submitted my slides and also asked what that sentence meant exactly. As it turned out, they added an additional condition to their admission policy. Any company that provided some sort of services (e.g. me at House of Test as a consultancy), is expected to buy a sponsorship for the conference. I told them that this is not acceptable and asked for an in-person meeting. We had a long discussion, but it did not change their position.

After having made a reasonable — yet failed — effort to help the organizers understand, that a speaker’s responsibility is to provide engaging content and not to bear any financial burden, I withdrew my submission. I decided to go public because I believe that behaviour like this diminishes the quality of conferences in general. It favours the ones who are able (and willing) to pay over the ones who have a good story to tell.

It is regrettable that some conferences still don’t reimburse their speakers for their expenses and in this specific case even add costs on top of that. I find that unacceptable. Therefore, I have come up with my short list of conditions to speak at conferences:

1. The conference reimburses ALL speakers for their expenses (travel/accommodation)
2. For workshops and tutorials, I expect an honorarium on top of expenses
3. I refuse any special deal for myself

The above rules do not apply to non-profit events, meetups, peer conferences and any event whose main purpose is community building.

Here is my call to action for all speakers out there: Refuse to speak at conferences that treat their speakers unfairly. Come up with your own rule set and make it public. I do, however, understand that this is easier if you are an established public speaker. But if you are, your statement will help new voices to emerge. It will also help speakers with limited personal funds to come up on stage and tell their compelling story.

Let’s together work towards a more balanced relationship between conferences and speakers. The future is bright!

If you agree with me, please sign my online petition.

tags: conference, paytospeak, public speaking

As testers we try to remove all filters that prevent us from seeing the product for what it is. As barefoot runners we try to remove all fillers beneath our feet that prevent us from feeling the ground for what it is. Hah! Isn't it wonderful, let's indulge in exploring this hippie stuff and see some more striking similarities.

Exploratory Running
Your feet are a finely tuned exploration instrument. You cannot get a feel about the terrain before you explore it. By running on various surfaces you concurrently learn about the texture, decide on your next steps and design your path. Sometimes you may also find yourself lost in the woods and through exploration you'll find back to the light.

Automation in Running
Running in shoes is a labor intensive repetitive activity which will bore you to death and give you bad karma. As soon as you remove your shoes and transition into a highly sophisticated forefoot running style, your calf muscles will become spring loaded and will give you back the energy with each stride. You will have achieved partial automation of your running process. Then you can run it over and over again.

Agile Barefoot
I am sure — sooner or later — you will go through the following transition. You might enjoy running along a waterfall, but believe me, when you suddenly find yourself on sun heated black asphalt, your feet become incredibly agile and you will start to sprint almost immediately. In retrospective you should have laid out your route a bit more carefully on your (sc)run board.

Running Heuristics
Here are a couple of useful barefoot running heuristics: Run forefoot, be feather-light in your stride, don't go too far too fast too soon, take care of your sole, use a quality foot creme, don't break your metatarsal bones, tip your waiter.

Barefoot Reporting
Yes, your soles will reliably report to you after every one of your runs. Pachamama has given you all the information you need. Read it thoroughly and adjust your running. Don't forget to remove the crushed bugs from your feet.

Highly Cushioned Running Shoes
These are the ISTQB of running, so to speak. A highly scalable business model selling you something you don't need. Their marketing has been quite sophisticated and it has tricked people in believing there is value in it. Don't fall for such nonsense. It's not good for you and you might get hurt.

Factory School Runners
Oh, these poor souls! Still heel striking and not understanding that it neither worked forty years ago nor does it today. And they still wear these heavy weight "shoes". What a wasteful behaviour.

And after each satisfying run, have a spirulina-green-tea-smoothie with an organic kale salad, make a peace sign with your hands and don't forget to tip your waiter. Kumbaya, people!

BTW: If you happen to be at Let's Test Conference in Sweden this year, I will hold a barefoot running workshop. We meet on Tuesday, May 26 at 7:30am in front of Runöhallen. Don't forget to forget your shoes and come along!

tags: running, testers, barefoot

image credit: https://www.flickr.com/photos/wenzday01/6027317553

My Beliefs
I believe the agile and the context-driven communities are highly compatible and should make every effort to get married at once. The two communities have not been too close in the past and I believe they have not yet appreciated each other's value. My experience has shown that it becomes a winning ticket as soon as the two communities are exposed to each other in a professional setting. When it comes to education I believe demonstration is far more powerful than presentation. And that is exactly what we did at eBay.

Initial Setting
At the European Product Development organization at eBay we had five scrum teams located in London, Berlin and Zurich. They consist of highly skilled developers most of whom believed that if they applied all good development practices there would not be a need for any testers. Hence, they did not have testers aboard their teams. In parallel I lead a team of testers who occupied themselves in more waterfall projects offering testing services to other parts of the organization. No professional contact between the two teams. We decided to do something about it.

Transformation
About mid-year in 2013 we started to change the set up and place testers into the teams. It started with a first experiment, where Jan Eumann commuted between Berlin and London to offer his services to a specific project. Jan has vast experiences as a software engineer and consultant from his days before eBay and that certainly helped him to establish a service culture towards the team and boosted his acceptance. He later joined the team in Berlin and actively helped to bridge the connection to the business units in Berlin, with whom he already had good relations.

Earlier that year I hired Ben Kelly, who was one of the first testers getting himself fully involved into one of the teams in London. Since Ben is a master in finding words for what he is doing, he was able to convince the team that there was far more to testing than they initially believed. Ben has a rare talent of being humble and assertive at the same time.

We then expanded to the team in Zurich with Daniel Moennich early 2014. Daniel has a sound background in software engineering, which helped him a lot with gaining acceptance with his team. He introduced a lot of critical thinking at the beginning of the project and his approach of solving problems for the team in a calm way demonstrated his value.

At Let's Test in 2014 one of my missions was to identify yet another tester to hire for one of the teams in London. I spoke to many attendees and tried to evaluate who could be a match, which was difficult because the profile I was looking for required a sound level of software engineering knowledge and a ruthless mind of inquisitiveness and deep understanding of testing.

I then stumbled across Ioana Serban. I recommend you meet Ioana if you get the chance to do so. She's one of the most energetic testers I have ever met. Ioana is smart, technically proficient, inquisitive and will certainly not take shit from anybody.

Of course I made mistakes, too. At one point I hired somebody with whom I did not clarify what it means to be embedded as a tester in one of the teams. We both soon became unhappy and our paths went into different directions again.

Hiring the right people
Hiring people is a tricky matter because it is tremendously difficult to evaluate people in the artificial setting of an interview. Our process evolved over time and we found the following approach to be suitable for our needs.

I talked on the phone for about 30 minutes to applicants who passed my first screening of their CVs. I wanted to establish their general views on testing and get a feel on whether or not they could fit into our teams. Then they had to write a little application incl. unit tests. We evaluated their work in terms of elegance of their solution and the quality of their tests. If they passed that, we invited them for a full day at the eBay office and we did something we called "Sprint in a Day". The applicants were exposed to the teams we were hiring for and they had to solve some hands-on problems. In between senior people talked to the applicants and established an impression by doing behavioural interviews. All this helped us to gain a rich impression on applicants and if they did well, we hired them.

Uncertainty
When we decided to place testers aboard the teams I had no idea of how that was going to work out. It was a path of little experiments and learning as we went ahead. Our set up was that all testers were reporting to me but their day to day accountability was towards the team they were in. This meant that I kept my hands off the operational level and let the testers do what they were doing. As a manager this can be uncomfortable, since it is a loss of control and I as a manager — like many managers — like to be in charge.

I discovered that the "be in charge" had to take another form. Rather than involving myself in the day to day matters, I took responsibility to hold the community of practice together and make sure the testers in the teams exchanged their ideas on a regular base.

Outcome
Currently none of the teams would ever want to do without their embedded testers. Their opinion shifted not because I tried to convince them of the value of a tester, but because the brilliant people I talked about above demonstrated their value. Not only are the teams operating very smoothly with the current setup, but parts of the rest of the organization have suddenly become interested in learning how the European Product Development Teams handled their testing. What we have established is an incubation cell that will have significant influence on the whole organization. This is much more than I expected to achieve.

Learnings
Leadership is not control. It is also not about me. It is much more giving people the liberty to shine and not to take a center position, but to support the flow of what is happening by offering assistance where it is asked for. At one of our workshops the team came up with an Agile Testing Manifesto, which gave us an outline of how we work.

The experience with the European Product Development team of eBay has demonstrated to me that the context-driven way of testing is indeed highly compatible with the agile mindset. It is an encounter between two tribes, which both strive for craftsmanship and high quality of work. I hope the two communities move closer together in the future. People using software will gain from it.

tags: agile, context-driven

Almost three years ago I joined eBay with the goal of building up a team of world-class testers and changing how testing is performed in that company. It has been quite a ride with a lot of international travel and idea exchanges with a broad range of smart people.

I am proud to have been able to influence some fine individuals in their pursuit of becoming really good at what they are doing. I am grateful to some extraordinary talent from the context-driven testing community, who joined our team. It is hard to leave them, but — who knows — our paths might cross again in the future. I certainly hope they do.

There are two things I am most proud of:
I convinced the developers and managers of the five scrum teams in our part of the organization that having a tester embedded in their teams is a good idea. Their initial reaction was: Huh? Testers? We don't need testers! Today, their reaction is: There is no way we would do without a tester embedded in our team. I have married Agile with Context-Driven at eBay.
The other thing I am proud of:
Together with Ben Kelly we established the first and only testing education workshop we held for interested testers in San Jose and Portland. It has been a great pleasure to demonstrate critical thinking and tester games to a wider audience within eBay.

The three years at eBay have also been an intense learning experience. I have refined my views on what good testing is all about. I also learned how to navigate complex social systems. Today I feel more confident to negotiate outcomes that are mutually beneficial.

Farewell eBay, may you live long and prosper!

and:

Good morning House of Test!

Maybe I have not achieved all my goals at eBay and I am hungry for more. Maybe all past experiences have only been a preparation for what is coming now. I am joining House of Test to build up our Switzerland branch. We are currently looking for and hiring the finest testers on the market and I can promise you this: Being part of the House of Test experience — be it as a consultant or as a customer — will be breathtakingly awesome. To quote, and slightly alter the quote, of my good friend, Ben Kelly: "We will be different, and by different, we mean better".

I am tremendously excited to be part of the most vibrant consultancy company on the planet and expand its reach to Switzerland.

Our House of Test consultants will relentlessly focus on bringing value to your organization. They will not only do that by offering their services, but also by helping your own crew to grow professionally. If we can't help you, we will not be offering our services. But if we can, you will be amazed by our determination to provide you with the most outstanding service.

Does this sound appealing to you? Are you looking for external support by one of our fine consultants? Then let's meet, drink a cup of coffee and find out how we can help you.

Find out more about us here.

tags: ebay, House of Test

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

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

I sent in an abstract.

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

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

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

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

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

tags: public speaking, conference, teaching

Exactly one year has passed since I joined eBay on July 1, 2012, and it has been quite a ride. Overall, the experience has been tremendously positive, mostly because the people I work with are both smart and a pleasure to spend time with.

Since my team is distributed at four different locations in Europe (Zurich, Berlin, Paris, London) and our projects mostly originate in San Jose, California, I am traveling significantly more often than in my previous jobs. For many people, air travel is tiring; I don’t perceive it as such. On the contrary, I enjoy the time on a plane because it allows uninterrupted time to read a book or do some thinking.

My team covers 12 European eBay sites in 7 different languages. In the past year, we have tested roughly 100 projects of features that were rolled out to the European sites. I am impressed by my team’s capability to handle all this.

There are many different approaches to testing within eBay, which often leads to intensive discussions with my colleagues in the US. In many ways, the misunderstandings are not unique to eBay. For some reason, there is a widespread view of dichotomous antagonism between manual and automated testing, whereby automation is regarded by some as a superior form of testing.

In these kind of discussions, I often appear to leave the impression of being against automation. Well, I am not. I am - however - against undirected/unreflected automation. I am against automation for the wrong purpose. I am against automation that is only done “because it is engineering”.

I am fiercely in favor of automation if it helps the team with their testing. I am forcibly in favor of automation, if it does the checking necessary to indicate regression effects. I am emphatically in favor of automation, if it does what automation does best - fast, repetitive checking of facts.

I’d be happy if one day the manual vs. automation discussion was no longer necessary.

Anyway, I am proud that my team does not quarrel with such lack of subtlety. They all have a sound mental model of how to do good testing. What more could I wish for? So, thank you team and everybody else in the organization I am in contact with for the splendid experience so far.

tags: testing, job, learning

tags: conference, observation, description

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

Zounds! What a menacing title, you might think. Yes, I am fishing for effects and the word “Heroin” always appears to do the job. And so does “Fuck”, “Motherfucker”, “Fuck you!” and “Fuck it!”. “Cunt” isn’t bad neither.

As a freethinking European I find it amusing when you desperately hide these words behind tiny asterisks like “F*ck” or suggestive ellipses like “F…”. Come on, prude people, get a life! None of you has a problem spelling the word “kill”, do you? Fucking is pure pleasure, killing is not. What’s wrong with you people?

Admittedly, fucking is not the topic of this post, but after the highly screened and politically correct ebaytechblog post, I am gasping for some “political incorrectness”-air. So - if you allow me - fuck you all!

The topic is Twitter and its importance to the context-driven community. As I see it there is the twin fix of Twitter and Skype that do the job. They both keep the network connections alive. Twitter plays an important role in the dog-sniffing activities of the people in the context-driven world. Some friendly hellos, fervent fights about semantics and an abundance of pleasurable disputes and useful links.

Whenever there is a need to either take the discussion offline or elaborate on something more in-depth, Skype is the tool of choice. I have had many good discussions both on Twitter and Skype. All good so far.

Only that there is a problem here: Twitter is a terrible attention grabber and temporarily transforms - well, I don’t know about you, but it certainly does it to me - people into ADHD victims. In the course of a day there are countless checks on new tweets and there always is a strong urge to engage in discussions.

That is not very good when you should work on longer term projects, such as preparation of a conference presentation. One’s own vainness is also in the way of many things. It is flattering if your tweets are re-tweeted or favored by your followers.

I did an experiment today. My thought was: What kind of tweet would generate the most re-tweets? It certainly had to be crispy and short, unexpected, funny and unusual. This is the tweet I came up with:

QA = Questioning Assumptions

It produced a good number of re-tweets and marks as favorites. But why would this be important? I don’t know.

Still, Twitter plays an important role in maintaining the relationships between the context-driven testers. It is just a great experience to meet some of my Twitter friends physically at conferences. It is like meeting old friends you have never met before.

Semantical discussions on Twitter tend to generate a common view on the meaning of things. Twitter has a tremendous power to make thinking better and have people experience deep learning.

The one thing I have not yet figured out is how to actually handle Twitter in order for it to not rob a significant share of my time. I’d be very much interested in how you keep the balance of sanity.

Truthfully yours,
Ilari

tags: twitter, education, networking

‘This is a nice one.’ A very simple sentence consisting of five words. Yet completely unintelligible. What is ‘this’? What class of things does ‘one’ refer to?

It is indexicality, one needs to take into account. A word or an expression can be considered indexical, when its meaning is tightly connected to the circumstances or the context of its use. As an example, the word 'this' is only fully understandable if it is either accompanied by a hand or head gesture pointing to what it refers to or if in the preceding sentence indicates a reference.

• This is a nice one (Together with a pointing finger to a beautiful rose)
• This is a nice one (Preceded by the sentence: ‘We just found some gold nuggets’ )

Mitigation of ambiguity in direct human to human interaction is quite seamless and its procedure is mostly not even noticed. A facial expression, an utterance of 'huh?' or a short interruption with a clarifying question helps to create meaning. Meaning of words and sentences are mediated by their interactive use between humans.

As a tester it makes a lot of sense to be physically close to a developer who can fix a bug. Even non-linguistical indexical behavior, like a pointing finger, works just fine. I point to something on the screen and the developer is ready to fire up the debugger.

In written language this is a bit more tricky. And bug reports are often written in a bug tracking tool. It is just not the optimal choice for clarity. However, in a bug report, some of the ambiguous effects of indexicality can be mitigated by a clarifying screen shot. It provides the necessary context for understanding. Therefore:

• This leads to a 404 page not found (followed by a screenshot with a button circled in red)

Alright, boys and girls, be aware of possible indexicality the next time you write a bug report.

BTW: ‘Nice’ has always been one of these words that irritate the hell out of me. Noncommital, superficial and mostly just semantically muddy. Some time ago, the meaning of ‘nice’ was ‘stupid’, coming from its latin roots ‘nescius’ (=ignorant). My good friend George Carlin - in his context - could not have expressed it better.

tags: linguistics, bug reporting, writing, ambiguity

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

The year 2012 has been an exceptionally eventful and busy year. It was actually the first year I took testing really serious and it was also the first year I started to become active in the context-driven community. Since there are so many outstandingly smart people around, it is a highly stimulating intellectual experience. I am very happy to have chosen this path.

Education
The year started with a one-day workshop Critical Thinking for Software Testers with James Bach. James was in Switzerland in March for the Swiss Testing Day and it was a good opportunity to have him present his workshop at Phonak AG. Quite interestingly there were not only testers participating but a fair share of developers, too.

In May I participated in BBST Foundations, which was quite hard as it coincided with Let’s Test 2012. BBST courses are very time intensive and each participant can decide individually about how much effort to put in the course. I can recommend the BBST courses to anybody who has serious aspirations in software testing.

Shortly after I had started to work for eBay, I organized the famous Rapid Software Testing Course with James Bach. Additionally to my own team I invited testers from all around Europe from eBay companies to join us. We spent three wonderful days contemplating about software testing and the puzzles were one of the most refreshing part.

October/November was filled with BBST Bug Advocacy, which again was quite an experience, this time for personal reasons.

Conferences
The year started with Swiss Testing Day. At that time I was still a member of its Conference Board and since I was in charge for the Keynote Speakers, I invited James Bach to have one of the Keynotes. He was as energetic as ever and the following book signing saw all his Buccaneer Schoolar books being sold out in no time.

In May it was time to fly to Let’s Test. What a conference! I had my first introduction into facilitation with Paul Holland. I think that Let’s Test has established itself as being /the/ context-driven conference in Europe. You need to experience it to know what I mean. I am very much looking forward to its second edition in 2013.

The weekend before CAST we gathered for Test Coach Camp 2012 in San Jose. We were a small group and we intensively discussed coaching of testers. I think that coaching is an ability which will become even more important in the future.

Test Coach Camp was followed by CAST 2012, where I presented two Emerging Topics sessions: ‘Observational Proficiency’ and How to ‘Make ’em Read Books’. I also enjoyed facilitating some of the other tracks.

In October, there was the Dutch peer conference DEWT2 in Driebergen; 2 days of intensive discussions on context-driven topics. It was an intimate event with interesting people. And it was quite cool to have a lunch walk while discussing management styles with Jean-Paul Varwijk in the forest of Driebergen.

In November I unfortunately had to cancel my attendance at Agile Testing Days 2012, since my youngest son was in hospital.

The year finished with a one hour talk at the technical University ETH in Zurich, where I talked to software engineering students about how we test at eBay and I presented my general views on what skillful testing means.

Books
Not as much as I wanted. 2012 was so busy that my book reading suffered severely. I don’t like that and I have some plans to change that in 2013. However, five of the books that influenced my most in 2012:

• Wolfgang Metzger - Laws of Seeing
• Ludwig Wittgenstein - Über Gewissheit
• Robert A. Stebbins - Exploratory Research in the Social Sciences
• Paul Feyerabend - Against Method
• Robert D. Austin - Measuring and Managing Performance in Organizations

Job
Probably my most radical decision in 2012 was to change my job. I had been working for Phonak AG for more than seven years and when the opportunity arose to start with eBay, I decided to have a go. There was a huge number of applications for the position and I somehow managed to convince them that I was the right choice. I am very glad it worked out. Working at eBay is wonderful, there is a lot to learn and my flight schedule has become very busy. I was sitting on a plane on 16 trips and I travelled 53,318 km in total.

Skype Coaching
With a lot of help by James Bach and Anne-Marie Charrett I started coaching testers on Skype. I have done 30 one to two hour coaching sessions in 2012. Coaching testers is a perfect activity to learn more myself. Currently, my coaching activities are on hold because everything else is very busy and I cannot do everything.

Twitter & Blogging
I both value Twitter for the richness of personal contacts and loath it for its capability to steal my time. I still want to figure out how to handle that in 2013.

Blogging has been an outstanding experience. This is my fortieth blog post this year and I value writing because of its capability to sort my thinking.

People
One of the experiences I valued most in 2012 was to have met so many outstanding personalities. I hope to not have forgotten anybody.

Henke Andersson - Very upbeat, highly knowledgeable, and a fun person to spend time with
James Bach - Probably the most important person for my own testing career and a good friend, too
Jon Bach - It is great to have Jon around at eBay, every encounter has been filled with intensive testing discussions
Scott Barber - What a wonderful person with a refreshing energy level
Sigge Birgisson - Very kind and energetic person
Michael Bolton - One of the sharpest and most educated minds I know
Tony Bruce - I think I have met Tony at almost every event I went to in 2012
Fiona Charles - Fiona impresses me with her calm yet firm approach to things
Anne-Marie Charrett - One of my mentors in the domain of Skype coaching
Pascal Dufour - Very intelligent, should find more time to discuss testing with him
Henrik Emilsson - We look alike! Hopefully it works out with the visit to Sweden in 2013
Markus Gärtner - I am so impressed by Marcus’ productivity in all areas around testing
Julian Harty - I like Julian’s kind and helpful energy
Leo Hepis - Still remembering well his fantastic introduction into the world of Virginia Satir
Matt Heusser - Also one of those people whose energy level seems to have no upper boundary
Doug Hoffman - Thoughtful and wise. In a several hour discussion, I learned a lot about american corporate culture
Paul Holland - Facilitation is a demanding job. Paul knows everything about it. And he values a good bottle of beer. Or two. Or three.
Ola Hyltén - I am glad to have met Ola in person and I am so sad that he no longer is among us
Martin Jansson - What a fantastic Test Lab Martin built for Let’s Test. Hopefully again in 2013
Johan Jonasson - Without Johan, Let’s Test would not be here. So: Thank you Johan
Cem Kaner - If only I had a tiny slice of Cem’s testing wisdom
Maria Kedemo - Always a pleasure to chat on Twitter. Looking forward to your session at Let’s Test 2013
Ben Kelly - Nobody has a darker humor than Ben…Well, maybe Ben in combination with Paul Holland might top it
Michael Larson - One of the most friendly people I know. Meeting Michael automatically makes you more happy
James Lyndsay - Hopefully it works out with the Test Lab session at eBay in 2013
Iain McCowatt - If you want to have a deep intellectual discussion, Iain is your man
Meike Mertsch - It is very cool to see how intensively Meike pursues her path in testing.
Simon Morley - Simon is from England but since he lives in Sweden, he decided to speak Swedish. I am impressed
Duncan Nisbet - Very refreshing and he has a serious plan about becoming a world class tester
Ray Oei - I was happy to enjoy Ray as an instructor for both BBST courses
Alan Richardson - Besides being an excellent tester, Alan opened the fascinating world of hypnosis to me
Alexandru Rotaru - We should refreshen our plans for a session in Romania next year
Robert Sabourin - Glad to have received the Gallows Puzzle from Robert
Simon Peter Schrijver - Simon is a hard working tester and an outstandingly friendly person, too
Huib Schoots - If you want a good laugh, spend time with Huib. Test yourself if you can pronounce his name correctly
Aleksandar Simic - Very soft spoken and a lot of dedication for testing
Ben Simo - My main source for old and useful books. Has a fantastic sense of humor
Neil Thompson - If you think you can draw a complex diagram, meet Neil. He’ll top you
Jean-Paul Varwijk - Should there be a need to attribute ‘senior’ to somebody, Jean-Paul would the number one candidate
Zeger van Hese - There is still this fantastic picture of which I want to write a deep description of
Oliver Vilson - A man of honor. I deeply respect his drive to lead an independent test consultancy company in Estonia
Wade Wachs - If I had to label somebody as a ‘free thinker’, it would be Wade
Christin Wiedemann - Exceptionally smart person. And Christin shares my conviction that soap is always the better choice
Benjamin Yaroch - Somehow I rarely agree with Benjamin. Maybe that is the reason I value him

In Switzerland:
I also met some interesting Swiss testers in 2012. I think some of them will become more active in 2013: Sandro Ibig, Chris Glättli, Tomi Schütz and Simon Berner

Still to meet:
With some testers I only conversed electronically, but I am looking forward to meeting them one day, hopefully in 2013.
Jesse Alford - Jesse is both a skillful writer and a very sharp mind. He is new in the testing business. I am looking forward to meeting him at PSL in April 2013
Jari Laakso - Jari is the master of Twitter and I am looking forward to meeting him at Let’s Test 2013
Savita Munde - I have spent many coaching sessions with Savita. I hope her testing institute is doing well
Raimond Sinivee - Without Raimond, I would not have finished BBST Bug Advocacy. I hope he’ll be at Let’s Test 2013 so I can buy him a beer or two
Richard Robinson - Hopefully there is some opportunity to meet Richard next year. Very much enjoyed spending time with him during BBST Bug Advocacy

Outlook 2013
In general, I want to identify wasteful activities and stop doing them. These include - among others - watching TV series, reading news in daily newspapers and mindlessly goofing off on the internet.

Having experienced the power of writing, I intend to do it even more intensively. Since there are some excellent testing publications, I want to write articles for them.

In 2013 I want to establish myself as an expert in the domain of observation. I think that in the domain of software testing, it is a very important aspect that needs further exploration.

Since I am not a very good programmer, I want to spend significant time on getting better at it. eBay is the right place to do it, since we extensively use test automation.

I could imagine that /the/ highlight of 2013 will be PSL. Everybody I know who has been there, told me it was quite a life changing experience. Now I want to see it for myself.

On the conferences side I am most looking forward to Let’s Test 2013 and CAST 2013. I think that these two conferences are the best, the testing world has to offer.

tags: learning, retrospective

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

BBST courses are known to be tough and they ask for a lot of quality reasoning. The workload should not be underestimated. After having spent a fantastic time during the Foundations course, I thought it would be a good idea to continue with one of the other two courses.

It appears that - although there is no requirement for it - most people choose Bug Advocacy as their second course (Why is that so?). I was excited, because I knew that some of the people I did the Foundations course with, would also join.

Bug Advocacy teaches you that writing bug reports is a persuasive activity, you need to make a case for your findings and convincingly explain, why a certain bug is worthy to be fixed. There are many dimensions to be considered.

Off we went into the first week.

It is advisable to carefully plan the BBST courses during times, which are not too busy with other obligations in order to free your mind for the course. This can be difficult as unexpected things can come up any time. In the first week I had a workshop with my team at eBay in Paris. Hard work, and very nice, because Paris - among other qualities - offers quite a variety of gastronomically refreshing opportunities.

I skipped the first quiz on purpose. Now, I admit that I am opinionated against the BBST quizzes. There are many excellent elements in the BBST courses, the quizzes are not among them. I regard them to be of minor value. Yes, they are meant to provide feedback on how well one follows the lecture videos, and they try to evaluate whether or not the students have understood what Cem was talking about.

My criticism on the quizzes is, that because of their nature - multiple choice questionnaires - they do not allow any subtlety and the answers are either right or wrong. I do not agree with that. Whatever answer one gives, if one is able to defend it with convincing arguments, it is not necessarily wrong.

When I came back from Paris, we were in full swing of the course and there were many exciting exercises on the subject of bug advocacy. What I enjoyed most, was the high focus on evaluating the quality of bug reports, and, on a further meta-level, evaluating the evaluations of bug reports. These are exercises, which help to become really good at arguing about the quality of writing.

Then, at the end of the first week, both our sons fell ill. Our older one (Marvin, 7 years) had a not too serious winter cold, but the little one (Nelson) - defenseless at his young age of 9 months - really caught something nasty. As it is, he acted as a biological petri dish, and so the germs multiplied. My wife and I hardly slept as he was coughing his way through the night.

In the following week he became weaker and weaker, and then it was shockingly clear to us that something serious was happening here. When we went to the hospital, he was immediately put into isolation and received additional oxygen and heavy medication. This is devastating to parents, as seeing ones own children sick is undescribably troublesome.

Bug Advocacy continued its course and in between hospital visits (my wife stayed there permanently), organizing the bigger one's school schedule, cooking breakfast/lunch/dinner, keeping eBay stuff up and running, I struggled to find time for the BBST exercises. I was close to quitting the course.

But I didn't until after 5 days in hospital the doctors declared that our son might have caught tuberculosis. Now I know what people experience, when they say that they lost the ground beneath their feet. It is a feeling of utter helplessness and complete despair.

It was already close to the end of the third week, I had under tremendous difficulties finished all my assignments and there was only the exam week to go. I just could not continue any more. It was too much to handle. I wrote on the moodle page that I stop the course immediately. I also cancelled my session at Agile Testing Days and every other non-family duty. We had other priorities now.

A couple of days later the suspicion of tuberculosis had blessedly not materialized and our son was getting better from day to day. Raimond Sinivee contacted me on Skype and and in a remarkably cautious and supporting fashion encouraged me to maybe still try to do the exam. I honestly had not taken into consideration to do that, but his message changed my mind. So that is what I did.

Our son was released from hospital after 10 days and now he is slowly recovering. It is great to see him smile and play again.

As I wrote in the introduction, BBST courses are hard and one should plan accordingly. And sometimes life just comes along and performs a test. I am not sure if I passed, but I am sure that the multitudes of pressures I experienced was close to what I can handle. I know my limits now.

tags: BBST, learning, bug advocacy

I have always enjoyed the sound of the Dutch language; for one, because there is a proximity to Swiss German and also because it sounds friendly: ‘GEEN FIETSEN PLAATSEN’ - not here, put your bike elsewhere.

Schipool welcomed me with enthusiastic rainfall and energetic wind blows. It was Friday, 5 October 2012. I decided to have a walk in Amsterdam. Jordaan is a good place to drink coffee and contemplate. Later the day I met Joep Schuurkes and together we drove to Driebergen, which is about a 50min drive south-east of Amsterdam.

The DEWT guys had found a great place for a peer conference. Hotel Bergse Bossen is located in the middle of a forest and there is a lot of space to sit together and confer. And what would be a better start of a conference than have some beers together.



We had a relaxed evening, and Jean-Paul Varwijk gave a short lightning talk which resulted in a discussion whether the club of testers, who subscribes itself to the context-driven school, was too elitist. I believe this is a question that needs some more thinking.

The testers I know from the context-driven school all have at least two character traits. They all are very eager to learn as much as possible, and - and this is important - they also want to share it with anybody who asks. Yes, there is a relentless urge to become better, and that might put off some people. Should we care? Yes, of course we should. But under no circumstances would it be justified to move in the direction of mediocricy. And what we shouldn’t do neither, is become a club of arrogant pricks, frowning at everybody else.



The second day was filled with talks I won’t go into in detail because they have already been elaborated on here. Instead, I want to mention our walk in the woods, honoring the peripatetic school. I had an engaging talk with Jean-Paul Varwijk about dysfunctional management systems. Why not establish regular walks at conferences? I have always enjoyed concurrent thinking, talking and walking.

To finish up here, I think Simon Peter Schrijver deserves a special mention, as he found a healthy middle ground between assertiveness and humorous coolness as a facilitator of DEWT2. Well done, man!



I enjoyed coming to Driebergen, and I hope to come back soon. DEWT3 will take place on the weekend of 20/21 April 2013. Would be happy to join the Dutch crowd again.

tags: peer conference, context-driven, peripatetic school

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

Back in the sixties, some military dickheads had a good idea. Why not use atomic bombs for engineering purposes? Let’s bomb ourselves a harbor. Let’s get rid of that nasty mountain. Or why not just build a new canal between the pacific and the caribbean sea?

One bomb after the other planted in a row and - hey - he he, it’s automated and we need to do nothing else but pull the trigger. A good name had to be found and what would be more obvious to choose from for the god fearing good Americans than the holy scripture?

"And he shall judge among the nations, and shall rebuke many people: and they shall beat their swords into plowshares, and their spears into pruning hooks: nation shall not lift up sword against nation, neither shall they learn war any more" - Somewhere in the Bible

And that is how Operation Plowshare was born to henceforth bring the blessings of the modern age to mankind. Sounds good, doesn’t it? Only that quite obviously there are some shortcomings to this kind of project. Radiation might leave the harbor useless, the costs could rise to astronomic proportions. They did not care about things like that and so the project died a silent death somewhere in the seventies.

Just recently I overheard some snippets of a conversation in the cubicle next to mine: “Yeah, just give me the coverage”, “No, I am only interested in the automation part”, and the best of all: “I don’t care”. You don’t care? Really?

Does that sound like Operation Plowshare?

It is the same mindset that takes one advantage (creating a hole quickly/executing a test suite rapidly and repeatedly) and completely disregards any shortcomings (radiation wasteland/untested wasteland). The ‘full automation’ extremists probably might not even have a good mental model of what ‘full’ or ‘complete’ means. Just do it for the sake of it because it is ‘engineering’, right?

But the analogy is only partially valid. Unlike nuking ourselves some harbors, test automation has value. It does have huge value, actually, if it is applied for the right purpose. In some cases, it is enormously helpful for regression testing, but it does not give any ‘guarantee’ for not having messed up.

Automation checks things, and it checks only what has been thought of and might (or might not) catch anticipated bugs. It is a lightweight insurance ticket for a part of the system. And in its execution it is fast (not so much for its development, though). That’s all.

Is it somewhere rooted in the western thinking style that we seem to insist on opposing binary categorization for concepts and ideas? It is either or, not both. It is complete nonsense to think of automation and manual sapient testing as being opposites. They are not.

So, let’s not be military dickheads and instead apply each test automation and manual sapient testing where it is most suitable. Maybe sometimes in the future, the ‘let’s automate the hell out of it’-idea also dies a silent death, much like Operation Plowshare did.

tags: automation, testing, obsession

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

Some years ago I studied Sociology and General Linguistics at the University of Zurich. That was before my time as a software tester and I enjoyed Sociology a lot. Well, at least part of it. Quite interestingly, Sociology and - in my observation - many of the human sciences, display a minority complex towards the so called hard sciences such as Physics.

This leads to a sad obsession. Make everything quantifiable.

But I was much more interested in qualitative studies. There is a brilliant sociologist from France - Jean-Claude Kaufmann - who studied and described many of the deeply human activities and behaviors. For instance, how men behave on beaches where women do topless sunbathing. The book: Corps de femmes, regards d’hommes - La sociologie des seins nus (women’s bodies, mens looks - the sociology of naked breasts). A fascinating read!

Also, one of my lesser known heuristics is, that men with extravagant mustaches are interesting people who have captivating stories to tell. Jean-Claude Kaufman has an extravagant mustache. Judge yourself:



On the other hand, I have always found that quantitative Sociology has only boring stories to tell. Its findings tended to be things that everybody already knew. There is hardly any discovery. Not even mentioning the fact, that the whole complex of validity of what has been found out through measurement, leaves some questions open. Measurements often give a false sense of certainty.

Our good old friend Availability Bias enters the scene: "if you can think of it, it must be important”. And we are already deep in the domain of software testing.

It is not difficult to count something and put that counting result into relation to something else. And - hey! - we are already 50.4576% done. Only that this has no relation to any relevant reality. It is utter nonsense. It is dwelling in fantastic la-la-land. And our users couldn’t care less about 50.4576%. They want a joyful experience while using our application.

Peter Drucker - the famous management man - once said: “If you can’t measure it, you can’t manage it”. A simple sentence that stuck in the simple brains of too many simple contemporary managers. That statement is of course not true, as every parent on earth knows from empirical experience. You do not quantitatively bring up a child. You don’t draw progress charts. You tell stories and pass your time playing and laughing.

But because many managers are too busy collecting meaningless data, they no longer find time to read books and have missed that Peter Drucker later in his life had serious doubts about his initial statement. It is not only us testers who suffer from that lamentable laziness.

I’d rather go with Albert Einstein instead: “Not everything that can be counted counts, and not everything that counts can be counted.”

tags: testing, quantitative, qualitative, management

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

Some time ago I posted a set of questions. Some of my fellow testers posted their answers. Some of them were really good. Let’s see what my own reasoning is.

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?

This immediately triggers a follow-up question. What do I mean by ‘counter-produtive’? A productive outcome - after having asked a question - would be: 1. the question resonates with the receiver and 2. generates an answer that helps the questioner to reduce uncertainty within the context of the question asked.

By ‘resonate’ I mean the receivers willingness to give you an answer. By ‘reduce uncertainty’ I also include an answers like ‘I don’t know’ or ‘ask somebody else’.

A counter-productive question either produces a failure with the former or the latter or both. In order for a question to resonate, the receiver needs to be ready to listen to you. If the receiver is in a mental state which incompatible with your need for an answer, the question becomes counter-productive. There is no use in asking anything if the receiver is stressed, does not feel competent or if the receiver is in an annoyed state of mind.

Some questions produce surprising answers. It may not be what you expected. Given that condition 1. is met, you should continue with refining your question until a productive answer is given.

In my perception the context-driven crowd describes itself as above average smart. This can result in asking questions just for the sake of it. It can be observed regularly on e.g. Twitter. I am guilty of it myself. I think we should exercise good judgment when asking questions. Am I just asking because I like my über-smart question, or do I really want to 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?

My answer to this question is: I don’t know. It could be the other way round. Good testers just like to exercise their brains and therefore like to solve puzzles more than others. Deliberate practice results in mastery.

Now, a good puzzle often asks for lateral thinking skills. Lateral thinking skills are good for general problem solving. And there is a lot of general problem solving in testing. Hence, exercising on puzzles might help to become a better tester.

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?

No, we should not. There are many reasons why somebody has a certification and maybe it was hard work to obtain it and the hard work result in the tester being proud of his/her achievement. Also, attacking people hardens the relationship and certainly does not change the opinion of anybody.

What we should put our energy in, is, in the following order: 1. set a good example ourselves by demonstrating what good testing is 2. argue against the certification and the certification providers. The certification industry is driven by monetary ambitions and not by the urge to enhance testers’ skills. That is what we should point out. We should not let the certification industry spread bad ideas about testing.

I very much believe in nurturing positive alternatives. Let us show what good testing is and let us concentrate on building a valid alternative to certification. A tester generally has two possible paths: Be employed or be independent.

When a company hires a tester, they want to know if he or she can do the job. Current certification schemes not being an option, then how exactly do we meet that need? Peer certification? A general ‘reputation score’? How? I do not have a good answer to that.

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?

Software testing belongs to the knowledge worker domain. The acquisition of knowledge depends on your ability to do so. The Cattell–Horn–Carroll theory lists ten general areas of intelligence:

• Crystallized Intelligence
• Fluid Intelligence
• Quantitative Reasoning
• Reading & Writing Ability
• Short-Term Memory
• Long-Term Storage and Retrieval
• Visual Processing
• Auditory Processing
• Processing Speed
• Decision/Reaction Time/Speed

If you go through this list, you will probably agree that all are applicable to software testing to some extent. The better you are in each of these dimensions, the better your testing will be.

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?

What is an apple? It is a fruit that grows on trees. It is round-ish, edible and has either a green, yellow or red color or a mixture of these. And here is one. Have a bite.

Some things are easer to understand and to explain to others. Other things - and especially concepts - are more difficult. Generally, the more abstract a concept, the more difficulty people have with understanding it.

So, yes, heuristic and oracle are abstract concepts and therefore more people struggle with understanding what they are than with understanding what an apple is.

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?

Ahem, let’s try a definition without referring to the existing ones of e.g. Michael Bolton:

Heuristic: A problem solving strategy that produces an answer without guarantee of neither its absolute correctness nor its best suitability nor its applicability for the task one is confronted with.

Oracle: Any valid reference used by a software tester in order to evaluate the observed with the desired.

And now comes the disclaimer: By just giving these one-sentence definitions I would not have any guarantee that I was understood. In order to know that, I would have to be in a dialogue for a longer period and observe if I was really understood. So, no easy and quick path here.

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 do not think so. There is the fantastic power of analogies. You can take any A and B and make a connection through an analogy. In my experience it is very fruitful to sometimes force analogies. When trying to connect two domains that appear to not be connected at all, the outcome can be rather surprising. Deliberately forcing analogies more often than not results in surprising insights and new ideas.

tags: context-driven, truth, 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

It is one of those rare events; at least for me who is not a job hopper. There are a couple more minutes left to officially being employed with my old employer Phonak AG, with whom I have proudly spent the last almost eight years. And then I will equally proudly become an eBay man. Yet, the transition feels odd.

PHONAK
In December 2004 I was studying at the university in Zurich and the only reason I started to work with Phonak, was, that I was in urgent need of money. How could I have known that it was the start of a career in software testing. And how could I have known that I would get seriously hooked with the context-driven school. James Bach, of course, was not at all innocent in all this.

Phonak has been an excellent employer for me and I would especially like to thank my former boss - Philipp - for everything he has inspired in me. Actually, why don’t you just have a look at his recently started blog to see what a marvelous free thinker a software development unit director can be. Philipp is a remarkable person, who, with his razor-sharp analytic abilities, yet relaxed compassion with people, was a pleasure to work for. May milk and honey always flow in his general direction.

And now the time has come for a change.

EBAY
I have been a line manager for a total of 13 people. It has been rewarding and on the other hand it does not leave a lot of time to do actual testing. As I have written in a post a while ago, it has been something I wanted to change. eBay has miraculously offered me this opportunity. I can have the best of both worlds, still doing line manager work by enabling people to achieve their best and also doing hands-on testing. How great is that!

It will be fun to read this post in a few months when I know more about eBay. So, what do I aim for within eBay?

My goal is nothing less than making my group of testers world class. And by world class I mean a team of fantastic individual personalities that is the envy of every other company. One that has sparkle in their eyes when they talk about software testing. One that inspires. One that understands world class as not being the end of a journey but constantly being on the road in search for excellence. One that every other manager would hire on the spot, only that none in the team would be interested for any price in the world, because they cannot have a better place to work for than eBay. One that has a smile on their faces.

This is bold, yes, and I would like to end this post with some beautiful sentences by a great man:

“Impossible is just a big word thrown around by small men who find it easier to live in the world they've been given than to explore the power they have to change it. Impossible is not a fact. It's an opinion. Impossible is not a declaration. It's a dare. Impossible is potential. Impossible is temporary. Impossible is nothing.” - Muhammad Ali

With this in mind - dear eBay - let’s see what I can do for you. I am looking forward to getting to know you all. See you on Monday.

tags: job, testing, new ideas

(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

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

CURRENTLY ON HOLD - NO COACHING SESSIONS AT THE MOMENT


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