Code Katas for Testers
Testers can do all sorts of things to be more productive and reduce waiting, including cut down on unnecessary documentation, pair with developers, get involved with design, and learn to test at the service level. But at some point, there will be downtime. Lately, I like to do code katas in my spare time.
A kata is a small programming task that you build a solution to, or sometimes multiple solutions. The point is to develop programming skill through familiarity with programming patterns. The question is, are code katas useful for testers? I think so.
I have been doing my katas by test-driving them through RSpec. I take a look at the problem and think about how I want to approach it. The first real task is figuring out the smallest piece of work I can tackle. I write a test that will fail because the implementation is missing, then write the code to satisfy the test.
When I’ve completed the kata, I have a working project in a public GitHub repository and a suite of tests that prove my work. I also like to integrate these with a free continuous integration system like Travis CI.
Lessons started becoming apparent after I experimented with a few katas.
Testing with code is a big one. We pair testers with developers on my current project, from beginning a change until it is ready to push to production. This includes testing throughout the process. This experience has taught me to better understand programming test coverage, how to spot missing test coverage, how to design tests, and how to design usable and testable code through unit testing.
Another lesson is empathy. Writing software is challenging and often frustrating. Every day presents new problem spaces, new technology stacks to learn, and new changes in direction. Testers are generally there to deliver bad news about how a new code change doesn’t work. But they are also a constant critical eye on the product looking for someone else's mistakes. This is crucial, but it can also be a challenging relationship.
Code katas have forced me to experience a little of that myself. After building tests and writing the kata, I post my public repo and CI build to our company developer Slack channel for review. When I seek feedback, the response is thoughtful, compassionate, and filled with careful questions about design choices and how to improve next time. Feedback forces me to consider where my code wasn’t very good or my skill level isn’t quite where it should be. These are hard things to think about, but again, it’s necessary.
That developer feedback is exactly what we should strive to provide as testers: thoughtful, compassionate, objective comments and careful questions.
If you have a couple of hours a week, I recommend trying a code kata in your language of choice. If you try more than one, you’ll learn about software development, testing, continuous integration systems, exploration—and even how to be a better person.
