DevOps Zone is brought to you in partnership with:

Dawn Cannan is a software test evangelist who has been working to integrate testers as members of software development teams and improving the working relationships between testers, developers, and everyone else for the past 9 years. When not speaking at testing and agile conferences and user group meetings, she spends her time working in the open source community on the .NET version of SeleNesse, a plugin making it possible to create Selenium tests in FitNesse. She also writes actively, publishing articles and posting to her blog at Dawn is a DZone MVB and is not an employee of DZone and has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

Let's not forget what makes a good tester a good tester

  • submit to reddit
In the past year or so, I've spent more time than not trying to find really good "agile testers" to hire. In this search, I have also had many conversations with other people about what I am looking for, what they are looking for in hiring, and how we can find what we are looking for.
Lanette Creamer asked a question recently about whether people searching for agile testers seem to be starting to focus too much on technical skills over *testing* skills. (By the way, Lanette will be looking for a job soon -- if you have an opening or might during this year, I suggest taking a look at her blog, Testy Redhead, and contacting her for further discussions.) As someone who has and will continue to hire testers to work on agile teams, I'd like to lay down my priorities in what I look for, and make an appeal to other hiring managers not to forget the qualities that make a really great tester.
So, if I had to lay out a bulleted list of what I am looking for in a person to join my team, it would look something like this:

  • Passion: I am looking first and foremost for someone who is passionate about what they do. I want someone who enjoys testing, someone who will be on my team for the long haul and not just use it as a stepping stone.
  • "The testing mindset": This one is hard to quantify, and I am relatively certain that I won't do this description justice. But here's a shot at it: I believe that many great testers are naturally curious, naturally analytical, and are critical thinkers. I believe they are particularly good at seeing through a problem down to its root issue. I believe they usually enjoy puzzles and logic problems. Many very good testers I have known are the kinds of people that see a typo or grammatical error on some publication and it stands out to them like a sore thumb.
  • Technical ability: Coding ability is icing on the cake for me. I love to have it, but if it's not there explicitly, something that indicates an ability to learn to code is all I really need. I've said for a while that I think it's *much* easier to teach coding skills than "the testing mindset".

So when I am sitting in front of a pile of resumes, what process do I go through to try to find these people? It is by far not a perfect process, but here is *roughly* how I try to find great testers.

  • Before I have resumes, I must have posted a job description. I try to make my job descriptions stand out from the norm. My classic role model for this is the Atlassian QA Engineer job description: I do not require experience on an agile team or automation or coding skills.
  • A resume that stands out: (Let's assume I always do resume scanning/filtering on my own rather than using a recruiter) I found last year that a large percentage (just over 50%?) of the resumes I received were very bland. Many of them appeared to be nothing more than a broad list of technology keywords squished onto a few pages. Unfortunately, listing a whole bunch of technologies you have heard of (they can't possibly be masters of all of these technologies!), tells me *nothing* about what you actually *do* or how you do it. I look for a resume that describes your accomplishments and tells me what initiatives you are going to bring to my team. I also look specifically for signs of continuous improvement, both in themselves and in their roles.
  • During phone screening, I can usually get a good feel for whether passion exists or not. I tend to ask candidates about themselves, what they do, what they like about testing, and what they don't like, and what made them apply for my position. I tend to ask the typical biggest accomplishment and biggest disappointment type questions. I learned this year to ask questions about what they do outside of work (favorite blogs, books, websites, etc) and to pause long enough to let them say more than just their answer. Some people make it pretty clear at this point that they really want to do something else (like be a developer) or that they just need a job, period.
  • For those that I want to talk to in person, I've started giving them a testing exercise (thanks to Patrick Wilson-Welsh) to do between the phone interview and in-person interview. I've chosen to do it this way because I don't really want to filter out people just because they are nervous in an in-person interview. In this example, if they can follow and test Java code, that's great, but if they don't have that particular skill, I send them to just the target website of that exercise for testing, and ask them to jot down a list of what they found and questions they have. I encourage them to communicate with me and ask questions freely. I have actually had people "self-select" at this point and refuse to do it.

It's worth noting that this exercise is what gives me the most information about their analytical and testing skills. Their responses to this will tell me a few things. I will get to see how well they think through the problem and which things they have questions on. I'll get to see how comfortable they are asking questions (I want someone who is not afraid to ask questions). Hopefully, I will also get to see them find some bugs and evaluate how they report those bugs.

  • The in-person interview: It has been suggested to me that I work through the testing exercise in more detail with them in person -- kind of like a pair-testing exercise. In the future, I believe I will incorporate this more, because it makes sense. In general, though, by this point, I am fairly comfortable with the major qualities and fundamentals. During this stage, I tend to describe the current environment, along with the biggest challenges and hurdles to jump. I ask them how they would approach some of the real problems or tackle some of the actual challenges.

Obviously, there are many many resources available out there on how to find good people. Social networking has become a really great resource for recommendations for job applicants and shouldn't be overlooked as a source of finding people who can be specifically recommended. Johanna Rothman has an entire blog dedicated to Hiring Technical People. Books have been written on interviewing and lots of websites offer tips and advice on questions to ask. I'd like to hear from you about particularly good or bad interview experiences (from either side of the table) that you've had. What have I missed here?
Published at DZone with permission of Dawn Cannan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Phil Kirkham replied on Tue, 2011/08/30 - 9:49am

When I was looking for a job this job ad got my attention amongst all the other job ads that sounded the same. Part of the application process consisted of writing an essay and part of the interview process was a few hours pairing up on a real project. It made the company stand out and gave them and me a good sense of each other.

Andy Till replied on Wed, 2011/08/31 - 8:01am

Could you explain this key skill in your QA job description why you require "You think that bug reports are a necessary evil"?  I've always found that bug reports are the best way to get bugs fixed and not forgotten.

Lisa Crispin replied on Thu, 2011/09/01 - 3:30pm

Thanks for all the helpful resources - we are trying to hire a tester, and as always, it is hard to even find someone to interview.

 I personally agree with you about technical skills and programming background, but the programmers on my team want someone with whom they feel they can easily communicate. They find it hard to communicate with tester candidates who might be great at working with customers and doing exploratory testing, but aren't yet capable of managing their own test environments, working in an IDE, understanding basic code and architecture design terms. I feel like they could work a little harder at their own communication skills, but this still limits our pool of potential hires.

It has always taken us several months to find a good tester to hire. However, it's looking particularly grim right now, we can't even find anyone to bring in for an interview. I don't know if it's because IT is hot right now here, or maybe nobody wants to work with me, or what!

John David replied on Thu, 2012/01/26 - 3:24am

I learned to include a list of achievements on my resume in a so called "third-page". By then you get to include personal achievements beside the buzzwords and could really stand out compared to other applicants.

Java Eclipse

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.