Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why your QA testers quit—and what to do about it

public://pictures/Matthew-Heusser-Managing-Consultant-Excelon-Development.jpg
Matthew Heusser Managing Consultant, Excelon Development
 

When I ask quality assurance (QA) testers how they got into the job, most of the time they say that they just sort of fell into it. Unfortunately, QA testers often fall out just as quickly as they came in, which leads to time and money spent recruiting and training new testers.

After years of hearing tragic tales of continuous tester turnover, I started to wonder if testing is just a temporary, transitional role for many people. If that's true, would managers be better off preparing for high turnover rates instead of trying to reduce them?

I presented this idea at the Conference for the Association for Software Testing (CAST). Then, during the Q&A period that followed, two test managers told me that they had reduced turnover in QA to near zero. It can be done, and that's a good thing because the cost of turnover is much higher than you might think.

The hidden cost of high turnover

Ben Yaroch, former president of the Association for Software Testing, puts the career average for a tester at four years. After employees move on, Staffing.org estimates the cost of recruiting a replacement at 13.4 percent of the annual salary for the position. If you use an outside staffing agency, you can bump up that number by an additional 15 to 30 percent. That includes only the cost of the interview process and assumes that your new hire is fully productive on day one. It doesn't include the full cost of onboarding and training.

New testers need to learn the product, understand your standard of quality (how good is good enough), and learn your organization's process, tools, and business rules. In the beginning, new testers will be net negative producers, meaning they will make less forward progress, or even slow the team down. In a worst case scenario, a new tester might miss key problems, allowing major defects to slip out the door.

One team I worked with recently was developing complex survey software. They refused contractor terms of less than six months, because that assumed that during the first three months the tester would be learning. That same team expected no meaningful value from a new tester hire for the first six weeks. That translates into a mid-five-figure investment just to get started.

The true cost of onboarding is substantially higher than 13.4 percent. The Ivey Business Journal estimates the cost of a replacing a single employee, in both excess dollars and productivity, at up to 150 percent of an employee's annual salary. That means the process of losing one tester and getting a replacement could cost as much as one and a half years of employee value.

It gets worse, though, due to the flow theory. Imagine your software development organization is a perfectly balanced machine, capable of delivering 200 points per week while moving through requirements, development, test, and delivery. While losing one tester out of five causes a 20 percent drop in productivity, unless the team is willing to flex to cover the load (or have less coverage), a loss in test capability may slow down the delivery of the entire software team by 20 percent. The productivity or quality impact of a loss could be a lot more than 150 percent of one employee's salary.

Your actual impact from turnover depends on the context. Thanks to a recent restructuring by Microsoft, companies in Seattle, Washington won't struggle to recruit staff the way companies in Cleveland, Ohio, might, due mostly to hiring from Progressive Automotive Insurance. The best approximation of the cost to replace staff is likely based on your own context and experiences.

The most accurate way to look at the cost of replacing that next staff member, including ramp-up time and recruiting costs, is to base it on what it cost to replace the last one. There's no magic formula for that, but you can start with the total number of hours per week that anyone was working on the replacement, and multiply that by the number of weeks the role was open. Then take the total number of hours the person spent learning, plus coworkers' time spent training and answering questions. Add a bit of wasted time to cover flailing and struggling in situations where your previous, more experienced tester would have known the answer. Finally, figure out the number of weeks until the new hire is 75 percent effective at their position, then multiply the weeks times those hours, and add them together. Once you have that, multiply by hourly rate.

That's going to be a huge number, which is exactly my point. In my case, the conservative estimate of the cost of a recent placement for a client came to $34,000. In other words, that's what I would have saved had the client be able to retain that one tester for just one more year. With numbers like that, you can't afford not to try to reduce turnover.

Which brings me to how you can do so. Yaroch says that thinking about it as reducing turnover implies a sort of cold, detached approach to the problem. Instead of focusing on preventing turnover, he suggests taking care of testers—figuring out what they need, and providing it to them, so they won't go elsewhere to have their needs met. This means committing to a change of attitude and making an ongoing, concerted effort to keep testers happy and effective.

