By Kate Paulk

In many software companies, it's difficult to convince upper management that the company needs to hire more testers. Sadly, many of the reasons for not hiring testers leaves all testers who are there (and quite a few of the developers) wondering how many misconceptions about testing decision-makers believe.  

Here are ten of the most common and most misguided reasons for not hiring more testers.

1. Only Lazy Programmers Write Bugs

Or Having Testers Makes Programmers Lazy

This unfortunate belief ultimately derives from the idea that it's possible to write software without bugs, without spending a fortune, or taking forever. While completely bug-free software can be created, it has to be either ridiculously trivial, (Hello World! comes to mind here, or some school programming assignments) or the entire team needs to commit to spending untold time hunting down and killing those last few bugs before release.

If that wasn't enough, a lot of bugs come down to differences between how a developer interprets the organization's requirements documents, how the test team interprets those same documents, or how the project managers and everyone else interprets them, and what the customer actually meant in the first place. There's no universe where laziness could cause any of these kinds of bugs.

2. We Have Unit Tests

Or Anyone On The Team Can Test It

The idea that unit tests are enough or that anyone on the team can test is another common misguided idea to avoid hiring testers. People who think unit tests are enough tend to deliver software with user interface issues or problems where different components don't work together as well as they could.

Even the best unit tests still test units. They don't test end-to-end flow through an application process, and they don't test that the user interface is usable or intuitive.

The biggest benefits of dedicated, skilled testers are the ability to find gaps in the assumptions other people may have made. It's part of the tester-mindset to ask, "What will happen if I press the big red button that says 'Don't Push This Button'?" People who don't have tester-mindset aren't as likely to think to test for usability, or for an intuitive flow through the system. They may not think to try to force the software to do things it shouldn't do. Or they might not test that it can handle unexpected input gracefully.

3. It's A Web App - We Can Fix It In Production

The idea that being able to push a quick patch to production is a reason to do without skilled testers isn't just misguided, it can be actively damaging to the company of the people who believe this.

To start with, any patch includes the possibility of introducing more problems. When a patch is pushed through quickly and not tested, it's even more likely to introduce new bugs.

In addition, if something is fixed in production because it was reported by customers, that means customers see it. Longstanding research shows that only four percent of customers will notify the business when they have a problem. For every person who reports a problem, there are at least another 24 others who have experienced the same problem. They could be telling all their friends and family how bad the app is and how they shouldn't waste their time on it. Even though the research was originally published in 1971, the proportion of customers who report problems to the business is unlikely to have changed much, but today the 24 who don't report the problem are telling their friends on social media, bad news can go viral and destroy a company's reputation.

From this perspective, skilled testers start to look like insurance against a company losing reputation.

4. We Can Use Interns Or New Hires

Throwing interns or new hires at a testing task assumes that testing is easy and anyone can do it.

Of course, bad testing is easy and just about anyone can do bad testing, which won't - unless you're lucky - expose important data about any problems they might find. Without the skills to quickly isolate and track down a problem, then describe it in a way that makes it relatively easy for someone else to reproduce it, there will be a lot of bug tennis.

Another concern about interns and non-tester new hires is that they typically don't have business domain knowledge. They are a lot less likely to realize that they need to find a domain expert to learn how the more complex aspects of the system are supposed to work.

5. The BA/Documentation Team/Customer Service Team Can Test It

While this is a better option than throwing interns or new hires at untested software, there are still some big flaws with this idea. To start with, business analysts, technical writers and customer service people all have their own jobs to do. They're going to prioritize those jobs above testing the software, and they're not going to have the time to focus on testing when they're also handling other responsibilities.

The skills needed to be good at business analysis, technical documentation, or customer support might overlap some by comparison, but they don't have the same day-to-day focus and practical application knowledge testers have in their role. People in these roles typically don't need to isolate and document problems, much less go through application logs or determine what kind of data is likely to find problems in the application. The end result is that any business who thinks they can have non-testers handle the testing is likely to have a very well tested happy path and not much testing for anything else.

6. The Customers Will Test It For Us

Or We Have A Beta Program

A good beta program is invaluable. One of the factors that makes it so valuable is that the people who use beta software, whether end users like the early adopters of Gmail or customers who receive a beta version to evaluate new features prior to release, know what they're getting. They know not to use the beta software for anything they can't afford to lose. Even when it's from a company like Google with a reputation for producing nearly flawless beta versions of their software, they understand the value of beta programs to them as well as the limitations of beta software.

Quite simply, people don't like using beta software for anything they consider essential. Too many have been burned by losing important data to incompatible upgrades or crashes.

The answer is not, as some seem to think, to neglect to mention that the software they're selling isn't quite ready. This sends customers who have suffered too much from "undocumented beta" versions to the companies they can trust and are transparent. These will more than likely be your competitors.

7. We Don't Have Time/Manpower To Test

It's a Rule of the universe that if you don't have the time to do something correctly, you'll be forced to make time to do it again until you get it right, or you’re driven out of the competition. This applies to any business and any product. Software is no different.

