Markus Gärtner's Blog, page 20

“How do you do all that stuff?”

I am often approached with the question whether I cloned myself. At least, when taking a look on the amazon pages for my book, this might be the case; yet I more seriously added my amazon accounts as authors for both the German and the American amazon pages.

A few months ago I had an interesting coaching session on whether or not I am burned out (there are questionnaires for this, I would claim these results do not hold for me), I put on too much work, etc. During that session I found myself confronted with the Diathesis-stress model which explains a lot of my thoughts around this topic.

While I write this, I am in Hamburg, Germany. So, imagine a ship. A ship has a keel, an anchor, a loading depth, and how deep the water currently goes. These four factors influence how fast a ship may sail. Let’s take a look on these four factors, and how they relate to the model as an analogy.

Keel

The keel defines how much load you may put on a ship. IF the keel is deeper, then you might put up more load, but you will also need deeper water to sail into. Regarding your own stress level, the keel relates to how much you can put onto your shoulders.

For me this means, that I have worked since I was aged 14 years old. I helped in a local swimming club. I also helped during the seasonal preparations of our local swimming club. Some years later, I was a student at the university, jobbed at a local shop, did the seasonal preparation for the federation club of our local outdoor swimming pool, worked as a swimming trainer two to three times per week, acted as a secretary voluntarily in three local clubs – all at the same time. I did a lot of stuff in the past. Therefore I claim I am able to put some stuff upon me with ease – probably more than others might feel comfortable with.

Loading depth

The loading depth is derived from how much load is currently already put up on a ship. When the ship is empty, it can take on more load. If it is already completely under water, you have to get some load off from the ship. This directly relates to how much work you put on yourself.

As I mentioned before, I think I can take on some load. There are times though where I sense that I am too heavily loaded with stuff that is fun to me, but might turn out to be overburdened. For example, I actively decided to take some shortages on my blog in the past few months while I spent more time finishing my book, and doing BBST classes. In parallel to my usual work this seemed to be lots of work, and I made the conscious decision to step back from blogging too much because my loading depth felt to be too high with it. Otherwise my ship would have been damaged.

Water depth

The water depth determines whether I can put more load on or not besides my actual current load. This means that I might be able to put more load on while sailing through deeper water, and I can take fewer load on myself while sailing through lighter water.

For example, if I find myself in the position to move to a new house, I will be able to put less work on myself on my day job. On the other hand, I can take more care about my family, when I don’t go through a 60 hour workweek. Ideally, I want to have my workweek balanced with my family life, but life is tough – and crosses my plans at times.

Anchor

Finally, there are anchors. These anchors draw myself down. These are stressors which slow myself down. For example, when I find myself in the position to move from one week to the next to a new location, this triggers more stressors inside myself and probably slows me down.

Putting it all together

Putting it all together, my work load, my cruising depth and the current water depth determine how much work I can put on my shoulders. This might mean that I can organize meetings, work on a book, write two articles, and maintain three blogs in parallel. At times though, stressors will slow me down, and I will have a hard time keeping up my current pace. The problem with stressors is usually that these are determined from the outside, and can put you into rough water pretty easily.

Some people I have talked to feel more comfortable with a lot of room for external stressors, others feel more comfortable when they have full control about their situation. I think I learn a lot by consciously increasing some factors at times, trying to put on more work, and watching out for too many stressors on the horizon. At that time say politely no to new things that turn up, although they seem to be a breakthrough chance at times.

Tracking testing on the Scrum taskboard

Today, a colleague of mine, Norbert Hölsken, started off a discussion in our internal communication channel. He asked:

How do you treat bugs on the taskboard that are found during testing? Create a new test for each bug, and put the test task back in ToDo? Or create a bug, and a bug-follow-up testing task?

As it turns out there are a lot of valid reasons to do it one way or another. Yet, the answer “it depends” does not help – neither a Scrum Coach, nor a tester working in a Scrum environment. So, I started raising some of my experiences and concerns, and some of my other colleagues replied as well.

Skip forward three hours, and I am writing a blog entry on my thoughts about it.

Test tasks

From my experience test tasks are completely different to development tasks in Scrum. There is one itchy issue with creating test tasks: It does not feel right. Usually you have one, maybe two testers (or test-infected developers) on your team in the most Scrum teams I found. They will do “all the testing” for your definition of “all the testing”. Once you create “test” tasks, you will find yourself with dedicated tasks that all of the other team members assume a tester will pull from the taskboard.