Keeping people on board: Care and feeding of technical staff

On a recent visit to Kitchener, Ontario, I spoke with three testers who'd all left the same company within a year of each other. When I asked why they left, I heard a few common themes, such as low salaries and unclear opportunities for advancement. One tester said he went to the company to learn and had a great time...right up until he stopped learning. Once he found he'd stopped learning, he found he had the skills he needed to get a new job.

The business gave him the training he needed to learn the job, but once he was fully on board, it offered nothing to keep him happy. The investment they made was wasted when he left for his next challenge.

Curiosity, which ties with learning, is one consistent character trait of a good software tester. Jerry Weinberg, author of Perfect Software: And Other Illusions About Testing, has defined testers as people who "imagine the world could be different," so it's no surprise that testers might leave when there's nothing more to learn.

Damian Synadinos, test manager at a large Midwestern bank, has been testing since the early '90s, including stints at CompuServe and NetJets. When I asked him the reasons he left previous jobs, he said one common thread ran between them all: the desire to make an impact. Without a visible impact, and without seeing customers benefiting from his work, Synadinos felt a bit like Charlie Chaplin in Modern Times—a cog in a giant machine.

My firm does a small amount of recruiting—we keep it to less than 10 percent of revenue. In the course of that work we talk to people, especially those who are looking and unhappy. In a few cases, candidates have offered to leave easy, secure, well-paying jobs—and take a pay cut—in order to learn, to make an impact, or to get away from a bad boss or a political situation. Those five items— learning, impact, opportunity for growth, manager, and politics—are recurring threads.

Rob Bowyer, a QA manager at eSolutions Group in Kitchener, Ontario, and Jess Lancaster, the QA practice manager at TechSmith Corp., both point out that a modest amount of turnover is natural. People do have children or go back to school, or their spouses get great job offers that force a move. These life events aren't bad things, so zero percent turnover shouldn't be your goal either. But getting turnover below national trends (currently around 11 percent) probably shouldn't be the goal either. Instead, look at why your people are leaving. Is it due to factors beyond your control, or is it because they want out?

Bowyer is quick to add another reason why testers want out: pay. While every interview for this article listed pay as a secondary concern, it's still a concern, especially for people who feel their pay is stagnant or below market average.

What to do about it

Most companies have a way to figure out the cause of an employee leaving: the exit interview. While exit interviews might be too late for the subject of the interview, sorting employee reasons for leaving into the buckets above, and adding a few more of your own, can help you recognize whether your organization is losing a one-off, overly ambitious employee, or if you have serious pay or opportunity problems.

Identifying the problem is the first step toward a fix. Perze Ababa, a software test manager with Johnson & Johnson (and before that, Viacom and The New York Times) offers staff 20 percent time one day a week during which they can pursue any work they think would be good for the company. With an average team size of 20, he has only lost three staff members over the past nine years, making for an annual turnover under two percent.

Hyland Software in Cleveland, Ohio, invests heavily in its employees, starting with several weeks of full-time training, followed by two more weeks of tester training. Employees who want to leave are likely to see job offers from other departments within Hyland, such as customer service, documentation, sales, and operations.

Large organizations can perform internal transfers to address the learning opportunity issue, and moving teams is another option. Michael Feathers, author of Working Effectively with Legacy Code, suggested at a recent presentation that teams consider a regular rotation to bring in new perspectives and to allow continued learning and growth, regardless of promotion or title change. This could look more like a merry-go-round than a hiring circuit, keeping employees at work without leaving positions unfilled or requiring recruiting firms.

Some turnover issues may be beyond your control. For example, one manager I spoke with said low pay had come up during multiple exit interviews, but that's not something he can change. What you can do is calculate the cost for every employee you've lost in the last few years, both in dollars wasted and total productivity lost. Then calculate the cost to resolve the issue, and you'll be ready to present your solution to senior management.

So the next time you're asked why a major project is late or why turnover is so high, you'll have the answer ready, along with a solution. Run the numbers, and you'll have something worth talking about.

Keep learning

Read more articles about: App Dev & TestingTesting