Alan Page posed this question on Twitter a few days back:
As a recruiting manager, I spend a lot of time thinking about what makes a good tester. As a test practitioner, I spend a lot of time working on my craft.
Low barrier to entry
What I have observed is that rather than a lower barrier to expertise, software testing has a low barrier to entry. The set of skills that make a good test practitioner is not easy to gauge and evaluate. The people who hire testers tend to rely on less than perfect metrics, such as certifications or years of experience, neither of which is a reliable indication of expertise. A low barrier to entry can have an impact on a perceived low barrier of expertise, but there are other issues that stem from it.
For example, complex systems often have large amounts bugs, and almost anyone could find some low hanging fruit without much knowledge of testing. That gives the illusion of good performance. More important issues (not just bugs) are harder to find and can be left undiscovered. That, in turn, creates a culture of “good enough,” where testers seem to be content with mediocrity. As Andy Tinkham put it:
“Good enough” culture
I agree with Andy. I have seen plenty of testers who are content with good enough, who stop at the minimum (if there is such a thing), who cover happy paths and edge cases and stop there. They may find some bugs, but rarely find the real deep issues in the systems, those that take a careful and dedicated practitioner to find. And when they do find issues, they struggle to communicate them eloquently, with diplomacy and compassion (yes, I believe compassion is an important part of a tester’s job; being able to tell a developer about issues in their work should be done with compassion).
Testing is not the only discipline with a low barrier to entry. Development has a low barrier to entry too (or at least lower than ever). College degrees are rarely required these days, and online programming courses are affordable and quick to take. Almost anyone can become a developer, just like almost anyone can be a tester. Although there is one notable difference: developers need to have a portfolio of some sort. Furthermore, industry accepted coding tests and exercises are available and used during interviews to assess code quality/craftsmanship. The same cannot be said for testing.
Don’t get me wrong. There are ways to assess a tester’s skills during interviews. Testing challenges and exercises give an interviewer a good idea of a person’s skill. Sadly though, most of the people interviewing testers wouldn’t know how to perform those assessments skilfully.
Seasoned testing professionals know how to conduct an effective testing interview. However, these professionals are not the norm. I speak from experience, gained over the span of my career as only once have I been given a testing exercise during an interview. All the other times I was asked theoretical competency questions that I could easily have memorized.
Other factors
Bad test interviews, bad hires, and bad management are only the tip of the iceberg. Other issues make testing a low barrier to entry industry: widespread ignorance about software testing, over reliance on automation and tools, lack of interest and knowledge about testing skills, confusion about test roles in agile environments, poor services, and unrealistic promises provided by outsourcing companies, to name a few.
We can do better
What can we do to raise the bar in testing and fight the good-enough culture plaguing our industry? A good starting point is James Bach’s post to the new tester which has tips on how to improve your career at whichever stage you find yourself in. I find that reading books, finding a mentor, getting involved in your local tech community, joining the conversations on Twitter, attending a reputable testing conference can all help too.
What about you? What are you doing to raise the bar in testing?
Road Less Tested 
What are some challenges and exercises that can be used when interviewing tester candidates?
Hi Erik,
Great question. When I interview testers, I like to have a balance of the below:
– Knowledge questions – most of the time the answers are not all important (they are important too), but what I look for is to find out how testers think. Do they ask questions? Do they go above and beyond minimal testing? How do they approach their testing? Do they know what a tester should be doing? Do they understand what testing is (and is not)?
– Practical questions – I ask testers to test something. Sometimes I ask them to test a pen or a piece of paper. Again, what I’m looking for here is the quality of the questions they’ll ask. Are they clarifying their assumptions? Do they just jump on testing without reflection? I often pair test during interviews or ask them to test ‘out loud’ i.e. telling me why they are doing what they are doing, what they are looking for, etc.
I’ve added further interview resources to my resources page.