Lately two postings on my feed reader popped up regarding testability. While reading through Michael Boltons Testability entry, I noticed that his list is a very good one regarding testability. The problem with testability from my perspective is the little attendance it seems to get. Over the last week I was inspecting some legacy code. Legacy is meant here in the sense that Michael Feather’s pointed it out in his book “Working effectively with Legacy Code”: Code without tests. Today I did a code review and was upset about the classes I had to inspect. After even five classes I was completely upset and gave up. In the design of the classes I saw large to huge methods, dealing with each other, moving around instances of classes, where no clear repsonsibility was assigned to, variables in places, where one wouldn’t look for them, etc. While I am currently reading through Clean Code from the ObjectMentors, this makes me really upset. Not only after even ten years of test-driven development there is a lack of understanding about this practice, also there is a lack of understanding about testability. What worth is a class, that talks to three hard-coded classes during construction time? How can one get this beast under test? Dependency Injection techniques, Design Principles and all the like were completely absent on these classes. Clearly, this code is not testable – at least to 80% regarding the code coverage analysis I ran after I was able to add some basic unittests, where I could. Code lacking testability often also lacks some other problems. This is where Michael Bolton, James Bach and Bret Pettichord will turn in heuristics and checklists, the refactoring world named these as Smells.

On the Google Testing blog was an entry regarding a common problem, I also ran into several times: Why are we embarrassed to admit that we don’t know how to write tests? Based on my experience project managers and developers think that testers know the answers for all the problems hiding in the software. We get asked, “Can you test this?”, “Until when are you going to be finished?” without a clear understanding of what “tested” means or any insight what we do most of the time. “Perfect Software – and other illusions about testing” is a book from Jerry Weinberg from last year, which I still need to read through in order to know if it’s the right book to spread at my company – but I think so. If a develoepr doesn’t know about the latest or oldest or most spread technology, it’s not a problem at all. If a tester does not know how to “test” this piece of code, it is. He’s blocking the project, making it impossible to deliver on schedule – escalation! What Misko points out in his blog entry is, that the real problem behind this is also testability:

Everyone is in search of some magic test framework, technology, the know-how, which will solve the testing woes. Well I have news for you: there is no such thing. The secret in tests is in writing testable code, not in knowing some magic on testing side. And it certainly is not in some company which will sell you some test automation framework. Let me make this super clear: The secret in testing is in writing testable-code! You need to go after your developers not your test-organization.

I’d like to print this out and hang it all over the place at work.

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.

Ivan Sanchez put up a blog entry on a parable: Three stone cutters. He challenged my thoughts with the following question:

Sometimes I have this feeling that we as professionals are frequently trying to be more like the [“I’m a great stone cutter. I can use all my techniques to produce the best shaped stone“] stone cutter than the [“I’m a stone cutter and I’m building a cathedral”] one. Am I the only one?

Due to the analgoy I felt the urge to reply to this question with Elisabeth Hendricksons Lost in Translation and Gojko Adzics Bridging the Communication Gap. Most of the stone cutters I meet in daily business think they are creating a cathedral, while building a tower of babel. The biggest obstacle to efficient project success lies from my point of view in communication among team members.

This principle was discovered in his research on successful project in the 90s and early 2000s by Alistair Cockburn, see for example Methodology Space or Software development as a Cooperative Game (Warning: don’t get lost on his wiki site just as I did several times). Software Development is done for people by people. Since people are strong on communicating and looking around, software development as whole should strengthen this particular facet of us. A cathedrale is of no use if the entrance is on the top of the highest tower. Though during day to day work I see software developers lacking early feedbacks, that do not see the problem.

The industry I’m working in has a high changing rate of requirements. In the mobile phone industry there really are impacts from competitors, that you will have to react on to stay in business. For me this means to reduce the time to market for the product we’re building as massive as reasonable from a quality perspective. This also means to communicate with our customers spread all over the world in different time zones – even in distributed teams. This means that I need to find technical and motivational ways to bring people together that do not see each other on a day to day basis in the office. Just last week I we performed a Lessons Learned workshop on one of our products, where our colleagues in Malaysia took there web cam the first time and showed us how the world was looking outside their office. (It was during a refreshening break, so don’t get wild on wasted resources, my dear boss.) This lead to personal touch and a lower personal distance between the two teams – at least during that session.

Anyways I wonder why these moments happen too little. Instead I see teams – erm basically groups of people – working without communicating with each other though they need some information from the co-worker directly near to them and wondering in the end why there is an integration problem. Another point is the problem of open interfaces (lacking communication of protocols and the like), open scope (lacking the communication of content of the project), open everything. Clearly, for me it seems there is no way to communicate too much, it’s more the opposite that I bother about.