Good testers are hard to find.

Some testers are more equal than others

George Orwell wrote, “All animals are equal but some animals are more equal than others” and I have often asked “If all testers are equal why are some so darn useless?” What exactly should you look for when recruiting testers? What are the key behaviors and attitudes that indicate that you have found a good tester?

The CV and other works of fiction.

When recruiting for testers, the first hurdle is getting through the deluge of CV’s. A good way to weed out the initial pile is to bin any that on first scan through do not scream “I AM A TESTER! I am constantly amazed at how often I get CV’s that start by saying that the candidate is looking for a support role, or a development role or to develop their database skills, or, for crying out loud, “looking to get in to IT”. The CV should that for the past few years, the candidate has held roles as a tester and ideally those years should be spread over more than one project, as this indicates a level of experience and exposure to more than one way of doing things. The CV should be clearly laid out and without typos or spelling mistakes. Again, I am stunned by the number of CV’s I get for a role that is going to require the successful candidate to write clear and accurate error reports, that are difficult to read and full of errors. Ideally the CV should also show some evidence of career development, courses attended and qualifications gained. Indicators and clues in the CV that I look for include;

Longevity of assignments or employment
Evidence of product or industry knowledge
Use of defect tracking systems
Exposure to different phases of testing
Technical ability (coding, databases, networks and the like)
Job Title includes Test (Test Analyst, Tester, Test Team Lead)
Test Activities (Writing Test Cases, Writing Defect Reports, Test Automation)

The Interview
I love interviews, both as a candidate and as an interviewer, its where all the carefully constructed wording that puts both sides in the best light can be challenged and explored. To get the best candidates, you have to prepare properly for the interview. Turing up and ‘winging it’ is not doing either side any favors. I tend to have a set of prepared questions I ask every candidate as well exploratory questions based on their CV. With both sets of questions I tend to ask the candidate to give an example of a real life situation that answers the question, so for example if I am trying to find out how they handle a disagreement from development about a bug, I will ask them if they can think of a time when a developer has reacted negatively to a bug report they have produced, and then go on to ask them how in that specific example they handled the matter and how was it resolved.

I also have a couple of off the wall warm up questions I like to start with, one is; “When was the last time you wrote to a company to complain, and what was it about?” I am suspicious of anyone who claims to be a tester and who does not from time to time write to complain. Another of my stock question is; “If I employ you, what will you do as a tester that will make me look good?” I truly believe that the testers job is to make the test manager look good (Writing good scripts, finding bugs, working late if required etc.) I also believe that the test managers job is to give the tester everything they need to make the manager look good (Decent requirements, adequate time , representative environments, right tools etc.) My final stock question is to ask: “ What books on testing have you read, or what testing websites do you visit.” With so much good material out there, I can accept no excuse form someone who considers themselves a serious tester if they are not reading testing related material regularly I do from time to time throw in a little test exercise to see how they write test cases, or how they report issues.

Throughout the interview I am looking for evidence of the following traits and actions;

Passion for testing, a love for finding faults
Ability to clearly express their views
Diligent recording of bugs
Experience of multiple phases of testing (system, integration, UAT etc)
Experience of writing good test cases
Willingness to work extra hours
Ability to work undirected
Ability to work as a team member
Plenty of ‘war stories’ that show that they have truly been there and done that.

To see myself as others see me.
References are an absolute must. I think this is often one of the most powerful tools we have when recruiting, and often one that is under used or overlooked. I always phone and chat one on one with at least two referees. In fact I often find that I have two candidates who both seem equally qualified for the role in question, and it is the comments by their past managers that swing the decision one way or the other. I also find that an informal chat on the phone allows past managers to say things that they might not be quite so happy to put in writing.

You get what you ask for

Of course, getting good testers often relies on knowing what to ask for in the first place, as well as tailoring the Job Specification to your local project, you might want to have a list of ready definitions, role descriptions and tasks that you can use. The following are suggestions of generic definitions that are appropriate to most testing role specifications.

Role:
To prepare and execute test cases as directed by the Lead Tester.

Overall Responsibilities
To support the Lead Tester and Project Manager in building and managing the test plan if required to do so.
Perform all tasks allocated by the Lead Tester and ensure they are completed on schedule and to budget.
To understand and work towards achieving quality objectives.
To communicate status against plan as and when required.

Specific Responsibilities
Ensure all items personally produced within the test plan have complied with the required quality assurance process, and that all have received sign off by the appropriate parties.
Develop test cases as directed by the Lead Tester.
Execute test cases as allocated by the Lead Tester.
Raise incident records accurately and with sufficient information to enable developers to understand and reproduce the incident.
Ensure valid to invalid ratio of incident closing codes against incidents personally reported is within acceptable boundaries e.g. the number of ‘Duplicate bugs’ or ‘No Bugs’ reported is not excessive.

Competencies
Team Working. Demonstrate positive team-working with colleagues, works with clear accountability of own work within a team, escalates issues promptly and reports progress
Flexible Approach. Capable of working in a new environment, quick learner and open to new ideas and processes
Business Knowledge. Is analytical and has a systematic approach to problem solving with some experience of a similar / relevant business environment.
Technical Knowledge. Technical Expert - provides an authoritative view of the technical impact of change, provides technical expertise to the test team.
Adaptable. Proactive within the test process, can apply existing business or technical skills to new technologies and processes quickly and efficiently.

Tony Simms is the Principal Consultant at www.roque.co.uk and can be contacted via email, tony.simms@roque.co.uk.