Learning To Learn (About Testing)

It is not every day that I find myself playing billards with some of the best thinkers in software testing.
Still, there I was, in Westlake, Ohio, at the Marriott Residence Inn, the day before the conference. We had a pool table, and five people - David Hoppe, Justin Rohrman, Peter Schrijver, and Erik Davis.
The next day we were set to discuss skills in software testing, so we set down to play a game or two.
Except, of course, my brain doesn't work like that -- I immediately began to think about skills in pool.
Growing Your Billiard Skills
First we spent an hour or so "just paying pool." Rack the balls, hit them with the cue ball, and on we go.
Most of us had never studied the game seriously. We could generally make the trivial shot, where you "just" want the ball to go straight. Periodicaly, though, we found ourselves trying to make a complex shot -- hitting he cue ball at just the right point so that when it hit the ball, the ball in play would move at a different angle.
This is, well, hard. We got it wrong a lot.
After an hour of playing, I noticed something: We weren't getting any better.
Each complex shot was very different than the shots before, which left us with no point of reference, no muscle memory to improve.
Building Muscle Memory
In traditional sports, the way to learn is to do the same activity over and over again. Serving in Volleyball, making shots in basketball, or hitting the ball in billiards - you set up the same complex shot, and do it over and over again until it is repeatable -- and you know why. Then, in the heat of the game, your body says "oh, this is kind of like that other thing I did a million times" and you don't think but react.
I'm oversimplifying a bit here; this is a blog post, not a book. The point is that repeat performance (practice) builds skill in most human domains.
Even in programming we have the idea of the Kata, of doing the same exercise again and again, discovering different ways to write the code, until it becomes familiar.
"Test Katas", on the other hand, make a lot less sense. You find where the bug is the first time, and on the second run through, finding it is going to be really easy. We talk about simulating a real project, where you get multiple "Builds" to test, to create a more realistic (and practice-able) kata -- but i haven't seen one yet, and I read about testing, well ... a lot.
In fact, if you go to a typical test conference, it is possible to go entire days without seeing any sort of realistic exercise, as simple as "here's a UI - how would you test it?"
Depending on the angle you look at the seem more obsessed with new and shiny, with automating the process, or measuring it, or talking about sidebar issues (hiring, firing, project management) than in the doing of the testing. The examples we do have tend to be trivial: "A triangle has three inputs ..." When they aren't trivial, we tend to focus on the technque ("equivilance class partitioning!") more than the skills.
The implication seems to be that coming up with test ideas is easy -- and as far as confirmatory testing, that may be true. Take a spec, turn it sideways, and every "the system shall ..." turns into a test idea.
That's also a weak and shallow form of testing.
Creating exercises that teach real skill is hard. Kaner, Hoffman, and Padmanahban where working on their Domain Testing Workbook for something close to a decade. At four-hundred and sixty-three letter-sized pages, the book is intimidating to even the most serious student of testing.
I am convinced that skill development is what we need.
Katas in testing are what we need.
We don't need lectures; we need thoughtful practice that ties in to our everyday work.
I've done a little bit of this; Parkcalc, a test exercise I developed, now yeidls 892 hits on google, and the Miagido School has its own web page too.
Still, as 2013 winds down, I can't help but think that we've got a long way to go.
Right now, as of December 16, 2013, I am in a position where I can choose my shot for next year, and have a little time to focus on it. My biggest interest is skills in testing, real skills in testing. As the editor of Stickyminds.com, I will be looking to publish articles that talk about it, but I'll be writing more than a few myself, speaking about it in public and private. The assignments I'll be looking for will be those that allow me to practice skills while studying and documenting them.

http://www.stickyminds.com/blog/matt-heusser/learning-learn-about-testing