Let's Test prequel with Martin Jansson

As a prequel to the Let's Test conference in May, I interviewed some of the European context-driven testers. Today we have Martin Jansson, one of the test eye bloggers.

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

you do for work?

Martin Jansson: I am Martin Jansson. I live in Gothenburg with my family and has been there for the last 20 years. I have a house from 1919 that I train my house-fixing skills on. Having two kids I get little time focused on myself, still I spend some of that spare time to read, write and talk about testing. My personal goal is to boost the test community in western Sweden. I am co-founder of The Test Eye together with Rikard Edgren and Henrik Emilsson, who I've worked with on and off since 1998. Our initial idea was to keep in touch through a blog, but I guess it grew into something greater than our first intention.

I work for House of Test Consulting as consultant doing most anything related to testing that I am passionate about. I recently switched company and am now enjoying the freedom in deciding where I want to excelling in the test domain, but also affecting where we as a company want to head. I also enjoy working with so many passionate testers. The last years I have consulted at a client where I've have helped them evolve the test organization from traditional testing into a fast-paced testing style. This has been work in the actual test teams as well as at a managerial level. Working all levels at the same time is a lot of fun and brings good result.

Markus Gärtner: So, you transformed a whole testing organization on multiple levels. How did you do that? Anything the community can learn from your approach, maybe?

Martin Jansson: I have not transformed anything. I see product development as a social science. It is all about people. The people at my client on all levels are transforming the organization. My role is perhaps to act as a catalyst. Even though I believe that one person can affect a whole organization, but it is people in the organization that do the changes.

When I first started as a consultant at the client I worked as a line manager for testers and developers and had my whole line with me to the client. This made it possible to try new ways of working and show that things could be done differently. It also helped when the client wanted me to be test team lead. Another factor was also that the members of my team were excellent testers, it was easy to show greatness to our client. It helped a lot to have a test project manager that wanted to try new things and was interested in other approaches. During this time the whole organization was starting to change and move in a new direction so it was easier to maneuver and try out new things.

In times of major organizational change there are lots of opportunities. When many things are changing there is a lot of chaos so you need to hold on to a few threads of control. Here are a few things that I considered as a tester:

Know your stakeholders, prioritize the right things and deliver what is valuable to them
Do excellent testing; administration comes secondary (unless that is in fact the most important)

Another key success factor that I suggest more consultants do is to work actively with other consultants even if they are from other companies. By cooperating closely you will better help your client and you might be able to discuss common goals on what you are trying to achieve. I've seen many consultants that work in a way that makes them irreplaceable and a key person in the organization. By doing that you are in a way pushing down the employees so that you to some extent can guarantee an extended contract, which I think is wrong. I try to make myself replaceable and instead empower employees around me so that when I am not there it won't be noticed. At the moment I am working and coordinating with Henrik Emilsson, who is training in agile testing to one part of the test organization, and Steve Öberg, who is coaching and training agile testing in a different part of the test organization. Henrik works at a different company than I do, but Steve and I work at House of Test together in Gothenburg. The three of us can together do things that benefit our client more than if we worked on our own.

During the last year I've worked as discipline driver in the test management team. This means that I am helping the organization in all kinds of test related situations. The tasks are ever changing, bringing on new contexts and new problems to solve. An example could be that in one team, testers were re-running the same test case several times just to show progress by counting test cases. The project management asked for progress and based their figures on amount of test cases run. I could then discuss with the project management that they get what they ask for and that it would be more valuable to ask other types of questions if they were interested in progress and in perceived quality of the system. By changing the way project management asked questions, the testers changed their behavior in how they tested and how they reported progress.

In big organizations there are so many things going on and making changes take time. Nothing is really done by just doing this and that. So when you want to see change, you really need to be patient and appreciate the small things. After a while the small things have summed up into a turning of the tide.

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

Martin Jansson: Honestly, I cannot remember how it happened. I'd rather say that I crossed paths with different people who had similar ideas like my own. When I worked at Spotfire in the early 2000, we were continuously investigating new test techniques and methods. I remember finding articles such as The Ongoing Revolution of Software Testing by Cem Kaner, which changed me and my team. Then we found a lot of material from James Bach and other great thinkers. We were not really doing scripted testing, rather following one-liner test ideas and using exploratory testing around the area. I've described this as a form of Check-Driven Testing. When we started to read about Exploratory Testing, it was interesting to get a name to what we partly had been doing even if we were not so structured.

When I joined the mailing list for context-driven testing I found even more material and great minds. I have not been involved in the discussion there, but we all do things that fit us best in how to contribute to a better test community, a mailing list is not optimal for me. Instead I blog and talk to people.

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

Martin Jansson: As discipline driver for testing at this client I affect how testing is done and try to affect where we should go with testing. I like the context-driven testing approach, it also fits well with what we are trying to achieve. In some cases, to express where we come from and where we are heading I use the schools of testing. I try to introduce my approach to testing that fit in their context, but it will always be affected with what I think and with what my experiences have taught me. For instance, I see the need for handling both testing and checking in an excellent and structured way.

Markus Gärtner: Let me put some context to context-driven testing. Consider a context where your test team consists of educated nurses. The team is applying Scrum with co-located testers on a C#-project for a Windows platform. They work on a product for doctor's offices. Which kinds of testing would you suggest? What are the factors favoring one approach over another?

Martin Jansson: I will express a few of my thoughts. I interpret the context as having a group of people in my team that