Katas for Coding, Katas for Testing

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.

Code Katas

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?

Testing Katas?

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:

  1. 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?).
  2. 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.
  3. Generate – AND EXECUTE – as many test ideas as you can in thirty minutes, documenting the ideas and results in the mindmap. Then stop.
  4. Repeat once a day:
    sampleMindmap

    Wouldn’t it be awesome if testers screencasted this kind of thing the way that developers screencast their code katas?

    -Clint (@vscomputer)

    Advertisements

3 thoughts on “Katas for Coding, Katas for Testing

  1. Yeh, that was one of the topics at Test Retreat, how to practice your skills. Markus Gartner proposed the topic and hopefully he can come up with some ideas and material.
    It is hard though – easy to think of a code kata “Write a program to do ” but much harder “Write a test that shows off Bug Type Z” unless you have a buggy app

    Your SFDEPOt exercise sounds like it might have promise, I might have to follow along with that and give it a whirl.

    Keep on thinking of more

  2. Nice post, thanks.

    I’ve seen a lot of test katas, but most of them are exercises “test this (generally a software product).” Once you’ve done it once, you know where all the bugs are, or you have style – there isn’t the same value in repeating I see for TDD, where you can explore different ways. I like your idea of a product coverage outline, because you could ‘build it up’ different ways, maybe focus on different risks or different aspects of the product.

    I’ve done this by taking RobSab’s Ten Test Ideas checklist ( http://www.amibugshare.com/articles/Article_10_Sources_of_Testing_Ideas.pdf ) and focusing on differenet kinds of test ideas – each as a different exercise – then comparing the coverage that generates.

  3. The deliberate practice talk at test retreat was mine :). I think Markus talked about exploratory test retreat?

    Anyhew, interesting article, Clint. I’ve been thinking about and working on this topic myself lately. I see some value in the idea of kata but I don’t quite get how they apply to testing. As far as I understand, a kata (https://en.wikipedia.org/wiki/Kata) is some activity where you repeat a set of forms (or actions) in an identical way each time. How do you think of the term? I don’t quite get how that identical repetition transfers to testing yet though I’m open to the idea.

    Are you going to WHOSE? You should 🙂
    http://www.associationforsoftwaretesting.org/2013/09/05/cfp-workshop-on-self-education-in-software-testing-whose/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s