There Are 349,140 Software Testers in the U.S.

EddieC 0 Tallied Votes 556 Views Share

Two weeks ago I was asked a question to which, given my occupation, I should have known the answer. The question was: “How many software testers are there?” Being editor of a magazine about software testing, that's a number I should have know cold. At the time, I offered an estimate of about 250,000. A wild guess, really; I had no idea.

As it turns out, it wasn’t all that wild. According to the U.S. Bureau of Labor Statistics for 2007, the latest year for which data is available, there were 349,140 people in the United States doing that job. The government says these people: “Research, design, develop, and test operating systems-level software, compilers, and network distribution software for medical, industrial, military, communications, aerospace, business, scientific, and general computing applications. Set operational specifications and formulate and analyze software requirements. Apply principles and techniques of computer science, engineering, and mathematical analysis.”

To all you software testers out there, does that sound anything like what you do? My guess is that it probably does. There are other similar jobs listed under the broad heading of “Computer and Mathematical Occupations,” but none included “software testing” in their description except “computer software engineers, systems software,” the job described above.

Of course, “” (of which there were 394,710), and “computer software engineers, applications” (with 495,810 people counted) probably do lots of software testing too. And as agile and test-driven development become more widespread, the number of those people will continue to grow.

That's a good thing, and will lead to better software. “Look at how often projects fail. That data has not moved," said Thomas Murphy, research analyst with Gartner. "Companies get cranky about cost, but don’t do anything to fix it.” But an increase in use of agile methods has changed people’s thinking when it comes to quality. “They have a more quality-focused system, they focus on post-mortums, learn from past mistakes and pick up on best practices and metrics. Now they look back and say ‘how are we going to improve and do a better job?’”

What it comes right down to, he said, is finding the right balance between maximizing the quality of your product (and ROI) while minimizing the risk. And isn’t that the case with most things?

Dani AI

Generated

As notes, a headline number is interesting but tells only part of the story. “Tester” is a fuzzy label: some organizations have dedicated QA teams, others distribute testing across developers, SDETs, DevOps and contractors. That makes simple headcounts misleading. For practical decisions — staffing, budgeting or career planning — it is more useful to measure testing effort and outcomes than to chase a single national number.

A short, repeatable way to capture testing capacity inside an organization is to build a team-level roster and record testing effort. Useful fields for a spreadsheet include:

  • Team
  • Role / job title
  • Employment type (FT / PT / contractor)
  • Percent of time spent on testing
  • Automation owner? (Y/N)
  • Primary tools
  • Notes (responsibilities, shared duties)

Summing the “percent of time” column produces testing FTEs that reflect real effort, not just job titles. Make sure to include developers who do test automation or pair-testing, plus contractors and support teams that perform acceptance or ops testing.

Headcount or FTE should be paired with outcome metrics rather than used alone. Relevant metrics: defect escape rate to production, mean time to detect/fix, percent of critical user flows covered by automated tests, and release cycle time. Use trends and impact on customer-facing defects to justify changes in staffing or automation investment — avoid raw ratios without context.

With agile and TDD practices, testing roles shift toward automation, test design, environment and data management, and quality coaching. For organizations reporting tester numbers, a consistent, repeatable definition (for example “roles spending >= 50% time on testing”) makes historical comparisons meaningful and avoids undercounting testers embedded in development teams.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.