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 more than having an expertise in 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

Blog Roadmap – 2014

I have neglected this blog over the last few months for a variety of reasons but I’m back on it.

So what follows below is my blogging road map for the rest of this year.

It’s based mostly around hiring the right people. It seems like my world is occupied by hiring right now. It’s a large part of my work at NewVoiceMedia and is a topic I’m deeply passionate about.

I wrote Remaining Relevant to help testers find good jobs and then do well in applications and interviews and I’ve since helped a number of testers improve their recruit-ability.

This next year will see me blog about recruiting from the other angle – from the angle of a hiring manager building an efficient and effective team – not just hiring testers who have all the buzzwords listed on their CV.

When I was recruiting one or two people I could rely on traditional ways of recruiting (adverts on jobs boards). When I was hiring in the numbers of around 5-10 I needed to get more efficient so I started using recruiters (they aren’t all bad) and other mechanisms to find people (which I will share as part of my upcoming posts)

When we’ve been recruiting in the 50+ (not all testers!) mark we really needed to get smart with how we do it.

I’ve only ever seen two presentations at a testing conference about hiring testers and both have made me cringe. One presentation talked about the process of scoring each candidate in a giant spreadsheet regarding some core skills such as test case management, defect writing and spec analysis. The person with the most points got the job.

There was no assessment of person fit, attitude, learning ethos, work ethics or anything else that is SUCH a big part of building an effective team.

The second presentation was about the desire to hire Top Class talent but with internal HR constraints and a crappy budget. The role went unfulfilled because the candidates weren’t good enough….but the salary wasn’t good enough and the aptitude tests by HR were putting off good people. (hint – fight the constraints, change the constraints, influence the people who can change the constraints, ignore the constraints, swap two roles for one or do whatever is necessary to get the person you need for the business to move forward – or of course lower your quality bar :))

It’s clear that most testers often don’t know how to get hired, and most hiring managers don’t seem to want to improve the hiring process.

I didn’t want to build an average test team here at NewVoiceMedia so I didn’t adopt average ways of recruiting. I’m not alone – there are many other talented hiring managers using innovative ways to get good talent to come and work with them – I’m hoping to get some of these people to guest post also 🙂

So the road-map will be focused on hiring. Here’s the road-map:

  • Effort on the CV is a good indicator
  • The certification is not a marker of excellence
  • Stop relying on certifications for hiring
  • Take recruiting seriously
  • What problem are you trying to solve?
  • Recruiting is not quick. Well not always
  • Plan carefully
  • Find a  trusted supplier
  • Don’t rush in to a decision
  • Dedicate time each day to recruitment
  • Kanban recruitment board
  • Tell them the truth. Are you offering a career in testing or just a job
  • Run retrospectives
  • Training versus hiring
  • Outsource all hiring or just some of it
  • Is your job role realistic
  • Writing good job adverts
  • Don’t use Nice To haves
  • Focus on values.
  • What end result do I want from each hire
  • Your recruitment consultants are an advert for your business
  • Learn from each interview
  • Direct contact is okay..if you have a compelling offer
  • Know their experience
  • Never the standard job spec
  • You are always hiring
  • Find people who inspire you
  • Slow down or speed up
  • Practical assessment are ok. In fact you should do them.
  • We don’t have the money to hire
  • Recruiters remove the need for tricky conversations
  • I don’t have the skills to recruit
  • Hire for your culture – not for skills.
  • Different messages for your recruiters
  • Videos
  • Filtering CVs.
  • Understanding a CV
  • CV Review – Look for outcomes
  • CV Review – Working through Jargon
  • Researching on Social Networks
  • Follow up on references
  • Logos on CVs
  • 3 Different Types of CV
  • How to deal with desperate candidates
  • Always be ready to receive an application
  • Should a hiring manager have an online presence
  • Create a business blog
  • Fending off recruiters
  • Networking
  • Follow up on prospects rapidly
  • Create a really great first impression
  • Recruiters – work out the ratio of success of each one
  • Build relationships with recruiters
  • Keep a record of all applicants and their outcome
  • Phone Interviews – Keep them short
  • Phone Interviews – Plan accordingly
  • Phone Interviews – Pair Up
  • Phone Interviews – Make Notes
  • Phone Interviews – Don’t Use a Phone
  • Phone Interviews – Lack of visuals
  • Phone Interviews – End the Call Like a Pro
  • Phone Interviews – Be clear and conscise
  • Interviews – Why do we do them?
  • Interviews – Open Questions
  • Interviews – Informal Discussions
  • Interviews – Leading Questions
  • Interviews – Closed Questions
  • Interviews – Loaded Questions
  • Interviews – Paraphrase Questions
  • Interviews – Hypothetical Questions
  • Interviews – Open With Time For Questions
  • Interviews – Time Keeping
  • Interviews – Appearance Matters
  • Interviews – Physical Proximity
  • Interviews – Make Them Feel Comfortable
  • Interviews – Turn Your Phone Off
  • Interviews – Eye Contact
  • Interviews – Leakage
  • Interviews – Take Notes
  • Interviews – Overpowering number of people
  • Interviewing for Second Life
  • Interviews – Did they actually answer the question
  • Interviews – Do a tour
  • Interviews – Be Honest
  • Interviews – Working with recruitment consultants
  • Interviews – Multi-part interview
  • Interviews – Reflect after the interview
  • Offering – Make it appealing
  • Rejecting – Give feedback
  • Recruiting – Be flexible
  • Accept rejection – don’t keep badgering
  • Killer questions in interview
  • Give people a chance
  • Don’t push a tester to be something they are not…and then call them stupid