Why is this a bad idea? First of all, this task has an implicit dependency. Not only on the tester(s) being not hit by a truck, but that all the coding tasks are fulfilled. Of course, in such a setting, the question from my colleague is very valid. If the testing task finds problems, probably all the work has to go back, starting-over. Enter the mini-Waterfall where we do analysis, design, coding, and testing within a Sprint, but nothing else in our culture and paradigms changed.

From my point of view it shows a certain drawback. We have implicit dependencies, and on a dysfunctional enough team this setting will create a silo thinking mentality, probably setting up the whole coding team to fight against the one or two testers that are creating more work just before the sprint review. Ouch. I think this creates enough tension on a team that starts using Scrum that I would not recommend it to start with. However, if the team over time while getting more experience finds out, this is the right thing to do, I will be suspicious initially, but might get convinced over time.

On the other hand, Ilja Preuss called out that testing tasks might work very well for automated acceptance tests. I haven’t seen teams doing this, and I think it would lead to sub-optimization, but I also think it can work. I prefer to put “acceptance criteria are automated” on the team’s definition of done, and have this condition implicitly on the taskboard spread out over all the other tasks that I will have to do as a team.

Dedicated Testing column

First of all, Scrum says nothing about the organization of the team within a sprint regarding their sprint backlog. However, most teams prefer to use a taskboard as an information radiator, so that everyone on the team knows exactly what is happening, where they are at, and how they are doing regarding their sprint goal. There are several different ways to organize your taskboard. The most common understanding is that you need three columns: ToDo, Doing, and Done. I don’t agree with this.

When my colleague raised the above question, I thought immediately, “how come they don’t have a separate Testing column?” I was thinking about a team I consulted with for the past 9 months (or so). They have the following columns:

Story
ToDo
Coding
Review
Test

Done

They move the story card on the taskboard to done once the product owner reviewed the story in the running system during the sprint. Then they have multiple tasks which spread the taskboard. The review column is allowed to be skipped only if people did work in pairs on that particular task. This encourages pair programming, and I found it a very elegant way to support pair programming. The remaining columns should come natural.

In the testing column the only tester on the team collects tasks which have been implemented up until a certain when he feels comfortable to test these tasks together as a collection. I like to call this the MTSI, minimal testable story increment. At times the tester tests parts of a story once he sees that a breakthrough is available that he can test in a manual kind of way. At other times, he might wait up as late until all the other tasks have been completed. Of course, this approach has implications regarding how the team defines tasks, and this particular team I have worked with does a lot of things in a way that helps the programmers, the tester, the product owner, basically all people involved. (They are hiring. If interested drop me a line. :) )

Ilja pointed out that a separate testing column probably means to have manual tests involved there. I don’t quite agree. I would also use testing tasks based upon my Exploratory Testing charters if the context asks me to do this. I would also set up a low-tech testing dashboard as a second information radiator, but I would keep this idea for some time to myself in order not to overburden the change effort. I think there are many valid reasons why I would indeed start with “put all the manuel testing tasks in the testing column”.

A meshup

As Cicero wrote in De re publica, I see advantages in the first approach, and I see advantages in the second approach. But if you ask me to take a position, I would prefer a mixture of both worlds.

If you start with a lot of testers coming from a manual only background, you might want to start with a separate column. However, over time I would work hard with the team to be able to get rid of this particular column, and bring more and more testing related tasks on the taskboard. At least I would make a possible bottleneck observable by using the testing column as a sort of gateway column. If too much work gets piled up there, we certainly have something to talk about during the retrospective.

On the other hand, when your testers come from a automation heavy background, then they might find it more comfortable to work with separate tasks. If I find testers working on their own silo tasks, I would work hard with the team to be able to exchange more knowledge here – and how to reduce the amount of bugs that get into the system in first place.

It might also be the case, that a lot of testing related tasks have to be carried out by programmers. Then I would start with tracking these as separate tasks first, sooner or later make them part of the definition of done, so that everyone takes responsibility for their own work.

Ideally, I would like to balance all three of these approaches against each other. This is not possible under all circumstances, however, but I think we can work on this as adults. If not, we might have a different problem to solve.

