Last Friday, we had a release party for my book, Developer Testing: Building Quality into Software, here at Crisp. Thanks everyone for coming! Apart from signing books, I did a short presentation and made some announcements.
I started by talking about the process of writing the book (It’s available on Amazon, Adbris, and Bokus.) It took four years, but I did have some bumps along the road, like two kids :). For those of you who haven’t heard the story, here it goes: Large parts of the concept of developer testing were born during my time at the Swedish Postcode Lottery, where we were a brand new Scrum team working in a regulated industry. Since we had no testers on the team, and probably even more important, no traditions and rituals to adhere to, we self organised into automating all checking: at unit, integration, and end-to-end level to such a degree that we were confident about releasing, pretty much always.
True, we refactored, dumped old technologies, and generally improved and cleaned up the codebase, but it was the amount of developer tests, which were possible because we actively worked to achieve high testability, that made us confident. To this day, I’m not aware of any major issues in that code. So, in conclusion, my first insight was that quality can be achieved by solely developer work.
The second insight, that I shared in my short talk, was that after having spent time with several clients and several platforms (Java, .NET, mainframe, PHP, and variations thereof), I realized that all development teams’ maturity curves look roughly the same when it comes to developer testing practices, i.e. everybody has the same problems and challenges. In this light, having a resource, like a book, that would answer these questions as they emerged wouldn’t be a bad thing. That’s what actually convinced me to put the ideas in writing.
Developer Testing is Based on 9 Core Competencies
Next, I went on to talking about what developer testing actually is. To be honest, it did start as a bunch of techniques and skills that I’ve found useful, but after having matured for four years, it has become an integrated whole. For example, initially, I was a bit sceptical to the importance of programming by contract, until I realized that it’s a complement to the black box testing techniques that developer testing relies on when it comes to coming up with and designing test cases. Anyway, I described the nine core competencies of developer testing and there was a short Q/A session afterwards. The questions were:
- What do non-technical testers do in the world of developer testing? Answer: They have time to actually validate the product/system and design the hard test cases, since they’re no longer occupied by double checking (verifying) developer work and manually performing regression testing.
- What’s the alternative to TDD (it always gets discussions going when I say that testability is a function of controllability and observability, and not of time an precedence)? Answer: Since the factors behind testability are known, I believe that writing the tests after the code isn’t that dangerous. More important though, having earned most of my experience working with large legacy enterprise codebases, I believe that it’s often a feat to get the code to work at all first. Therefore trying to test-drive something in untestable spaghetti riddled with anti patterns and homegrown frameworks usually isn’t the most effective use of one’s time. In such circumstances, development is much more about prototyping. Once our assumptions prove to be correct, we can tailor the code towards being testable and then verify it. That said, test-driven development is the best way to automatically create controllable and observable code.
- Does developer testing include mutation testing? Answer: No, not in the book. Although the book cannot cover everything. There are other useful techniques that it doesn’t cover too. Mutation testing tools will be covered on the developer testing site in the future, tough.
New Companion Site
After that, I presented the book’s companion site developertesting.rocks. It contains the book’s errata, and I explained my rationale behind creating a tools page: although many tools are super-well documented online, I intend to publish cheat sheets and short guides that can be used to compare the tools… in the future.
New 3-day Training in Developer Testing
Finally, I announced the new Developer Testing training, which will be available as a public 3-day training at Crisp in March! The training is also available as an in-house training from January (please email me with questions). I know that three-day trainings are thought of as long, but after having given trainings in test-driven development, unit testing, agile testing, and alike, I know that I can’t fit all of the material on Developer Testing into two days and create a good training experience. For in-house occasions, I might shave of some topics, but I really recommend that the public training be three days.
Lastly, I instructed the guests in the art of Polish alchemy: one part Żubrówka and two parts apple juice turn into a cinnamon drink after stirring. Really.