No matter how good the development process is, the application will have bugs. Software that's actively tested throughout the development process will find a good number of those bugs before they're released to a customer. This means not only is it faster to fix them because there are fewer activities in the deployment cycle to redo, but also that your company remains in your customer’s good graces.

If your customer’s goodwill isn't incentive enough, companies with a reputation for consistently releasing buggy software eventually become bankrupt companies. There's a reason Microsoft has put so much effort into improving the quality of its software over the last ten years or so. They have also improved the perceived quality of their software. Something that's as important as the actual quality when it comes to customer retention.

8. Anyone Qualified To Be A Good Tester Won't Stay A Tester

The assumptions behind this belief are horrific. The notion that testing is the act of following detailed instructions and, more or less, being a trained robot is just the start to this problematic  “reason”. This also assumes that "qualified to be a good tester" means someone who is capable of being or becoming a good programmer, business analyst, or technical writer. It's the kind of viewpoint that's immensely damaging to the testing field as well as to the dedicated testers who love their craft.

Good testers are people who have enough technical knowledge to isolate anomalous behavior. They have enough communication skills to create good bug reports which clearly describe problems so they can be isolated and fixed.  They enjoy digging into software and tracking down problems. They may also enjoy creating automated checks for regression suites, or building helper tools for their team, or helping to clarify and refine user stories and other documentation. The duties and skills of a good tester can, and often do, overlap with the duties and skills of other team members.

The only time someone like this won't stay in a testing role is when that role is limited to writing detailed test plans, and test cases, and implementing them. The kind of creativity required to find and isolate problems in software is stifled in an environment that requires a person to act like a robot.

9. We Can't Afford Testers

Our universal rule covers this misconception too: 'If you don't have the time to do something correctly, you'll be forced to make time to do it again.’ In this particular case, if you don't have the money to do it right, you will have to find the money to do it over.  Many companies have found to their cost that they should have testers on staff.

Testers are as human as everyone else. Having testers on staff doesn’t mean that they can catch all the serious problems before those issues reach production, or even worse the customers. It means that far fewer serious problems will reach production, because skilled testers are good at finding and isolating them. In turn, it means the company will have a better reputation, which usually translates to selling more software.

Think of hiring software testers much like someone would pick out insurance for a car or a house. Insurance companies don’t produce anything, but you pay your premium knowing that when something happens, they will take care of it. If testers are working to ensure that defects don’t escape to production, then you are paying your premium to try as hard as possible to keep your software, and your company, from a major failure. After all, no company wants to see itself in the news because of a software failure.

10. Testers Find Too Many Bugs

This idea is like the cliche of the ostrich with its head in the sand believing that if it can't see a predator it's safe. Problems with software don't go away if everyone pretends they don't exist. Instead, they cause customers to be unhappy with the company that makes the software, often to the extent of telling their friends and associates to avoid it.

Most people prefer to know in advance that there's a problem and how to work around it, if possible. How many times have you complained about getting trapped in a traffic jam caused by freeway road works which weren’t signposted until after the last exit you could use to detour around it? Personally, I have grouched about that many times. It's much better to tell people about the problems you didn't fix along with the ones you did fix than let them stumble into it and apologize.

Every bug found and fixed before a release is a bug that doesn't have to be explained or apologized for to customers. It improves the company's reputation and reduces the chance that customers will decide to take their business elsewhere. It can also help with company morale.   

Testers Are Important

The Internet is littered with examples of companies and governments damaged or ruined by insufficient or non-existent testing. Companies like Knight Capital Group and Peak Hosting which were bankrupted by bugs. In Knight Capital's case, it took less than an hour to destroy a profitable business.

Any business will make decisions based on cost, risk, and potential reward. When the risk includes the possibility of bankruptcy, the question starts to become: "Can you afford not to hire skilled testers?”

References

• A Sisyphean Task - Bug tennis
• Business Insider - 96% of customers don't complain
• Business Insider - Cisco bug blamed for bankruptcy
• Developertown - All software has bugs
• Doug Seven - Knightmare: a devops cautionary tale
• Joel On Software - 5 wrong reasons you don't have testers
• Linkedin - How a software bug made Knight Capital lose 500 million in a day
• Ministry of Testing - 10 misconceptions about software testing
• Ministry of Testing - 10 reasons testing isn't boring
• MSDN - Perceived vs objective quality
• Project Smart - Top 5 wrong reasons for not hiring testers
• Qualitest Group - Insufficiently tested software kills companies
• Stack Exchange question & answers - when is it OK not to have dedicated testers?
• Test Talk - 4 reasons companies neglect software testing
• What the customer really wanted cartoon

Author Bio

Kate Paulk refers to herself as a chaos magnet, because if software is going to go wrong, it will go wrong for her. She stumbles over edge cases without trying, accidentally summons demonic entities, and is a shameless geek girl of the science fiction and fantasy variety, with a strange sense of humor.

In what she ironically refers to as her free time, she writes. Novels, short stories, and more recently, articles for the Dojo.