In a recent blog entry over at 8thLight’s blog Angelique Martin points out to 8 things you ought to know if you do not know anything about hiring a software developer. Having been involved with the Software Craftsmanship movement since the early days, and 8thLight has played a major role in that movement early on, this list was compelling to me.

In short, Angelique reminds us to ask potential new employees for the development processes they used, their development practices, – particularly TDD, pair programming, short iterations, and continuous integration – and how they educated themselves and kept their claws sharp. She also points out that she would ask for a proof of their talent, how they estimated, how deadlines are met, and what they can say about the costs involved when developing software.

This list was so compelling to that I decided to put up a similar list with the things I was looking out for hiring a software tester. I believe there are some unique skills I would look for in a software tester that I would not necessarily look for in a programmer. So, here it is.

I would ask about their approach in different contexts. Agile software development is all around us. But still many companies also use more traditional approaches. In the end, one approach to testing might work in an Agile shop, while it would fail dramatically on a more traditional project. I would look for their adaptability to different contexts, and how they react to different situations. In today’s world it’s certainly not enough to know about the latest methodology, but also to apply different techniques as unique situations unfold. I would also look out for their tactics in fast-paced Agile iterations, and how they adapt to two week long sprints. What about one week? What about daily deployments?

I would ask about the testing techniques they could show me right now without preparation. My experience in our field is that testers visit a course or two – if they actually can do so. After that they use the 20 percent of testing knowledge that they need in their day job – without exercising their brain cells on the remaining 80 percent. Even worse, there is little interest in growing beyond these practices. If the potential new hire can share a lot of testing techniques without preparation, she certainly uses all of these different techniques regularly.

I would ask about their programming experiences. Fast-paced iterations call for test automation. Even if you don’t work in an Agile context, programming knowledge will benefit you at creating different tools that assist your manual tests. In the end, you can talk to programmers on a different level, if you can at least read their code. Specifically I would ask the potential new tester if she could pair with me right now on some production code. I would also ask for experiences with TDD, pair programming, pair testing, continuous integration, and different automation tools and programming languages.

I would ask for heuristics they regularly use. Test automation alone is not enough. A good tester also needs to be aware of the oracles and heuristics by which we recognize a problem. A good tester also knows when to aim for more depth in their test sessions, or to aim for overview on a new product. These are covered in many of the mnemonics on software testing around. Maybe they even came up with their own mnemonic on aspects in their testing which they regularly use.

I would ask for a demonstration of their skills. This could mean to submit an example bug report as Lessons Learned in Software Testing points out. This certainly also means that I hand them some problem to test, and ask them to show me how they would test the particular application. Among the things I would look out for, is how they handle traps, and what basic assumptions about testing they follow through. I certainly would use one of the missions over at Testing Challenges.org. I would also spent an eye on how they try to clarify the mission, and how they involve the different stakeholders in their testing.

I would ask for how they work on their knowledge. What has been the latest book on software testing that they read? Which blogs do they read regularly? Did they invent a new testing technique (like the Black Viper testing)? Which conferences did they attend? Which online coaching opportunities did they take? Weekend Testing? Skype coaching? Miagi-Do? BBST? These are all examples of personal dedication to our craft. They also show a passion for life-long learning.

I would ask for how they collaborated. This includes collaboration with programmers like pair programming, but also with peers in pair testing sessions. I would also seek to get to know how they worked out specification details and acceptance tests with the customer. What is their approach to collaborate with programmers who don’t give a thing about testing and testers? How do they show their unique value they bring to the software development process, and how do they get others engaged in what they do? Testers need not be alone in their daily struggle on quality, and certainly shouldn’t be the gatekeeper about quality. I would look for a tester who understands that quality in the software is a team effort.

I would ask for their previous professional job. In the last year, I attended the second writing-about-testing workshop. During the introduction on the first day, everyone stated how she or he came into testing. Most of the participants didn’t pick software testing as their first job. Eventually they found out about their passion for testing by accident. Since then I made it a habit to interview testers about their path to the profession. Most of them had interesting stories to tell, and even compelling insights about fields of expertise that suits any tester.