Two problems with context-driven testing

Over the course of the Let’s Test conference in Runö, Sweden, I noticed a problem with context-driven testing. In the past one or two months this turned into two problems I see with context-driven testing. I finally decided to put them out there for further discussion. I hope a lot of you don’t agree with me – and I hope a lot of you folks speak up.

Systemic effects

The most pressing issue I have starts with the systemic effect. I will phrase this as arrogantly as I can. The term “context-driven testing” – for me – includes the notion that we are driven by the context, and the context of our situation is the only way we can think of as we should be handling now. We are testing alongside our context, right? What could be wrong about that?

This interpretation of “context-driven testing” ignores pretty much a central point about context:

The context includes the tester.

Our behavior leads to changes in the system that we call “context”. This is a variation of the Chinese proverb: “When you point your finger to another person, look where the other three fingers are pointing to.” By acting based on “the context”, we influence “the context”, we change “the context”, thereby we will drive “the context” to another status, to another “context” that will change our behavior. To put it clearly: Stating “I as a tester am only driven by the context of the people around me” is foolish, short-sighted, and ignores the systemic effect that our own actions have to the situation, the context of our project.

If we do a poor job of testing, this will influence the stakeholders and project managers around us to lead to different actions upon us. If we do a decent job testing for the stakeholders’ expected results, this context might drive us into different follow-up actions. But rejecting the premise that we as testers influence that context, and are only driven by it, is rejecting the systemic effect that we bring to the party. We neglect the effects that we make upon the project, thereby we will miss a large part of “the context” that we claim that drives us. Ouch!

But there is more to it.

Victim behavior

Victim behavior? What’s that? Unfortunately we have to dive into transactional analysis for this. According to the theory behind the Karpman drama triangle we play a game here. A game with roles as the persecutor, the victim and the rescuer. Huh? What’s that?

People play games at work and while interacting with each other. The Karpman drama triangle puts three roles into context, and I see them a lot. The persecutor is the one evil figure. It’s the devil in the Holy Book, it’s Al Kaida in Western News Reporting, it’s the programmer and the project manager in modern programming (I made this third one up).

As a tester, now, we are victims of this situation. We are helpless there just as the US is helpless against Al Kaida, the German soccer team is helpless against the Spains or Balotelli, and the only hope against the devil is the belief in God. We testers are the victims of the situation, the victims of the context, that became our persecutor. I hope by now you notice how this is an extension to the first point that I made with the ignorance about the systemic effect.

Now, in the triangle, there is someone who rescues us victim testers that are persecuted by the evil context.By playing the role of the victim, we are seeking for the rescuer, whoever that might be. I won’t hypothesize on this; you’re a thinking tester; I think you can make up your mind about who your rescuer could be on your own.

Now, here is my call: Stop being a tester that claims to be “driven by context” as a false victim behavior. You are influencing the same “context” by your behavior, and you might find yourself seeking a rescuer that will not hear you.

I agree with most of the context-driven literature, most of the context-driven teachings, heck, I even claim to teach context-driven testing to others. And I think the name is at least misleading in these two particular points that I described. We are not victims as testers, and we are active actors within the context that we claim that influences us. Deal with it. Now.

ATDD by Example

It seems that my book ATDD by Example: A Practical Guide to Acceptance Test-Driven Development is now available at least for Kindle. I received my first physical copy last week. So far amazon lists the physical copies due for end of this week.

It’s been quite a journey since I approached Kent Beck with the idea for the first time two years ago. As I was unsure whether I could actually write a book in a non-native language, I decided to give it a try during the Pragmatic Programmer’s Writing Month in November 2010, and completed the first part from three within the first month. Skip forward a few months, and there it finally is.

Now, with every book you as the author face two main struggles:

when to stop believing that you can incorporate new stuff that you learned in the meantime so that the content will not be out-of-date
when to stop polishing up what you have so that any mistakes that are still there get exposed to the public – and finally show your readers how bad an author and writer you are

For the first of the two points, I was glad to incorporate some of the stuff that I learned while finishing up the major draft version around New Year’s and now in a series of articles for inform IT. The first one of these will get you started with ATDD. It’s called Getting Started with ATDD: Overcoming the Biggest Mistakes Right from the Start.

