Zeger van Hese: Markus, congratulations on your first book, ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, which you published recently. Can you explain what the book is all about? Why should people read it?

Markus Gärtner: Oh, it's not my first book. Back in 2008, I published my diploma thesis on hand-gesture detection. It’s in German, though. Maybe that's why I sold only six copies up until now. Now, you could claim that ATDD by Example is my first book in English. That would be probably right, but I also contributed a chapter on agile testing to How to Reduce the Cost of Software Testing by Matt Heusser and Govind Kulkarni.

So, what is ATDD by Example all about? The book provides an entry-level description of acceptance test-driven development (ATDD). At some point, I figured that the books available on ATDD either describe a tool or focus on the principles. Someone new to ATDD often faces the question of which tool to get started with and does not learn from the principles but rather from clear examples. So, up until now he was in the situation that he had to buy five books focusing on different tools, read them all, and then come up with a decision about which one to use. I wanted to change that.

Now, you can dive into ATDD by Example, work through the two examples using two different tools, and read up on the approach with its principles in the third part of the book. By then, you will have a good feeling for the different approaches of the tools. With Cucumber and FitNesse, I cover two of the most commonly used tools for ATDD around today. I also provide a hint to Robot Framework.

Zeger van Hese: What was your main reason to write ATDD by Example? Why ATDD?

Markus Gärtner: When I first read about ATDD back in 2008, my first thought was “I don't need this.” We had just finished transitioning our functional automated tests from shell scripts, which needed constant attention of ten people, to an approach using FitNesse. We had used test-driven development to develop most of the fixture code, we had continuous integration in place, and we had replaced the previous test suite that had grown over the course of one year—with five people, in a matter of eighteen weeks.

Then, back in 2009, I attended a session on good acceptance tests by Gojko Adzic at the Software Craftsmanship conference in London. He handed out copies of his then-new book, Bridging the Communication Gap. I started reading it immediately on my way home. I was amazed! Gojko's book helped me a lot with figuring out what acceptance tests actually meant.

My main reason to write it was to help people new to ATDD learn by example. Kent Beck's TDD by Example served as a blueprint there. Kent Beck introduced me to Pearson, and he was eager to put the book in his signature series. Two other reasons I wrote the book—though not the main ones—were to have a book available with up-to-date examples (the FIT book is dated 2005 and does not include the latest development in FitNesse like SLiM, for example) and to expose different ways to use ATDD on your project. That said, while the first example in the book deals with a website, Selenium, and some tester and programmer separation, the second example shows how to use the tests to drive an API and do outside-in development when you have access to the code. Actually, I am discovering the domain code while automating the examples there.

Nothing is actually new in the book. Rick Mugridge and Ward Cunningham wrote on the approach of ATDD back in 2005. A German book dated 2005 called Testgetriebene Entwicklung mit JUnit und FIT (in English, Test-driven Development Using JUnit and FIT) even shows how to do outside-in development based on a lot of ideas that eventually made their way into Growing Object-oriented Software Guided by Tests by Steve Freeman and Nat Pryce. Yet, I still felt that something was missing from the whole picture. That missing thing was my main motivation for ATDD by Example: to provide the missing piece in the whole puzzle.

Zeger van Hese: You mentioned the Software Craftsmanship conference. How did you get involved with the software craftsmanship movement?

Markus Gärtner: Back in 2008, I followed reports from the Agile 2008 conference. I read something about Uncle Bob's [Robert Martin] keynote, where he wanted to add a fifth value pair to the Agile Manifesto: “craftsmanship over crap.” He opposed the, well, “crap” on agile teams and stated that the spirit of the early agile days was indeed replaced by less focus on technical excellence. Later, he refined this to "craftsmanship over execution," since the value pairs in the agile manifesto have one thing in common: We value both at times, and we don't value crap at all.

With that refinement, he called out for a movement. I somehow crossed the Google group with its lively discussions back in November 2008. Folks from 8thLight and Obtiva were meeting in Chicago to distill what they thought craftsmanship is all about and put their results on the list for discussion. I saw the Manifesto for Software Craftsmanship evolve from the Agile Manifesto (named "The New Left Side" in the beginning) and was part of a smaller group of thirteen people distilling the equivalence to the principles of the Agile Manifesto off list. Doug Bradbury back then did an excellent job getting us back on convergence.

