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 has the domain knowledge and have a good idea on what problem we are trying to solve with the product. I have little experience of the domain, but could bring my knowledge as a generalist tester. I would start by asking what our mission[s] was in this context. I would investigate the immediate need in the team on us and what is most prioritized. I would together with my testers plunge in and do some exploring/testing/learning what we have right now. I would try to outline and create a model (one to start with) of the product to easier discuss what we test. As soon as I am able to work more long term, I would have an introduction to testing, some training and exercises to enter the right mindset for the test team. I would investigate what other expectations we have on the team such as information/documentation, that could affect how we work.

It is hard to say what kinds of testing I would suggest. I am not sure what different kinds of testing is in this context. If you ask if I would focus on requirements, I would say no because that is only one of many coverage models. We would setup lists of things we need to check, some might be automatable and some might be used in checklists. We would probably try out some form of session-based testing if that works with the test team. I like to work that way and would see if it is possible and if it provides value to the team.

I have an exploratory approach to testing. I cannot change that approach or my perception on what testing is and what we could do. Still, if the client wants something that I do not believe in or that I cannot deliver I will discuss the implications and the possible value loss for the client. Another thing, I would see the nurses in my team as intelligent persons and I would do all I can to coach and share my experiences and skills to the team. I know that context changes and that we need to adapt to reality, so I would be open for trying new things as well as using methods/techniques that are proven to work in their context at a certain time in the past.

Markus Gärtner: Where do you see the biggest challenges as of today in the European testing community? How can we solve these problems?
Martin Jansson: I’ve blogged about one of the problems having to do with the perception of testers. How to get out of the rut… well as testers we need to aim for getting better as testers by learning and excelling in what we do and deliver, we need to work on how and what we communicate, we need to investigate in other sciences to become better, to name a few.

There is still a focus on verifying requirements (the written ones) and just that. Anything that is outside of this should not be tested, some say. If the focus of testing is in this little area we miss so much. In the training I do I usually talk about testing outside the map and lately about the Universe of behaviors based on Iain McCowatt’s reflections in Spec Checking and Bug blindness. As a natural consequence you enter the discussion with testing vs. checking. As I see it, we need to do both, but testers should focus on testing and we should try to automate as much of the checking as possible if that is valuable.

I worked with a friend of mine, who has been a developer for several years. During this time we have talked a lot about testing and he has even gone through the RST course with James Bach. His awareness of testing is great and according to him, he has tasted the sweetness of great collaboration between tester and developer as well as seen what great testing could do. Lately he has been working for a new client and has worked with testers from the traditional schools/approaches to testing. He expresses a noticeable change in what testing is delivering to him and the ambition on what they could and should do.

Developers should expect greatness from testers. We could be an excellent partner in making great products.

Markus Gärtner: Programmers should expect greatness from testers, you say. What are the benefits testers can bring to your development team? How can we train and coach testers, programmers, and managers about these values?
Martin Jansson: The exploratory approach promotes a tester that is interested in learning and wants to get better. It also implies that the tester can do all parts of testing, not execution of another person’s test instructions. By promoting this view of a tester and by showing (not just talking) what a great tester can do in a cross-functional team or in general in product development, we will be able to raise the expectations or perhaps alter them to something that requires and promotes great testing. This could also mean that the teams and organizations really do not want the low value added testing any longer.

I try to show how you quickly can get started testing in various projects at my client. I show this by taking a tiny testing area then sit down with a tester I am coaching/training. Based on this tiny (as far as we thought initially) area, I start asking questions and we discuss and mind map different aspects. I use different heuristics and talk about different coverage models. After a short while we naturally end up with a much bigger area than we initially thought. We consider what would be most valuable to the team and where our focus should be. We then start testing, where I let the tester drive while I sit in the back coaching/documenting. I continue to identify new questions but let the tester lead the way. We take breaks and check our initial map, using it as an overall report. In this coaching session, I try to spend 15 min to do the initial map, 1 hour for a test session and 15 min for a debrief/roundup summarizing the result in the mind map.

Someone used to the traditional way of working is usually amazed on how much we accomplished in such a short time. This is like a demo of how testing could be done, perhaps differently to some persons and organizations.

How do you sell this to the organization? I guess you need to be able to show your testing skills and back them up with theory, and vice versa.

Markus Gärtner: Consider Let’s Test is over. What has happened that made it a success?
Martin Jansson: When I talk about the conference’ I am most thrilled about the idea that we are co-located all at the same spot, that after we have conferred with the speakers and attendees, then we have many other events that take place well into the night. So the conference will almost be round-the-clock. My focus will be in the testlab (or perhaps Lets TestLab?) together with James Lyndsay. We aim for setting up a testlab that will tickle your minds and where we can practice our skills together.

When the conference is over I hope I’ve met lots of great testers whom I want to work with in the future at possible clients, that I’ve found new techniques in how to do better testing, that I am full of energy and lots of new ideas for future test work.

Markus Gärtner: Tell us more about the Let’s TestLab. As a conference visitor why would I spend time in the lab and miss all those great talks?
Martin Jansson: Glad that you brought that up! The core idea for Let’s TestLab is that we should not compete with other speakers. Still, there will be other events taking place during the evening, so that the attendees can choose what they are interested in. Let’s TestLab starts in the evening and continues into the night. This means that we will be able to have longer sessions, not just between breaks as it has been previously. This year me and James Lyndsay will have the test lab together.

We will not have as many laptops available as before, so it would be excellent if the conference participants could bring their own laptops and use them in the test lab. We also suggest that speakers backup their claims or theories in the lab after their sessions, and that they coordinate this with either me or James.

We will not have so much focus on sponsors and their tools in the Let’s TestLab. Instead it will be even stronger focus on testing and conferring. Watch the Let’s Test Conference Blog for new information about the test lab.

Markus Gärtner: Consider time travelling being possible now. 30 years from now, what will be different?
Martin Jansson: I assume you mean that it is only me that has the ability to do time travelling. I cannot predict the future. Still, I see that the awareness of testing is growing and that in 30 years it should probably have grown a bit further. But I am still afraid that the two futures of Software Testing painted by Rikard Edgren and Michael Bolton are still possible. The majority of the test profession is going for the dark future that Michael talks about. I just hope there are enough of us to promote a future which promotes the testing craft as something that requires intelligence and skill.

Markus Gärtner: Thanks for your answers. Looking forward to meeting you at the TestLab at Let’s Test.