For the second point, I have a deadline nearby middle of July to return any corrections for the second printing by then. So, if you happen to find any “bugs” in the final manuscript – and I know there are lots of it, although I decided to read through it several times – I would be more than glad if you dropped me line about it, so that I can get it corrected in the next printing.

I figured that I spread around some easter eggs from time to time in the projects that I am involved in. If you happen to find one, please keep it to yourself in order not to spoil others who are looking for it. I think I should set up a challenge around this some time in the future. Maybe I will spread a free copy of my next book then.

On the title, why did I call it ATDD by Example rather than Specification by Example by Example: Well, I think the name “Specification by Example by Example” would be stupid. A recent client gig where I consulted on “Specification by Example” I also found myself in the situation where a business expert asked me: “Does Specification by Example mean ‘all specifications’?” Since then I am convinced that we didn’t solve the naming problem – and I wonder if we will have to. For more on the name, make sure to read the preface. I explain why I picked that particular name – and a whole lot more on the background.

One final word: If you enjoy the book, tell others, so they read it. If you are disappointed or have any criticism, please tell me so that I can improve myself. Thanks. Enjoy.

Testautomation Coderetreat postponed

If you have followed this blog long enough, then you might have crossed the Testautomation Coderetreat in Munich which we planned for June 2nd. I apologize for having to cancel the first meeting on such a short notice, but we found it unprofessional to stick to the date. Here is the reason we had to postpone this date:

While this might mean, that I will have to do lots of other duties in the next few weeks – well, at least my priorities will change a bit – we also planned in a replacement for the for the first testautomation coderetreat. The new date is now the 11th of August, again in Munich, Germany. Here is the link to the event on eventbrite, please sign up there: Testautomation Coderetreat Munich.

Ukrainian Testing Dojo 2 Report

This is a guest blog entry from Andrii Dzynia. He contacted me a while ago on Testing Dojos, and wanted to run a session in Kyiv, Ukraine on his own. At their first public Testing Dojo they seemed to have had a great time. You can find his original blog entry in Russian on his blog.

The second Ukrainian Testing Dojo meet up was organized!

The goal of the dojo was to understand the concept of Exploratory Testing and to practice with it.

We started on time!

I’ve create a small presentation about Exploratory Testing with the first words about the definition.

Simultaneously…

learning about the software
designing the tests
executing the tests
using feedback from the last test to inform next

James Bach corrected me with the new version of the definition, and I will use another one for the next time!

James Bach:

Exploratory testing is an approach to testing that emphasizes the personal freedom and responsibility of each tester to optimize the value of his work. This is done by treating learning, test design, test execution, and test result evaluation as mutually supportive activities that run in parallel throughout the project.

There was just one slide left for the testing session and all of attendees proceed with the testing!

That was really cool to look how testers collaborate in pairs or sometimes trios.

On the flipchart we showed how many points testers get for bugs.

After the first session we switched to a debriefing. A lot of questions and mistakes were discussed. It’s very important to do debriefings after each session. It helps people to find answers and share the experience!

We did one more 30 minute session and one more debrief. We had a break for tea and coffee.

For the last session we were left with just 15 minutes and the main focus was to create the bug report.

There were 15 teams and to count the points for each team we decided to use one minute session for each team to show their results to the others.

After the second team we agreed that it’s very complicated and we already had no time for remaining teams. A lot of questions came up regarding quality of the report and the bugs found.

We decided to try it a different way. All the participants sit in a circle and were discussing about the bugs found and tried to figure out collaboratively what the best bug was!

It was the golden moment of the dojo! The testers were looking like one big family! That was really cool!

After that the organizers of the Ukrainian Testing Days conference awarded T-shirts for the best bugs that were found during dojo!

This dojo was very cool and we are going to do this on a regular basis. In fact it’s very hard to understand the concept of Exploratory Testing in 2 hours. So we will continue this testing dojo session in the near future.

Stay tuned!

Regards,

Andrii Dzynia

http://www.adzynia.com/

Announcing GATE 02

The second GATE workshop will take place on September 8th 2012 in Munich, Germany. GATE is a workshop that falls into the series of peer workshops on testing like LAWST, LEWT, DEWT, and SWET.

As the content owner of this workshop, I worked with my peers to identify the following main theme:

