Sunday, 12 March 2017

How do you hire a junior tester?

I recently participated in a workshop that was co-hosted by the New Zealand Qualifications Authority (NZQA) and New Zealand IT Professionals (ITP). They're exploring the idea of creating a new qualification for software testing within our tertiary education system.

One of the topics of conversation that I found interesting was the question of how employers currently recruit junior testers. By junior, I mean a person with no experience in testing, regardless of age or other work history. As there are no dedicated testing qualifications* at present, where do new testers come from?

I sat in a discussion group with Aaron Hodder, Adam Howard, and Anna Marshall. We came up with a list of ways that we found the junior testers in our organisations that included, in no particular order:
  • the business - subject matter experts who show aptitude for testing
  • overseas - new arrivals to New Zealand may start in a junior role
  • internships - through programs like Summer of Tech
  • consulting firms - local consultancies who run their own graduate training and placement
  • graduates - those who are fresh from study

In my experience, finding candidates for a junior testing role is not a problem. When I've advertised a role that is suited to the wide audience defined above, I've had a lot of applicants. Testing is seen as a pathway into the IT industry, so there is a lot of interest.

I think that the workshop question is more interesting when it is considered in a slightly different way. As there are no dedicated testing qualifications at present, by what criteria do you recruit junior testers? In other words, how do you decide which person to hire?

I assess the testers who work in our agile delivery teams by six criteria that can be broadly summarised as:
  1. Testing knowledge and experience
  2. Automation knowledge and experience
  3. Agile knowledge and experience
  4. Domain knowledge
  5. People skills
  6. Growth mindset

I'm not looking to hire people who hit all of those criteria. I am looking to create testing teams with complementary individual strengths that mean we are collectively strong in all of those criteria. This applies across all testers, not just juniors.

When I hire a junior, I'm generally looking at the latter criteria in the list. While a junior may have knowledge of testing, automation and agile, it is likely to be entirely theoretical. I probably have strong testing, automation, and agile skills in the existing testing team anyway. The strengths that a junior might bring are their domain knowledge, people skills, and growth mindset.

I've talked previously about why you should hire junior testers. The benefits that I see in making junior testers part of the team, which largely focus on their attitude and behaviour, can be difficult to quantify. Similarly, the attributes that I am looking for in order to realise those benefits can be difficult to quantify, which means that they generally aren't assessed in an IT qualification.

I look for juniors who can communicate and work well in a team. People who are eager to learn, pick up new ideas quickly, and constantly search for a better way of doing things. Perhaps people with these traits are more likely to pursue higher education, but not necessarily. A person can pass a qualification without possessing these particular skills.

So, would it be useful to create a software testing qualification? Perhaps. If the qualification had a strong syllabus that was delivered in a practical manner, then hiring someone with this qualification might save some time when explaining basic concepts.

Would the presence of a software testing qualification change how I hire junior testers? Perhaps. The presence of such a qualification might increase the chance that I interview a candidate as I would spot it when screening CVs, but I'm not sure that it would have a significant bearing on the final criteria by which I hire.

Does New Zealand need a new software testing qualification? Perhaps. When I received the invitation to the workshop I thought it sounded like a great idea. As a trainer I was excited about the challenge of creating a syllabus. But the more that I've thought about it from the perspective of an employer, the less sure I become.

Now I'm curious. How do you hire a junior tester? By what criteria do you choose a candidate? Is there a software testing qualification in your country? Do you think there should be? I welcome your comments below.


* ISTQB is a certification, not a qualification. A certification is an official document attesting to a status or level of achievement. A qualification is a pass of an examination or an official completion of a course, especially one conferring status as a recognized practitioner of a profession or activity.


  1. Oh, wow, I really like your list.
    Really curious about how do you try to assess testing knowledge and growth mindset. 2nd question - Is your list any different when hiring an experienced tester? I found out that for me, the list is the same for junior and senior testers, only I expect a different level of it (for instance - I expect a junior tester knowledge about testing to be a general feeling on how testing is done, and maybe some intuition. My expectation from a senior tester is to show they are learning as they go).

    As for my criteria, there are about three or four (funny thing, just wrote about it yesterday, the number changes according to the exact wording I put to it):
    1. System view and a good technical sense (I look for the ability to provide a high level overview and dive deeper upon request)
    2. "A tester mindset" - I am looking for candidates that ask questions, think on their feet and keep in mind the business goal. Risk awareness is also a part of it. testing theory is a nice bonus. Sometimes,I merge this one with the 1st criteria.
    3. Coding skills. Nope, not automation specific. Especially not for a junior. Automation is just programming. The exact specialization doesn't matter much, and focusing on automation might hide a gap in the basic programming skills (algorithmic approach, proper flow control, data structures, etc.)
    4. Communication skills (though I think I prefer your definition of "people skills", it seems more accurate).

    As for a qualification - I'm not sure I understood your distinction between certification and qualification. We have several "testing courses" that are (up to) ~500 hours and are pretty worthless (they prepare their students to the ISTQB foundation exam and learn some basic intro to several subjects - knowing what a computer is, a week's worth of SQL, writing some documents, etc). I'm not sure how to categorize them, but I would rather if they didn't exist as they increase the number of candidates I have to filter out.

    1. Hi Amit,

      Thanks for your comment. In response to your questions:

      1) How do you try to assess testing knowledge and growth mindset?

      This is tricky, but I have a couple of questions that I like to ask during interviews:

      -- Tell me about the work you’ve been doing recently. What’s the most interesting bug that you’ve found, and why?

      -- What process are you using for testing currently? Can you describe how you might improve it?

      2) Is your list any different when hiring an experienced tester?

      No, I use the same criteria but I expect seniors to have different strengths within that list. A similar strategy to yours.

  2. Hi Katrina,

    can't comment on the hiring part of your story as I've never been in that position (nor do I want to, so that's cool), but I have something to add on the position that software testing has in our education system here in the Netherlands. This is still just a partial view as I don't know the details of every curriculum from every college and university (again, nor do I want to ;) but I've been on both sides. Both times at a math/science-oriented university, I must add.

    When I was in university ('98-'04), there was no subject that covered testing. Software quality was sometimes touched upon, but in a very formal, model based, logic and semantics-based, mathematical manner. Not a good basis for a career in software testing.

    Last year, I had the opportunity to teach a full class (7 lectures + practical assignment) on software testing at another university here in NL. I was pleasantly surprised that that particular university at least offered a course on testing and software quality. It was an optional course, but still, a big improvement from the time when I was a student.

    Until I saw the material of my predecessor. We were asked to host this course at pretty much the last moment (a month or so before the first class) so there wasn't really time to start over from scratch, all we could do was freshen up the existing material a little. It was SO academic, SO focused on outdated concepts, SO far away from the reality.. But it was what we had to work with. We tried to liven things up with our own working experience, but that only went so far.. We revamped the practical assignment to reflect a modern software testing project, though, and that was the best rated part of the whole course.

    I think that's about the extent of software testing qualification here in NL, a single course here and there, but not nearly enough to deliver qualified testers to the job market. I'd love to see this change!

  3. Hi,
    I still like the idea of handing out something to "test", like a roller pen or a tea bag or something similarly simple. I think it gives me an impression if systematic thinking, creative ideas and humor are present. And I seriously think that some humor is needed for testers.
    For the curriculum/qualification/training: I really dislike the Istqb stuff. The idea of having something standardized in order to get a common understanding with others is great, but it is not close to enough. I would send my mentees to take exam and course only after at least half a year of experience in an existing team.