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.

Test Leadership Breakfast

At our usual WeTest MeetUp events we get a wide variety of attendees from all levels of experience in testing, as well as those from other disciplines of software development with an interest in the topic of the day. This creates an environment for a varied conversation and questions, but often the discussion feels as though it dances across the surface of what it might be possible to talk about.

A diverse audience has advantages, but for a long time I've thought that there might be an opportunity for more focused conversation if we restricted the audience of an event. If we could create an audience with a specific similarity - whether that was years of experience, domain of employment, gender, or some other attribute - then people would have the opportunity to dig into topics of interest based on their shared experiences.

In 2013, our second year of WeTest, we tried to launch two initiatives to test our theory. WeTest Warriors was aimed at experienced testers and WeTest Green was aimed at those who were new to the industry. We scheduled an evening event for each group to socialise and share their stories over an informal pub dinner.

Both events were poorly attended and the initiatives were ultimately abandoned.

At the time I was a little perplexed by this. When I spoke with individuals during our normal events they would offer feedback and commentary that seemed to validate the idea of having separate discussions with a targeted audience. I thought that these people would jump at the chance to speak with their peers. They hadn't, but I wasn't sure why.

This year I decided to tackle the same idea in a slightly different way. Selfishly.

As I've moved through the testing profession into a leadership role, I have found that I have fewer and fewer peers within my organisation. Test leadership can become relatively lonely. I could see people out in the community who were tackling similar challenges to me, but I struggled to identify close colleagues who were doing the same.

I spoke to a few people in similar roles, then decided to launch a monthly Test Leadership Breakfast. I wanted to create a forum to bring together a specific collection of people that I was eager to have conversations with. By the event description:

This breakfast is exclusively for people who are currently working in Test Leadership roles to discuss their challenges and share their successes. It will be small, just 10 seats at the table, and will run in a Lean Coffee format.

The response was immediate. The ten seats were claimed for our first breakfast in January within a day of the event being advertised. The same happened in February and March too.

The feedback from events so far has been positive. Through the Lean Coffee format we've covered topics of conversation that have been useful to the people who have gathered. I've personally gained a lot of ideas and insight from the other attendees, and hope to have contributed to their thinking too.

I see this as proof of the value of gathering like-minds. In comparison to the Lean Coffee sessions I have attended with a varied audience, or the discussion at a usual WeTest event, every topic of conversation has had some relevance to my own role. Our discussion has been focused, productive and delved into exploring the details.

The contrast with our previous attempt to bring experienced testers together has been stark. Why did WeTest Warriors fail where the Test Leadership Breakfast has succeeded? On reflection, I see five key areas where our approach changed.

Naming is important. Test Leadership Breakfast clearly identifies the audience and nature of the event with simple, gender-neutral language. WeTest Warriors was alliterative, but in retrospect it was a rather intimidating and unclear name for what we were trying to do.

Evenings are busy. People have evening commitments to their family and friends, sports, hobbies, and other entertainment activities. Perhaps there are less intense demands on people in the early morning? A breakfast event might mean setting an earlier alarm and making alternative arrangements for family transport, but not forgoing another commitment.

Time is precious. For the evening events we had a relaxed approach to time. There was a start time listed, but no end time. Our assumption was that people would stay for however long they wished. By contrast, our breakfast events run for exactly an hour from 8am to 9am. People know the commitment that they are making.

Scarcity creates demand. WeTest Warriors was an open invite to a pub environment that could accommodate flexible attendance. By contrast, the breakfast event requires a booking at a local cafe who consider ten people to be a large group. It seems that the limited number of spaces drives a quicker response as people don't want to miss out.

Structure is reassuring. The Lean Coffee format offers a framework for productive conversation with strangers in a relatively informal setting. It helps focus the topics and manage individual contributions. I can see how this might be less intimidating than navigating totally informal conversations in a pub environment.

Beyond these details, the community evolved within those four years. Many WeTest attendees received promotions, which changed the group of people who made up the target audience of these events. We have grown and now have over 700 members in Wellington, which is significantly larger than in 2013. This means that a smaller proportion of members need to attend an event to make it successful.

This experience has also been a general reminder that a solution that fails doesn't mean that the premise is invalid. Approaching the same problem in two different ways can yield entirely different outcomes. Sometimes you have to step back, think about an alternative, then try again.