The future of Agile and Exploratory Testing

We expect participants to submit content in line with this theme. We are interested in contributions such as

innovative approaches to testing
combining session- and thread-based test management
collaborative test chartering
testing in practice (Testing Dojos, Testautomation Coderetreat, Hands-on testing)

Feel free to contact us if you are unsure. We will be most glad to provide you feedback.

You will find more detailed information on the GATE homepage over the course of the next months.

I look forward to meeting lots of testers in Munich in September.

Let’s Test: If it’s not context-driven, you can’t do it here

At the Let’s Test conference, the first ever context-driven testing conference in Europe, Michael Bolton delivered the first keynote on Monday morning. He was talking about context-driven testing – what else?

Michael emphasized that the title of the talk is irony. He was surprised to find out that people took it serious when he held the talk for the first time.

Michael mentioned the “How to think about science” series. He mentioned the starting point of scientific experiments when people started to investigate influences of air on the human body system. This was the first time an intersection between engineering and art came into place with the air pump. Everyone had one.

Robert Boyle introduced the term of fact-based experimentation. He tried to solve a human issue by inviting people to his experiments so they could witness the results.

On the other hand Thomas Hobbes argued against Boyle’s method. He approached the scientific problem from a philosophy point of view. One of Hobbes principle objections was that Boyle started his experiments based on the models that led him to come up with the experiment. The second objection Hobbes had about Boyle’s experiments is that he didn’t solve the social problem underlying the arguments of the time. Mere evidence doesn’t convince people – Knowledge has a social dimension.

Michael concluded referring to work from Kuhn and others that the whole body of scientific method was questioned in the 1980s. They found out that scientists were merely good at convincing others of their approach and their results, but didn’t lead to generalizable insights, but merely observed facts. At the same point, it seems that similar debates started to rise in the testing community as well.

Michael read a part from “The gift of time”, a gift for the life and work of Jerry Weinberg. He referenced a section from James Bach’s chapter, where Jerry trapped him into insights about testing and testers. Testers know that some things can be different.

Michael referred to the seven principles of the context-driven school. He pointed out that every principle carries uncertainty in it. In a complex world, we have to be able to deal with uncertainty.

Michael raised the point that we are in the middle of a big change. This change started in the 1820s/1830s with the uprising of electricity. Michael continued to challenge that in traditional testing, the only kind of certainty comes from test cases and test plans. Is that all we have to provide for certainty? Is that all you need? I agree with Michael here – from a distance it sounds rubbish.

A key part of our service is to reduce unwarranted and potentially damaging certainty about the product. Science has been going through significant changes over the last few decades. Testing cannot make any absolute promises about what it delivers. Instead we deliver partial answers that might be useful. Testers are anthropologists in the field of software development projects. We observe what happens, and provide our observations. But we don’t make the decisions about dealing with the uncertainty.

Michael concluded the keynote by pointing to the third principle of the context-driven school:

People, working together, are the most important part of any project’s context.

He explained that this means that we have to develop ourselves so that we as testers can be a valuable part of the projects that we are working on.

Coderetreat goes testautomation

I remember a talk from Cory Foy back at XP 2010 in Trondheim, Norway. He referred to Corey Haines as the happiest guy in the world. Although he lost his job, he started to travel around in the world, from shop to shop, from company to company. He was able to learn so much in a single year that he continued his journeyman tour after that.

One thing that Corey Haines invented alongside is a Coderetreat. Up until the global day of Coderetreat last year on 3rd of December I didn’t know what a Coderetreat actually is. At the core are six sessions of 45 minutes each where you solve a problem in code. Then you delete your code, and do it again – maybe with a different pair partner.

Recently J.B. Rainsberger invented the idea of a Legacy Coderetreat. The idea there is similar to a Coderetreat, but have to deal with legacy code and improve it. I attended one Legacy Coderetreat in the mean time, and it was quite interesting to solve the problem of a big mess of code.

At some point back last year I got in touch with Corey Haines and Adam Goucher. We bounced some ideas back an forth, and I refined them later with Adrian Bolboaca to yield a Coderetreat for testautomation code. Now I am happy to announce the first Testautomation Coderetreat in Munich on June 2nd.

What is a Testautomation Coderetreat?

