DEVOPSdigest

SmartBear recently released the results of its 2021 State of Software Quality | Testing survey, my personal favorite of the company's reports. While I do work for SmartBear, my interest in these non-product-promotional surveys is purely due to my fascination with the world of software quality, and the evolution we're seeing around who owns quality, the challenges that quality owners face, and what they feel will solve those challenges.

I don't feel too bad about revealing this spoiler, because I doubt you'll be surprised to hear that a "lack of time" was reported as the number one challenge to doing more testing, especially as release frequencies continue to increase. However, it was disheartening to see that a lack of time was also the number one response when we asked people to identify the biggest blocker to professional development.

We also asked respondents what testing activity is the most time-intensive task within the time they are able to dedicate to testing, and the number one answer was disheartening again.

23% of respondents reported that "writing manual test cases" is the biggest culprit.

Why is that disheartening?

I would argue that writing out test cases isn't actually testing. It's a testing-related activity, sure, and maybe even a necessary one.

But can you say that the single act of writing out test cases actually improves the quality of your software?

Would your customers say the same?

The second-place answer, coming in at only 1% less at 22% was "learning how to use test tools." Again, a necessary requirement and skill, but learning how to use a tool to test is not testing. What I find humorous, but not surprising at all, is that in this year's survey, we asked respondents for the number one quality they look for in API tooling.

What would you guess the number one answer was?

Most powerful features?

The latest AI/ML innovations?

Nope. "Ease of use."

One trend that's been interesting to observe — from within this survey and in the industry at large — is looking at who owns quality in an organization. In the past, it was largely, if not entirely, owned by manual QA teams. But today, quality owners possess any number of professional titles and backgrounds: manual or exploratory testers, automation engineers, SDETs, business analysts, DevOps teams, or probably the fastest growing group of quality owners — developers.

Even as an exploratory testing enthusiast myself, I'm thrilled to see developers share the responsibility of testing. However, one result that completely surprised me was finding out just how much time developers say they are spending on testing in an average week. Developers were one of the only roles to state that they're spending more time on testing in 2021 than they did in years' past and this percentage is increasing every year (automation engineers, manual testers, and business analysts all reported a decrease in 2021). Developers reported spending, on average, 47% of their week testing. What? Really?

Do developers want to spend nearly 50% of their week not developing new software? From all the testers I've ever spoken to, few would want to spend 50% of their week not testing. I won't be surprised at all to one day see every developer claim to also be a fellow quality owner like their tester counterparts, but at what percentage over 50% of a developer's week being taken up by testing do they simply become … a tester?

There's simply too much actual testing that needs to be done, too many accelerated release cadence goals to hit, and too many bugs to eliminate from the last release(!) to envision those who own software quality being able to continually deliver on our promises to customers. Not if we continue to struggle to spend time on what directly impacts our customers, because too much of our time is stuck doing what doesn't.