The myth of the standard tester

I always tell candidates looking for a job to have a standard CV, but to never send this CV to anyone. Never.

The ‘Standard CV” is a starting point for a contextually specific CV that gets the hiring manager giddy with excitement about speaking to you.

Yet the other way around, it’s very common for companies to have a “standard job spec” for most roles.

We have another Testing role available, someone send me the Tester’s job spec please!

This standard spec gets rolled out whenever there is a new position available or an existing employee leaves. It’s got some generic stuff on it and it’s pretty vague about everything. It asks for a broad range of skills (cos we want a wide pool of people) and doesn’t specify much in the way of actual expectations or outcomes.

It contains lots of buzzwords and leaves the door open for the widest selection of candidates the company can attract.

I think this is sad.

I think this is sad for two reasons:

1. If your business is that generic (i.e. that anyone can fill a testing role) then I suspect you’re solving the wrong problem by hiring generic people.

2. I don’t believe any two Testers are ever the same, so why should the roles they fulfil be?

As your business moves and grows (or shrinks), your products mature or you start to move to new technologies, techniques or processes it is inevitable that the roles you need will change also.

One of the major challenges a manager may face is ensuring that your teams skills and goals are in alignment with the business needs, and that your teams skills can/will change in line with your business.

I think that each team needs diversity of mindsets, skills and experience. I think each business needs different Testing skills at different times. A great team will acknowledge this and flex and grow with the business. Standard test teams won’t.

I think that all Test Managers who hire from a “standard” job spec do so because they know no different (or HR are forcing their hand). I did this for a few months and spent that entire time griping about how few good candidates there are. I was casting the net too wide and wasn’t 100% sure who I was looking for). I then narrowed and recruited an excellent team (If I say so myself 🙂 )

  • Do we just need a “standard” tester (whatever that may be)?
  • Or someone with Exploratory Testing skills?
  • Automation skills?
  • Database Testing skills?
  • Security Testing skills?
  • Web Testing skills?
  • Messaging skills?
  • Email and multimedia skills?
  • Specialist domain knowledge?
  • Managerial skills?
  • Leadership skills?
  • People skills?

I could go on for ever.

Why do we try to cast the net wide and grab the most generic person we can find when deep down inside we want someone with some specialisms, or a certain outlook on life, or certain skills and abilities?

  • Is it because it’s hard work initially to write new job specs and think long and hard about the actual objectives we want this person to achieve? Yep. Probably.
  • Is it because this process will take a longer time than the generic advert? Yep. It will do, but it will be cheaper in the long run.
  • Is it because recruiters are asking for generic job specs? Maybe. But believe me, there are some great recruitment consultants out there.
  • Is it because it’s always been done this way? Yep. Absolutely. But why should that stop you changing it?
  • Is it because I may have to get creative about the hiring process and work hard to find someone right, rather than someone who *might* be right? Yep. But that’s your job right?

So here’s what I believe anyone hiring for a tester (or building a new team) should/could/might do:

  • Define the personality traits of the person you want to hire.
  • Define the actual skills that person will need.
  • Define the activities they will do.
  • Define the outcomes you expect that person to achieve.
  • Write a new job spec for each position.
  • Screen, screen and screen – face-to-face interviews are expensive for everyone involved.
  • Interview based on the things you’ve defined above. Test them. Show them around. Invite them to meet other people. Ask varied questions. Tough questions. Be Open and Honest; make it clear what the objectives of the role are.
  • Be subjective in your decision making.
  • Be Open Minded and willing the flex on some things.
  • Be hardline about the things that really and truly matter.
  • Do not discriminate.
  • Get a second opinion.
  • Read Cem Kaner’s excellent interviewing article (www.kaner.com/pdfs/QWjobs.pdf).

Offer to the right person and you will have no regrets. Offer to a generic person, for a generic role and I suspect you’ll have your work cut out in the months and years that follow.

Hiring the right person is going to take much longer but in the long run, but it’s a price worth paying.

One Reply to “The myth of the standard tester”

  1. Hi Rob,I agree that there should not be a standard tester for a standard role, but I disagree that a generic job spec doesn’t have its place… I think with a small test team where you are only looking for a specific role to be filled, you are absolutely correct, but in larger organisations then a generic job spec can work, as you have more freedom to tailor your resources. You can ensure that an individual who answers a generic job spec can still be an individual, with their own specific career path – you simply have the resource to be able to decide which role that they are going to fill (or even tailor a brand new one for them) after they have joined. Moreover, having a more specific CV might scare aware people who might be ideal for one of the other roles. At a previous company where I was the senior tester (we had no ‘Test Manager’) I used three generic Job Specs (Trainee, ‘Standard’ and Senior), but for a specific reason – at the time we had 40 – 50 testers, but only about 10 of them were permanent employees, so I was never looking for a specific individual for a specific role – I was looking for a specific type of person who could end up in whichever of the 30 – 40 roles currently being done by contract staff was most appropriate. So therefore the generic job specs could ask for specific personality traits, and could be reasonably precise about the fact that we used Agile, but couldn’t be more specific about day to day activities, as there were usually 12 ongoing projects, each with different needs. Test resource per project could be between 0.5 and 10 people. Environments were different. The requirements of the testers were different. Some roles used automation, some were manual. Larger teams allowed testers with specific skill-sets, smaller teams needed testers who could do it all. It certainly wouldn’t have been possible to create specific job specs for each of the roles. In this kind of environment it became more of a question of when we got in a good candidate, then thinking about the best roles they could fill once they started – that would benefit both the company and the individual. So it was never an issue of hiring a generic tester – it was only to find good testers and using the size of the company to find the role that was most appropriate to them – and having the luxury to not have to fill a specific role. It could actually be quite freeing – one of the best testers we got in answered the generic ‘standard’ CV, but had almost no experience (‘checking’ only), but as we really liked him and his passion for what we were doing, we were still able to employ him in a trainee role somewhere completely different. After someone was hired it was then a question of ensuring that each tester was treated as an individual. As a specific person, with specific needs, and their own personal development plan and career. The problem comes in the big companies where you’re not able to do this (EDS springs to mind straight away from when I worked there) where you really were considered just one of a big pool of testers. What do you think?

Comments are closed.