We will work on automating tests for a website that is already there. We will use different approaches, and over the course of the day learn about different ways to implement our test code.

Over the course of the day I will challenge test automators to try different tools, different approaches, and also test-driven their test code. The programming language, the test framework, and maybe even the test driver will be decided upon by the different pairs in each session.

Why should you attend?

You will get to know how web applications can be tested with an automation framework
You will strengthen your techniques around test automation code
You will exchange your thoughts with other test automation developers.

I already have some inquiries for another session somewhere in Germany. Due to personal reasons, I won’t be able to run such a session before July, unfortunately. I also hope for some participants from other countries, so that we can spread our learning and bounce back some more ideas.

Looking forward to a great learning opportunity – also for me.

Let’s Test prequel with Ilari Henrik Aegerter

As a prequel to the Let’s Test conference in May, I interviewed some of the European context-driven testers. Today we have Ilari Henrik Aegerter, the first participant in this series. He’s a tester and coach that was highly recommended by James Bach in the past few months.

Markus Gärtner: Hi Ilari, could you please introduce yourself? Who are you? What do you

do for work?

Ilari-Henrik Aegerter: Hi Markus, my name is Ilari Henrik Aegerter and I am a tester. And there is certainly more to the question “Who are you?”. Some of the things I would list: I am a books and comics lover, interested in cognition and anything around the topic of observation. Furthermore, I am on very friendly terms with puzzles in general and I enjoy hard thinking. I am also happily married and the father of two wonderful boys.

I work with Phonak AG which is the world’s leading manufacturer of hearing aids. My role there is line manager of a testing team of 13 people. The applications we test are classified as medical software. That’s why there is probably more test documentation needed compared to a regular testing organization. But we try to keep it as lean as possible.

Testing software was not my career plan. I stumbled into it by chance in 2004 while I was studying general linguistics at the university and I just needed the money. And then I started to really like it. That’s why I am still doing it. It is the intellectual challenge that I really enjoy.

Markus Gärtner: “I stumbled into testing.” I heard this a lot during the past year. What conclusions do you take from my hypothesis that a lot of testers somehow fell into testing? What does this mean for our profession?

Ilari-Henrik Aegerter: Well, I would even suggest that most people somehow stumbled into their profession regardless of what it is. I think we overestimate the percentage of people who always wanted to become e.g. a pilot and then rigorously followed their life plan. Isn’t it an exciting thing that chance may be the guiding force in our life?

One other reason for testers to stumble into their profession: There is neither an apprenticeship model nor can you study software testing at universities. It is quite natural that the remaining path then is to “stumble into” it. The “stumblers” may or may not have developer background and the ones that got hooked with testing are probably motivated above average and want to advance in their profession.

And then of course there is the sad story of the non-performing programmer whose misguided manager thought: Let’s put him/her into testing.

To sum it up, I do think that “stumbling into” is generally a good thing for software testing. It means that you start to work as a tester and if you are really interested in it then you educate yourself. In other professions it is the other way round. You study for years to eventually become a medical doctor or a math teacher or an experimental physicist. If after all these years of study you do not like your job, what do you do then?

Markus Gärtner: How have you crossed the path of context-driven testing?

Ilari-Henrik Aegerter: It was back in 2007 when I attended James Bach’s tutorial “Exploratory Testing Explained” at StarEast in Florida. James has certainly had the most intensive influence on my testing. Now, for the past years I have been a line manager and I have done less and less testing myself. This really bothered me and at the StarWest conference last year I gave myself a push and started to re-educate myself. I did not want to become the zombie line manager who hasn’t got a clue. And I find the context-driven school to be the natural choice for people who want to be really good at testing.

Markus Gärtner: What specifically did you do to re-educate yourself? If I run into you today, which sources of information do you provide me?

Ilari-Henrik Aegerter: There are several specific actions:

About half a year ago I started to have regular Skype coaching sessions with James Bach and they are the most intensive learning experiences for me. Recently I started to do Skype coaching myself with testers who are interested. So far I have done about a dozen sessions with other testers. The good thing there is that I learn as much as the testing student.

I registered with uTest to test a wide variety of products albeit mostly web based. Then I started to discuss testing topics with a broader range of people in order to defend my own thinking and learn from others. There are many excellent blogs that I regularly read and I try to periodically write posts on my own blog, too.

