This interview with Markus Gärtner is part of our series of “Testing Smarter with...” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field's leading thinkers.

Markus Gärtner, author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development, a student of the work of Jerry Weinberg, received the Most Influential Agile Testing Professional Person Award in 2013.

Markus regularly presents at Agile and testing conferences all over the globe, as well as dedicating himself to writing about agile software development, software craftsmanship, and software testing, foremost in an Agile context.

Hexawise: Which person or people have had the greatest influence on your understanding and practice of software testing?

Markus: Foremost among the persons that influenced me are Michael Bolton, James Bach and Dr. Cem Kaner. I remember reading through Lessons Learned in Software Testing back in 2008 when I was trying to make sense of how we could approach our testing efforts, and learned a lot from them.

Of course on the same note, I need to mention Matt Heusser who I was in contact with on a regular basis back then, and who opened up the whole agile world to me. He's been a mentor, a partner in crime and so much more since then. Last, but not least, Lisa Crispin, Janet Gregory and Brian Marick from the agile world taught me so much while reading through their books, and I took the occasion to bother them with many personal questions back in the day. And finally not to forget, Gerald M. Weinberg, who has been a guide through his books, through email conversations whenever I bothered him, and through personal interactions at the problem-solving leadership class, I attended way back almost a decade ago.

 

Hexawise: You and Matt Heusser wrote Save Our Scrum, what software testing recommendations do you offer for those using scrum or agile software development practices?
Markus: The rapid and incremental-iterative nature of agile product development necessitates a high degree of test automation to catch the most basic problems that lurk up too late in the development cycle in more traditional approaches. With this high degree of reliance on test automation come two immediate effects that make you thrive in agile development.

First, test automation brings together testing know-how with software development. Test automation in the long-term needs to be adaptable to the changes in the production code, and for that maintenance to be built into your test automation code structure, you don't want to waste all your efforts by building something that you cannot sustain in the long-run. This fact brings together software programmers who (hopefully) know how to write maintainable code and skilled testers who know which tests to run to provide the confidence that everything is still working as before.

Second, with that high reliance on test automation, Matt and I both come from the context-driven testing school of thought. That said, you can only automate a test if you know about the expected outcomes, and we both know that there is a universe of things that we cannot think about. That second kind of area needs clever exploration so that we are not surprised by problems in the field about too many things we did not think about while automating our tests. This puts us in a dilemma. On the one hand, we shall spend time automating tests and exploring the unknowns. But the time we spent automating tests, we won't be spending to explore the unknowns. And vice versa, time spent to explore the unknowns is time we no longer have at hand to automate things we already know the software should do.

So, how much is the right amount of time to spend exploring, and how much of our time should we be spending automating? Clearly, there is no one-size-fits-all answer to this question, so it really boils down to the consultant answer: "it depends." A good consultant also puts some spotlights on the factors (s)he thinks it depends, so let me provide some of these spotlights as well. When you are working with a programming team that does good unit tests, maybe by applying test-driven development, the amount of exploration you can do might be higher because your programmers catch obvious problems very soon, and you only need to spend little time for all the interaction problems and the tougher problems in your codebase. If your programmers help out on automating story-level tests that might give you also more freedom for exploring the unknowns. On the other hand, if you regularly ship your product and the customers find many problems there, it might be wise to invest more efforts on automating the parts, and maybe get your programmers together to explore the unknowns with you.

When you are working with a programming team that does good unit tests, maybe by applying test-driven development, the amount of exploration you can do might be higher because your programmers catch obvious problems very soon, and you only need to spend little time for all the interaction problems and the tougher problems in your codebase.

 

Hexawise: Please describe a view or opinion about software testing that you have that many or most smart experienced software testers probably disagree with? What led you to this belief?

Markus: I'm not sure to which extend other testers might disagree with me, but there's a thing regarding test automation that I see time and again. "I will build a test automation framework to easier automate the tests for our application. I will be working on this the next xxx months (usually 3-6) before any of you will see anything of it."

