Recruiting for the right talent is time consuming

Recruiting for the right talent is time consuming. Trust me. I spend a huge portion of my day involved in recruitment activities but it’s well worth it for the end result.

Good testers (and programmers/scrum masters etc) are really hard to find and increasingly hard to tempt to your workplace. They are in demand and hence often take extra leg work to get them for an interview – let alone get them on board.

However, over time recruitment becomes easier and quicker, especially if you take recruitment really seriously and work on building a large network and a multi-threaded approach to recruitment (more coming soon). In some instances recruitment can be very quick indeed – but in the early days it’s time consuming.

Or of course you could throw lots of money at a series of recruiters and chance that, but in my experience there is small group of recruiters who are especially good at finding top end testers.

In Johanna Rothman’s excellent book “Hiring Geeks That Fit” she makes the following statement:

“You don’t have to spend gobs of money to find great candidates, but if you don’t, you probably will need to spend time. Remember, potential candidates may not all look in one place to learn about the great job you have open, so you need to use a variety of sourcing techniques to reach them.”

Recruiting is hard work and it is time consuming so as you embark on hiring a team, or a tester, don’t expect it to happen overnight. It can take months before that elusive candidate turns up. Be prepared and don’t start your recruitment campaign days before you need a tester. Start early and be prepared. Or of course, throw gobs of money at the problem.

This is part of a series exploring how to hire good testers – the reverse “how to get a freaking awesome job” is covered in my book Remaining Relevant – a book for testers who want to take control of their careers. It’s full of advice on how to find good jobs, perform well in an interview and take control of your own self learning.

You can follow more posts in the series using this category link – or by subscribing to my RSS feed

Why testers really should learn to code

Testers need to learn to code *. Period.

And here’s why.

The market demands it and the supply is arriving.

As a hiring manager I’ve personally seen a massive increase in the number of testers who can now code. They may not be able to write production grade feature code, or automated tests, but they can write scripts to help them test, or they can write a small app that will inject data or they can extend an Open Source tool to make it work for their needs.

They can basically dig deeper than what you see on the screen, do more with automation and do a more varied set of testing by using tools and code. I see this as a positive thing – I know some people may not.

There is also a growing number of developers who are moving in to a technical testing capacity and learning how to do good exploratory testing and test planning. The market is buoyant for testers who code (and who know how to sell themselves) and it’s good for hiring managers. It’s quite rare now for me to find a tester who isn’t coding, or at least really focused on learning it.

In a nutshell the market is now being supplied with these once elusive testers who can code.

You could of course replace “learn to code” with “learn to do security testing” or “learn to do performance testing” but the reality is that most of these niches also require coding or scripting experience. It’s rare to find a tool that pops out of a box and does what you want it to do – despite what many of the tool vendors sales people will tell you.

To ignore the shift in the market is to leave yourself at a disadvantage when trying to get a job.

Whether you believe that coding is essential to being a good tester or not will soon become an irrelevant moral viewpoint. Testers now need to remain relevant to those with jobs, and those people with jobs for offer are starting to get multi-skilled testers (or T-Shaped as I call them) applying.

Instead of investing energy in fighting the inevitable train of change it might be worth spending that time learning to script, or carving out a niche in another aspect of testing (security, usability, off-shoring, test management etc), or resigning yourself to being outpaced in job applications.

We should be careful though to discern from simply following trends such as certifications and following evolutions in how testing is done. One is very dangerous and leads to lazy recruiting and competitions like certification inflation – the other is a natural progression of our testing craft. Learning to code is deeper than a certification; it’s a skill that can open up many new doors and give you access to tests that were once impossible without some code. Of course you could rely on the developers in the team to help out and that models works well, but the market is shifting and to remain relevant in this market means your skills will need to shift also **.

It’s no longer enough to be a tester who doesn’t code, because when you apply for a job you may be up against a tester similar to you who can code ***.


* Note – there are of course many roles within testing that mean coding or scripting is not essential such as management, strategy, coaching, leadership/directorship roles and problems solvers etc but for the mainstream testing roles the times are changing.

** Note – shifting skills could also mean learning specific tools, learning how to solve problems or, as the post suggests, learning how to code.

*** Note – of course – there are also lots of other ways to get hired rather than applying for a job – thought leadership and networking are two – I cover lots more in my book.

Testing is bigger than just testing

Testers have a main expertise in software testing.

Some testers could even have a more focused area of expertise such as usability, performance, security or exploratory testing.

When recruiting testers, you’re more than likely looking for one of these testers who has a core expertise in testing. Sounds logical.