In my company I have decided to start pairing up with some of my testers during exploratory testing. I have not done that yet but I have it on my schedule. Also my reading is more guided by topics that can be of use for software testing.

All May will be flavoured with the BBST course. I have registered for Let’s Test and I am also attending the Test Coach Camp, which precedes CAST. I expect all these events to be intensive learning experiences, too.

I asked you and Matt Heusser for a Miagi-Do Testing Challenge which Matt agreed to do with me in July. Then I just discovered codecademy.com and James occasionally challenges me with mathematical and lateral thinking puzzles.

Ok, that’s about it for the moment.

Markus Gärtner: “The context-driven school is the natural choice for people who want to be really good at testing.” How come this is natural?

Ilari-Henrik Aegerter: The principle number 6 of the context-driven school states: “Good software testing is a challenging intellectual process”. In order to meet this challenge you need to study your craft. I have no knowledge of other schools or circles that put that much emphasis on intensive practice and learning. That is why I see the context-driven school as the natural choice.

Markus Gärtner: How do you apply context-driven testing at your workplace?

Ilari-Henrik Aegerter: First of all I try to focus my team on testing itself and away from spending too much time on the creation of secondary work products like test plans and reports. As a medical device company our context demands some level of documentation, e.g. all requirements need to be linked to at least one test case. However, we heavily use exploratory testing and do experimentation with “real life” scenarios. As the line manager I give the people in my team a lot of freedom to experiment with different approaches to testing. Also, since our testing is a service we offer to the best of our abilities to our customer we have a peaceful relationship with the developers and product management who both value our efforts.

Markus Gärtner: I assume that creating fewer secondary work products, as you named them, in a medical environment sounds dangerous to some folks. How to you defend your position? Do you have any troubles defending your position against agencies?

Ilari-Henrik Aegerter: It is not fewer but leaner. We have automated as much as possible of the report and document creation. Not doing these documentations would violate IEC 62304, which is the medical norm for software development.

We do fulfill what is requested and I wouldn’t be nervous at all if an audit was announced. On the other hand, if we ONLY did what was written in the norm, we would have a lot of bugs in the product.

It is during exploratory testing sessions and other more creative forms of testing that we find the interesting bugs.

Markus Gärtner: Taking a closer look on the Let’s Test program, which talks do you look forward to attend at Let’s Test?

Ilari-Henrik Aegerter: Let’s Test has such an excellent line-up that it is really difficult to name one or two. Maybe “Testing Hypnotically” or “The Testing Dead”. The first because it explores an unusual analogy between two areas normally not mentioned together: testing and hypnosis. The second one, because it addresses a sad problem in our craft in a humorous fashion. But there is not even one session, which I do not find intriguing. It is going to be tough to choose among the concurrent tracks.

Of course I am especially looking forward to the conversations outside the sessions. It is great to meet all my Twitter, Skype and e-mail conversation friends in person and discuss testing.

Markus Gärtner: Imagine Let’s Test is over. What did happen there, that made it an awesome conference for you?

Ilari-Henrik Aegerter: If after the conference I come back to Switzerland and feel even prouder to be a tester,

if all the discussions with people have made the network of testers stronger,

if my tester’s gas tank is filled with energy and inspiration from the sessions and the discussions,

if I genuinely feel sad that the conference is over,

then I think the conference will have been awesome.

Now, the expectations towards Let’s Test are already very high among the participants. That is of course dangerous. But I think the conference cannot fail, because all the context-driven people will flock to Stockholm and just them being presences will generate a positive dynamic.

Markus Gärtner: European Testing in twenty years from now – how does it look like? What do you think?

Ilari-Henrik Aegerter: I haven’t got the slightest clue! Twenty years in a technology focused area is such a long time. In this dynamic and complex system where just a tiny invention can have effects beyond imagination, all prediction is just guessing. I have no idea how software testing is going to look like in 20 years. But I know a lot of us will be around and adapt to whatever situation there is.

I think this adaptation can be quite a challenge for some people who call themselves testers. No certificate can prepare you for the next 20 years.

There are certainly things I hope for the next 20 years. In a short sentence: Less ISTQB, quality police mentality and useless certifications, more context-driven.

Markus Gärtner: Thanks for your time. Looking forward to meet you at Let’s Test in May!