That's a position I strongly disagree with. The disagreement is not so much on the necessity to have such a framework in the long run, but more on how it's done. Test automation code in my opinion and experience is software development, and such a framework needs to be developed like production code. You can do it in an iterative and incremental manner and respond to the emergent nature of your needs. Automate the first few tests. You will find there are some things you need in every automated test. Put them in some reusable mechanism like a class or a helper function. That part, you can make available to your other team members already.

When you automate the next tests, new things might come up that would be useful in their own places. Extract these reusable components as you go along. Your framework will grow naturally while you are using it, and maybe your fellow team colleagues come up with new ideas on what they need.

You need a different skill-set in order to be able to grow such a test automation framework. For example, you need to be able to remove duplications in your test automation code and extract components out of it. Sometimes you need to refactor your test automation from one design pattern to another as you go along. Everything while not breaking backwards compatibility with existing tests that you rely on. It's possible to do so technically, but if you lack the skill-set to do it, it will be impossible.

I recommend this and learning the critical skill-set to do so because of the psychological problems in the other approach around. The alternative would be a team member that does not contribute directly to the work of the other team members for months. Then he comes up with a solution, and surely there will be team members struggling with the design approach that person took. Too often I have seen such a test automation framework being abandoned for these kinds of reasons, and then the 3-6 months spent will be a waste of time.

At my first job we sort of did that when we decided to move our test automation approach from a shell-script based approach to something using a more sophisticated programming language. Gradually we brought the automation engineers in the position to use the framework we had gradually grown up to this point, and made them aware of bigger changes we thought we needed to do to be more adaptable in the future. After 18 weeks we had replaced what grew hysterically over the past year, and the new approach was working well with future changes. We learned the necessary skill-set along the way, but it was worthwhile.

Test automation code in my opinion and experience is software development, and such a framework needs be developed like production code. You can do it in an iterative and incremental manner and respond to the emergent nature of your needs. Automate the first few tests.

Hexawise: A few years ago you wrote a blog post on learning as a professional with some good tips on how to keep learning while practicing your profession. Do you have any updates you would suggest to that list or any specific suggestions you would like to highlight here?

Markus: Oh, that's a pretty old entry - yeah, I know, I haven't blogged for a while. Going through the entry, I think in terms of progression it helps to dive into books and articles to get to know the basics first. After that, you can engage more fruitful with the various communities out there, and continue your learning path with peers that you will find there. That's basically what I have used internationally in various communities, from the context-driven testing community, over to the software craftsmanship world and into the more general agile space. I tell this tale from my personal experience in these three different communities.

What always stuck with me over the years is a lesson my passed-away father provided to me. See, my father was a car mechanic working for a car repair station. Right before I finished my time at the university, he jokingly said to me: "So, then your learning will be over after that." Then he took me by his side, and said he was under this impression right before finishing his apprenticeship as a car mechanic. But real learning only started after that initial education. That's what he realized over the years when more and more electronics came into the cars, he still needed to continue his learning journey.

So, whether you are a car mechanic or someone that studied something at a university or you are just a janitor, learning is the most basic thing us humans do. Think about it, think about the things you are capable of doing. You were not born with most of this knowledge. That means, in your lifespan, you learned these skills, and the learning continues your whole life. That's the essence my father taught me that day. And I still stick with that. We're on a journey of life-long learning that will just end when we drop dead on the floor.

Profile

Markus Gärtner works as Organizational Design Consultant, Certified Scrum Trainer (CST) and Agile Coach for it-agile GmbH, Hamburg, Germany. Markus, author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development, a student of the work of Jerry Weinberg, received the Most Influential Agile Testing Professional Person Award in 2013, and contributes to the Softwerkskammer, the German Software Craftsmanship movement. Markus regularly presents at Agile and testing conferences all over the globe, as well as dedicating himself to writing about agile software development, software craftsmanship, and software testing, foremost in an Agile context. He maintains a personal blog.

Blog:  www.shino.de/blog/

Twitter: @mgaertne

Book: Save our Scrum