But this is just an expertise and developing software requires more than just an expertise in testing; it requires doing what’s needed to ship software as a team.

Shipping software results in the company achieving its goals; most typically something to do with money. Ship stuff – get paid – keep the business going.

Shipping software often requires testers to step outside of traditional roles associated with testing, or to evolve what testing “is” so dramatically, that at first it may not appear to be testing.

The same is true of scrum masters, developers and anyone else building software.

So when hiring testers it’s important to hire testers who know their role within the company is more than testing; their role is to help the company ship good quality software and sometimes this means doing something that might not be testing.

In my experience all good testers are happy to evolve their skills to meet market changes and sometimes wear many hats within the business. Testing is increasingly becoming an activity done by everyone and is no longer just a phase done by people with the job title of “tester”.

Interviewing for this outlook and flexible thinking is harder than it may first seem, but it is possible.

If you want to ship good software frequently then it’s important to find people who can support this vision by being solid members of a team.

Team-work is all about the end goal and not just about the individual job title, main responsibilities or specialism.

What problem is hiring a tester solving?

When hiring testers it’s important to know what problem you are trying to solve.

By defining the problem that you have you’ll be able to ensure you solve the problem in the right way, whether that be by recruiting the right person or actually coming to the realization that recruitment won’t help.

Throwing more testers at a test problem is no guarantee that the test problem will go away.

For example, to handle a growing regression suite the answer may not be to hire more testers. It may be to hire a test automation specialist to automate the tests, or to encourage your developers to automate more tests.

Another example is poor quality products going out to production. You may improve the quality by hiring more testers, but you may also improve the quality by slowing down, spending longer designing what you’re building or working out some way to get rapid feedback on what is being built.

Recruiting is often time consuming and expensive so it’s always worth assessing whether recruiting more testers is going to solve your problem. To do this you need to know what problem you are trying to solve.

When you define your problem you’ll also have a clear understanding about the kind of person you are looking for. This will help you articulate your needs to recruiters. It also allows you to communicate more clearly to the candidate.

Being able to explain to a candidate what they will be doing and why it’s important for the business will increase your chances of a candidate accepting your role (assuming that’s what they want to do). Don’t be surprised if a candidate doesn’t accept your job offer if you cannot even clearly explain what their job role would be and in a sense, what problem they are going to solve for you.

Not all testers are created equal so it’s crucial to know whether their aptitudes and skills will solve your problems. Some are better at exploring, some are better at designing, some are better at building bridges between teams and some are very good at automating anything that moves. Each one of the above examples will help to solve a problem but not all of them will solve all problems.

By understanding your problem deeply you’ll be able to work hard to solve that problem. Simply hiring testers because you “feel” like you need resource leads to bloated test teams and ineffective delivery. And of course, the chances are you wont have solved your original problem.

Certifications are creating lazy hiring managers

A certification is not a marker of excellence.

I can say this categorically from the viewpoint of someone hiring testers.

It’s a viewpoint often ignored, dismissed and unheard by those extolling the virtues of the certification as an effective tool for hiring.

I’ve interviewed 100s of testers and I’ve yet to see any direct link between excellent candidates and their possession of a testing certification. Period.

certification of awesomeness
Certification of Awesomeness

To print your own certifications of awesomeness – visit Certification Magic.

Don’t rely on them for your recruitment as they won’t provide you with candidates who have the consistent level of experience, knowledge or aptitude that many people promoting this angle of certifications would have you believe.

If recruiting excellent testers was as simple as pre-filtering candidates based on them possessing a certification, then every software company in the world would have awesome test teams – but this simply isn’t the case.

You cannot presume someone with a certification is a talented tester.

You also cannot presume someone with no certification is a rubbish tester.

Anyone who tells you otherwise is selling you a certification, lying, misinformed or easily mislead in to spouting a message they have not thought critically about.

This doesn’t mean that certifications are bad. They could have their place. In fact I’ve heard some very compelling reasons recently for using the certification schemes. They seem to solve some people’s problems.

But they create problems in recruiting.

Certifications have created lazy recruiters (hiring managers, HR and recruitment agencies) by providing a seemingly easy way to filter applicants. This in turn has given lazy candidates a simple route to getting through the filters.

Candidate no longer need to excel at anything, nor up-skill (other than sitting more certifications) or learn how to sell themselves effectively (Testing Club link to a thread discussing selling yourself) in order to get an interview, and presumably, also land a job.

Overall it’s creating a vacuum of fairly average people all playing certification inflation to keep up with everyone else.

