Who Should Run Tests? On the Future of QA

A basic question as we look at shifting testing left, as we put more testing responsibility with the product teams, is what the role of QA should be in this new arrangement. This can be generalized as “who should own tests?” Microsoft retired its “dedicated software engineer in test” (SDET) position in 2014, while Apple and Amazon retain a high focus on dedicated QA. If the FAANG companies can’t decide whether we need dedicated QA roles, how can the rest of us answer the question?

Let’s explore how QA’s role grows in a world where testing is shifting left.

QA Has Long Been a Victim of Trends, but QA Continues

In my first technical role at New Relic, I was meeting all the engineering teams who wrote APM (application performance management) agents for the major web development languages. Each team had a similar makeup, but I asked, “Who’s the QA person on the Ruby team?”

“There isn’t one,” The head of the Ruby team replied. “Rails doesn’t require QA.”

That team’s hubris can be forgiven: There’s never a new hot language on the scene without someone insisting that it solves every known software problem, and makes bugs, failures and unexpected behavior impossible. However this conversation led me to a more general principle: Some would always see QA as an embarrassing thing to need, meaning some teams would proudly proclaim that they no longer needed people dedicated to testing.

In the decade since this conversation, it’s become clear that no language or framework is free from the need for testing. That work can be highly distributed, with every single engineer doing their best to write tests, run them and interpret the results. Alternately, the work can be centralized, with a selected few running a compendious set of tests on every release.

There Was Never a Time When Developers Didn’t Run Tests

“Back in the day, QA was responsible for running all the tests and developers just wrote code.” This was never true. Since the era of groundbreaking figures like know how to run high-quality tests — is that QA ends up doing more, not less. The work that QA does becomes more strategic, and has a greater effect on overall developer velocity. Things like:

• Coming up with the testing strategy


• Building testing frameworks


• Choosing the right testing tools


• Focusing on more complex end-to-end automation


• Shifting left and embedding themselves within product teams to enable earlier testing

As the need for development velocity and reliable deployments grows, QA will become more valuable than ever.

Join the Signadot Slack

At Signadot, we’re trying to make testing easier for every part of your software development life cycle. If you’re interested in hearing more, join us on Slack to meet our community.