And if I manage to blog all of that then I’m hoping you will have a pretty decent set of ideas to help you find good testers for your team.

Note – I may not blog in the order listed above. I will also expect new posts to emerge and existing ideas to be deleted.

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.

Build Quality In – The Book

Regularly readers will know the journey we’ve been on here at NewVoiceMedia and the way in which we’ve shrunk our release cycle down from yearly to weekly.

It’s an honour then to have been invited, along with my colleague Lyndsay Prewer, to contribute a chapter to an upcoming book called “Build Quality In“.

We’ll be sharing a story of our transition from yearly to weekly releases. We’ll feature in the book along with many other people doing great things in other companies.

70% of the profits are going to code club, a not-for-profit organisation that runs a UK-wide network of free volunteer-led after-school coding clubs for children aged 9-11.

The book is being curated and edited by Steve Smith and Matthew Skelton and can be bought on LeanPub.

Nordic Testing Days – The next big event?

I had the pleasure of attending Nordic Testing Days in Estonia last week. Two of my team, Dan Billing (@thetestdoctor) and Raji Bhamidipati (@peppytester) were speaking at the event so I tagged along to support them. And they did an awesome job – well done.

Should you go to the conference next year?

It was great.

2014-06-06 11.06.24
In Raji’s session on note taking
Dan Billing mingling with the organisors
Dan Billing mingling with the organisors


The Pros:

Estonia! – What a fabulous country to attend a conference in. The City of Tallinn was beautiful and the old town is a must see. For some photos of Tallinn visit my Google+ photos here

The organisation – it was a very well organised conference. The team behind it are a great laugh and worked really hard before and during the event – it went very smoothly indeed. They are passionate about delivering an outstanding conference and it shows in how good the conference was.

The speakers – what a good line up. The events website lists them all but the highlights for me were Stephen Janaway, Raji and Dan obviously!, Matt Heusser and Pete Walen keynote and Gitte Ottosen.

What I liked about Nordic Testing Days was that it was a “Context Driven” focused event that celebrated and encouraged discussion about interesting ways of working; it felt very much community based. It didn’t feel like I’d stepped in to a private club of context driven testers who were unwilling to listen to others people’s contexts unlike some events have started to feel recently.

The Venue – the venue was exceptional. It was clean, well staffed and very modern. Bizarrely enough the wifi even worked well (unheard of for most conferences) and the conference rooms were all close together keeping the crowds mingling.

The Entertainment and Conversations – There was a nice meal and some food after the first main day of the conference. There was also a bartender doing tricks and a comedian. The Old Town in Tallinn is amazing and lots of good conversations about testing were had in the bars on the main square.

For a short video of the bartender:

The Cons:

No conference is ever perfect but Nordic Testing Days was very close in my experience.

The Food – there didn’t seem to be enough food and it took ages to get what food there was. There was also very little choice for vegetarians meaning some people were left eating just salad for two days.

The purchasing of tickets – It took me ages to get the tickets bought. I didn’t seem to find a way to buy the ticket online via a credit card so had to work with invoices and money transfers. There needs to be a simple and easy way for someone to sign up and then pay for the event.


Nordic Testing Days felt like the early years of Agile Testing Days where people were coming together to create an event based around enthusiasm and a new way of talking about testing.

I have a strong feeling Nordic Testing Days will keep their momentum as the people behind the event are driven, focused, ambitious, talented and intent on creating the best testing conference on the planet. If this years event is anything to go by then expect Nordic Testing Days to become an event that will be the highlight of your testing calendar.