I believe that certifications are not improving our craft in the way many believe they could, or should, and they are negatively affecting the recruitment of testers.

A certification is a business transaction. Lets not pretend it’s anything more. You pay for a course, you get a certificate (and a short amount of coaching/training/lecturing/reading etc).

Certifications are not education and they are no substitute for on-the-job learning, but they may be a useful source of learning and a useful introduction to testing for some.

A certification tells you nothing about the candidate themselves. It tells you nothing about their soft skills, aptitude, motivations, self learning ethos or work ethic. This is important because being a good tester is more about the person than it is about the skills. Most skills can be taught and learned – aptitude, thought patterns and work ethic are much harder to change.

Recruitment is not supposed to be easy. It is hard work finding good testers. Your job as a hiring manager is to find good people. This means your job is going to be hard. Embrace the challenge.

Instead of relying on certifications why not try other innovative ways of getting the right people? It’s not as tricky or expensive as it may first seem. (I’ll be sharing many of these ways over the coming months).

But of course if all you want is another bum on a seat then certifications may be your more efficient way of recruiting.

If however, you want a test team that can help your business adapt to the changes and evolutions it will inevitably go through then you will have to drop your reliance on certifications as a way of recruiting testers; certifications are making both you and the majority of candidates in the testing industry lazy.

Effort on the CV is a good indicator of interest

Picture of a CV Image from The Italian VoiceCurriculum Vitae” March 2, 2008 via Flickr, Creative Commons Attribution.

A general heuristic you could apply when hiring good testers is to assume that the effort on a CV is directly related to how interested the candidate is in working for you.

The more effort applied to tailoring the CV – the more they are someone you want to hire. If you’re looking to hire a great test tester you’ll ideally be looking for people who want to work with you, and not just want any old job.

This is a good heuristic to use, but as always, it is fallible.

Generally speaking though a CV that has been tailored thoughtfully to match your job advert is often the sign of a tester who cares about working for you.

A boiler plate CV with no tailoring is a sure sign of someone who just wants a job – any job.

Be careful though. Not everyone knows how to write good CVs or tailor an application. You may miss some great candidates by applying the heuristic with no other key indicators.

In my opinion though if someone wants to work for you then they will take care and effort over the application.

Care and effort on the application manifests itself in a clean and simple CV with carefully chosen details to support their application. It will contain a sentence or two about each of the aspects in your job advert, even if it’s a simple statement saying “I am currently learning X” or “I am keen to understand more about Y”. It shows they care. And testers that care are the testers you’ll likely want to hire.

In my experience the better the CV – the better the candidate

Your Service Desk is your customer

(In the following post I use the term Service Desk to also mean “support desk” or whatever else you call the people who deal with calls from customers)

Call Centre
Image from Lamont_Cranston “aafad 167/365 call centre-kun” Nov 2, 2008 via Flickr, Creative Commons Attribution. – Image not modified.


Your Service Desk team is your customer.

You may have never thought of them in this way before but they are your customer.

They may not be your only customer but they are your most important customer.

The service desk may not be your company’s most important customer (or even seen as a customer at all to the wider business), but they are most likely your most important customer.

If service desk have a problem, you have a problem. If service desk have no problems the chances are (assuming your service desk is accessible for your end users) you are building and releasing something very good indeed. This is not a problem.

If your service desk are fielding 1000 calls a day about bugs in your product/service then you’re getting something wrong with your development process. And this is your problem.

If your service desk are fielding 100 questions a day about how a feature works then you’ve likely got something wrong with that features suitability, the documentation or the communication around it. And this is your problem.

If your service desk are fielding 10 requests a day and having to do something for your customer that they could realistically do themselves (i.e. resets, unlocking, data configuration) then you’ve likely got something wrong with your product or documentation or communication. And this is your problem.

Your testing (and the Dev cycle it exists within) is there to provide something of value for your end users/customers, whether that be a product or service. And when that product or service doesn’t meet expectations your end users/customers will likely contact service desk. Your customer is now your service desk.

You should do everything within your power to help them support your end users. Your test strategies, approaches and techniques should be designed to support your service desk. Ideally your process will be designed to minimize as many service desk calls as possible, but the reality is you’ll not catch everything. So design your testing to support customer issue resolution.

If service desk have a problem then development has a problem. It’s your job to stop people calling in (by creating something that solves their problems and doesn’t create new ones), but when they do call in it’s also your job to support those on the front line dealing with your end users problems. After all you most likely helped to create their problem in the first place.