Phil Kirkham on Puzzles, Accidental Career Changes, and the Paradox of Testing

This is the fourth in a series of interviews with Atomic makers.

Meet Phil Kirkham: kerning expert, chipmunk photographer, and software tester at Atomic Object. I recently sat down with Phil to learn about testing, what drew him to it, and where he sees it going.

So, what is a software tester?

A tester tries to find problems in a program before the user does. You don’t want to login to your bank account and find that all the money has gone, you don’t want to be using your GPS and find yourself driving the wrong way down a one-way street, and you don’t want a game to crash just as you’re about to finish the level.

What do you like about it?

It’s often like a big puzzle game—you’ve got to try and find the mistakes. In a lot of companies, that’s really easy. At Atomic, it’s a challenge.

Because Atomic is a consultancy, I also get exposed to lots of different companies and business domains and lots of different tech, from embedded devices to web sites to mobile apps. Learning about the many ways and areas people are using software is something I find really interesting.

What do you find frustrating/difficult about testing software?

One of the paradoxes about being a quality tester is that you want a quality product—from the customer’s perspective, I don’t want to be finding bugs. But you also want to be useful by, well, finding bugs.

Another challenge is that because there’s so much bad software out there, people think finding bugs is easy. They can pick something up and find bugs, so they think anyone can test. But it’s not that simple. As an experienced tester, I know about edge cases and different paths through the system, how many combinations there can be, and typical errors that can come together to cause problems.

How did you come to be a software tester?

When I was a teenager, computers were the up-and-coming thing. So off I went to university to learn all about electronics, microprocessors, etc. I got a job at British Aerospace, where I did everything from counting how many screws went missing to testing an acoustic mine sweeper.

I noticed that programming was the thing to get into, so I pushed to get myself into the programming department there. I got the relevant experience, and then found a small company to work for—somewhere with better pay, better prospects, and less bureaucracy. They made typesetting systems for books and magazine houses. I got to know more than you ever want to about fonts and kerning.

I programmed there for 20 years, then found myself stuck as the “expert” on one part of the system, which was really boring. I took a personality test that suggested various career options, one of which was a tester. I seemed to have a knack for doing that when I was working. I was always better at the end of project, finding the things that were wrong and fixing them. So I got a couple of books on testing, realized that was what I wanted to do, then tried to move into it at the company where I was working. But I ran into a brick wall, so it was time to move on again.

I worked for a consultancy in London, but that involved a rented house and four hours of commuting a day. So I started looking for options. Being very active in the online community, I saw an ad for a software tester at Atomic Object, which sounded like exactly what I wanted to do. I worked remotely until my visa came through, and I’ve been here three and a half years so far.

What makes someone a good tester? What traits do you need?

Most testers find it by accident, like I did. They just get asked if they can test a piece of software and find they like doing it. And then they find a couple of books, and off they go.

You need critical thinking skills. Some psychology (being aware of how people use the system, of your own biases that can come into play). A little bit of philosophy: What exactly is quality? Technical know-how. Computing in general, so you can examine log files, set up your own data, and be aware of what things can go wrong with a program and why. Communication skills are vital if you want to be able to tell people why a bug is important, why it should be fixed. And you need listening skills so you can listen to users and learn what’s important for them, and listen to developers and find out what was complicated for them.

What do you like to do outside work?

I live a little way out in the country, and I like to take photographs of Michigan, especially of wildlife. I have so many photographs, I started a Twitter account for them. I also really like to watch soccer (or as we say, football).

Is software testing changing as technology changes?

Automation is taking away all the boring manual stuff we used to do. But the big problems have always been people problems rather than tech problems. You can never automate a test that says, “Do I enjoy using this piece of software?” An automated test won’t notice anything that it’s not programmed to check, and it won’t think of a new test to run whilst it’s running.

Testing does actually seem to be getting on people’s radar. And we’re trying to get involved earlier in the process. As requirements and user stories are being gathered, testers can start identifying problems before a line of code is written. They can find what’s wrong with the specs, what’s wrong with the user stories. I’m still pushing to get involved earlier; it’s something where I need more experience.