Jason Gorman announced the Software Craftsmanship conference in London back in December 2008, and it was sold out within hours. I was lucky enough to reserve a spot on that conference. It was awesome, even for a tester like me. Starting from there, I tried to learn as much as possible about software craftsmanship as I could—not from a technical point of view, but from a soft-skill point of view.

Early on, there were a lot of things going beyond "clean code." There was a craftsman swap between Obtiva and 8thLight first and a couple of other companies later in 2010. There was the Wandering Book [according to Wikipedia, “a book that travels from craftsman to craftsman capturing the current thinking about the zeitgeist of the software craftsmanship movement”] that seems to have disappeared. There were mentoring programs. To me, this was and still is the radical new approach of software craftsmanship.

Back in 2010, Andreas Leidig dropped me a line. He wanted to create a conference on software craftsmanship. We met up at the XP Days Germany and organized the first Software Craftsmanship and Testing (SoCraTes) conference in Germany in 2011. At SoCraTes, we also discussed how to continue from where we were. It was there that I discussed a local user group in Hamburg together with Roland Jülich, and a local user group in Bielefeld, Münster, and Osnabrück together with Martin Klose, Andreas Simon, and Oliver Paczkowski. There were a dozen others who wanted to create local user groups. That was the starting point for the German Softwerkskammer, and I look forward to this year's SoCraTes conference where we all come back together again to exchange what we learned since then.

Zeger van Hese: Do you see a specific role for testing in software craftsmanship?

Markus Gärtner: I see the field of software development and that of software testing changing dramatically. Agile methodologies so far taught us that a separation of testing and programming has its limitations. More important than that, it has also taught this to programmers and managers. I think in the years to come, testers will be very important to our field. We will teach testing to programmers, and we will have to seek testing skills in programmers, designers, and business experts and help them become better testers.

On the other hand, we will be challenged. Despite all the things we know about how things can go wrong, we will be in a position to learn about programming and overcome our fears about all the things that can go wrong.

So, while one of these futures scares a lot of testers, the other one is encouraging them to learn more about their craft. In the light of the new software development, we will have to find our spot. It will no longer be possible for a tester to hide behind test-case templates or foster following a test plan document only to find out that the product is unusable for everyone. I still think that testing is disrespected by others involved in software because there are too many out there who do a terrible job at it.

So, to answer your question, I don't see a specific role in software craftsmanship for testers, but I see the great value that we will bring in teaching and mentoring in the years to come. I see hope in the aspiring generation of software developers—that includes programmers and testers.

Zeger van Hese: Speaking of teaching and mentoring, you're doing your fair share of teaching and mentoring testers. What are your biggest challenges in that?

Markus Gärtner: My biggest challenge in teaching and mentoring testers right now is that I don't know what particularly I do that helps other testers grow. There, I said it! And, it's a fact. I do some things that help other people while others refuse to listen to me. Of course, this is all right. I don't listen to anyone else on the street either. While writing this, I started reading Thinking Fast and Slow by Daniel Kahneman. I haven't read too far right now, but what I understood is that I seem to be doing something intuitively right.

I notice what I have done with [software tester] Michael Larsen: I left him alone, encouraging him whenever he needed it, but I kept out of his way whenever he was doing the right thing—whether I believed in it or not. That's what I try to do with most testers right now: Keep out of their way. Unfortunately that's a terrible business model to start with.

Zeger van Hese: You'll be giving a workshop called "Beyond Testing" at CAST and Eurostar this year. Any thoughts on that?

Markus Gärtner: I look forward to both conferences. At EuroSTAR I really look forward to what I enjoy most about conferences: the networking (and the beer in the evening). When I am among other great testers in our industry, most answers come to me easily.

"Beyond Testing" is based on some nuggets that I found fruitful for testing. Long ago, I started digging into other topics than testing wisdom—topics like complexity science and psychology—and I found some pieces that are not very well known among testers. I see a lot of value in these fields, and I think we can learn a lot by combining these with our profession. That's what the workshop will be about: complexity science, psychology, and how we can relate that to our daily job in testing.

Zeger van Hese: Thank you for the chat, Markus.