Matt Heusser came up with the idea of the Boutique Tester. While reading through his article, I was wondering about the same striking question that arises in me since the early days of the Software Craftsmanship movement: Where are testers going to be in the Craftsman world?
Some months ago I started a series which I called Testing focus of Software Craftsmanship, covering Values, Principles I and Principles II and in addition I have planned an entry on Principles III, that I did not conclude so far. Most of the stuff in it I took from Elisabeth Hendrickson, Lisa Crispin, Janet Gregory, Brian Marick, James Bach, etc., etc. In this series I tried to raise an understanding of the testers role in the craft world while just restating the lessons most Agile teams already learned. The reason that I did not yet conclude this series is that I came to the realization that there seems to be no clear understanding of the sticky minded in the craftsman worldview for me.
Reflecting back on the lessons I learned from Agile methodologies like extreme Programming, Scrum, Crystal or Lean I remember myself being a bit jealous. Programmers were taught to use test-driven development, pair programming, big visible charts, planning poker. For me they seemed to have most of the fun. The tester simply does testing – the stuff they always do. As long as they don’t get into the way, this is wonderful… It was striking first, but when I realized that there are definitions of Exploratory Testing, Pair Testing, Retrospectives, etc., I got aware that testers also have fun activities.
A while back I proposed to rename the Agile testing school to the example-driven one. After getting some feedback from peers, I realized that there seem to be no room for school-mindsets in the Agile world and care for naming in the other schools. My initial motivation to rename the Agile school was driven by the realization that the Agile view on testing seem to be a good one for craftsmanship either. While my reasoning was based on poor assumptions, I started to realize a bigger argument behind this.
The bigger argument behind all three previously described situations is from my point of view that Software Testers have defined their craft long, long ago. Jerry Weinberg wrote in December about the way unit testing was done in the older days. Over the years there have been several thought-leaders appeared for Software testing. (I refuse to name a few here, since I know I’m too few in business to give honor the right ones.) Over and over the craft of software testing has been discussed, defined and found anew as the latest approaches to Agile testing teaches us. Just a few months back there was a heavy discussion on why Agile testers just define the terms that context-driven testers already teach since decades.
What is the difference between Software Craftspersons and Testing Craftspersons then? Testers know their craft from decades of experiencing and definition. There are more than enough books out there that teach good software testing just as not so good techniques. Software testers have most of their set of tools together to start leading their craft. For the development world this is not as true. Over the decades programming languages have come up and fallen down. Programming techniques like assembler, structured programming languages, logical programming languages, object-oriented programming languages, functional languages. The craft of software development seems to be more fluent to me as the craft of software testing. You can nearly apply all the testing techniques found in the books to your software, even to real world products as an Easy Button.
My point is that Matt raises a good point in his Boutique Tester article. Testers can directly go out and provide their testing services, gaining experiences over the years in order to improve. Maybe they can also take apprentices to teach the lessons they learned over the years. Basically I assume his proposal could work, though I’m concerned whether I would like to view myself more as a tester-developer or more as a developer-tester. In the end I think what matters most, is that there is only us and testers and developers form some kind of a symbiosis, just as automated and manual testing does. It’s a good thing that we’re not all generalists, but we should keep our mind open for different views of the problem at hand to compose an improved solution to it.