So come on and walk with me tonight and we’ll talk.
If I repeat it, it’s ‘cause I mean it and I don’t know what to do in a conversation.
It might take a little time, but you know, baby I’ve got the time.
Good Luck – “Same Stories”
Sometime around the winter of 2011 (not-so-coincidentally soon after watching James Whittaker’s talk at STAR West All That Testing Is Getting In The Way Of Quality), a few coworkers and I decided we wanted to know more about the inner workings of our product. We wanted to dig into the code, with the end goal of participating in unit test reviews, maybe adding additional value by fixing some bugs ourselves, and generally just becoming more technical testers. We decided to devote our innovation time (my organization generously provides 20% time for innovationy stuff) to forming a C# self-education group where we’d get together once a week and code for a couple of hours.
One of my developer buddies, Brian Dishaw, graciously volunteered to mentor us. Brian – a busy guy – was stuck in meetings for most of our sessions and couldn’t sit there guiding us for long. He did, however, point us towards Roy Osherove’s invaluable TDD Kata as a jumping-off point for learning a new programming language.
I may drive to work every day, but I’m far from a professional driver. Similarly, programming every day may not be enough to make you a professional programmer. So what can turn someone into a professional driver or programmer? What do you do to practice? – Jeff Atwood
Code katas are simple coding exercises that you practice every day. The term is borrowed from the martial arts: Mr. Miyagi made Daniel-san wax his cars as a way to strengthen his blocking muscles, and code katas are a way to strengthen your coding muscles. Mr. Osherove recommends that you do his TDD Kata every day for 30 minutes. I decided to take that recommendation at face value and literally do that kata, once a day, every day, for a couple of months. (Can you keep a secret? Sometimes I did it more than once in a day.) At the end of that training period, I felt like I knew a bit about unit testing in C#, enough that I felt comfortable diving into my team’s test suite and start banging around in the code. So, drilling for weeks on that TDD Kata was really useful to me.
Whether it made me a good programmer is a different question.
A Caveat (and Another Use For Katas)
Yesterday, for kicks, I pulled the TDD Kata out of mothballs and ran it again. Then I went back and looked at all my old TDD Katas I’d saved on my hard drive 18 months ago.
It seems to me that the old katas were written by an insane person. I would never do the kata that way now! But I’m sure that at the time I looked at these things and went “Hey, I’m doing pretty well here! This code is clean as a whistle,” while making a calculator that uses 6 member variables to add a couple of numbers together.
So, in addition to increasing your skills and confidence as a programmer, the katas also create a document of your progress as a code thinker. I can contrast yesterday’s kata against last year’s kata and see what I’m doing that makes me better now. What changed? Why do I like the new code better?
The most interesting feature, to me, of Rapid Software Testing is that it elevates being skilled over memorizing facts. I liked this video from James Bach where he explained that the Rapid Software Testing approach aims to make it easier to increase and access your “tacit skills” through the use of “heuristics”. That’s a jargony way of saying that RST aims to help you get better at testing through effortful practice.
So how can we effortfully practice? What can we use as testing katas? I don’t know, what do you think? If you’ve got great ideas, let’s talk about them! We need something that we can do every day, in the same way, to get better at a particular aspect of testing. And – to provide the documentary quality that the code katas do – we need to capture our actions in some kind of document.
My first idea is this:
- Take a feature from a software product that’s on your desktop, or even a manufactured object that’s physically nearby (I used a pen the first time; for testing purposes it should really be a different thing each time, I think?).
- Start a mindmap in your favorite mindmapping application, and apply the SFDIPOT heuristic by making a node each for Structure, Functions, Data, Interface, Platform, Operations and Time.
- Generate – AND EXECUTE – as many test ideas as you can in thirty minutes, documenting the ideas and results in the mindmap. Then stop.
Wouldn’t it be awesome if testers screencasted this kind of thing the way that developers screencast their code katas?