Who Should Own QA?

If you’re starting from zero with QA, the critical question to answer is, “Who should own Quality?” Rainforest has spent years working with hundreds of organizations of varying sizes. As a result, we’ve seen QA done well and also badly. It’s our hope that with this article, you can learn from our observations.

The “right” ownership model varies by company. Rather than prescribe, this article explores:

The standard ownership models—pros and cons, as well as things to consider before adopting them.
How to select or hire the right individuals to own QA.
How to develop a Culture of Quality, which is a requirement for success in any ownership model.

Where Should Quality Live in Your Organization?

QA-Owned Quality

Strengths

Optimization through division of labor and specialization. Effective QA requires a specific skillset and mental wiring. This is not to say that other role types don’t. In fact, we’ve seen many people successfully transition into QA roles. Nevertheless, there’s less risk in having someone with a strong background own QA.
Responsibility and ownership. Since team members are responsible, there’s a low risk of priorities or incentives misalignment.

Challenges

Cost. For smaller organizations, it might be difficult to justify the expense of a full-time QA hire.
The wrong profile. The first QA hire is fundamental. We often find leaders without QA experience optimizing for cheap labor by hiring a junior QA person. Doing so can lead to problems down the line.

The first QA hire is a strategic role. The owner must lay the foundation of a scalable QA process. This often involves technical tasks and working cross-functionally to develop solid Quality practices. They must have proven ability to influence others in the organization, and they must have experience with execution. Depending on the needs of your company, technical expertise might be required. The right profile is typically a tenured individual contributor with strong interpersonal skills.

Developer-Owned Quality

Strengths

Motivated to build a codebase they’re proud of. The worst code is the most difficult to test, so when engineering owns QA, you encourage clean building practices.
Culture. If you’re successful in this model, you already have a great Culture of Quality. The people building the software are themselves responsible. Some of the organizations that are the most fanatical about Quality are those where the developers own QA.

Challenges

Underestimating time and effort. If you don’t have specialization in a subject, it’s not uncommon to minimize the amount of work there is to be done. We often see leadership teams adopt this model to save money. “We don’t need to hire QA. Let’s have our devs do it. This is the best deal ever!” But the work doesn’t go away—it’s just redistributed. And this needs to be considered when doing capacity planning and giving out assignments. Factor into your planning the time your developers must spend on QA.
Too close to the code. We often see developers struggle to pull themselves out of the depths of “how it works” and into the mindset of how users interact with the software. Training is essential. QA is a different mindset, and you must invest in tools and training to set up the team for success.

Product-Owned Quality

Strengths

Product and user knowledge. Product owners understand their product and how customers use it. This knowledge helps with test scenario development, which is often difficult for developers.

Challenges

Competing priorities and responsibilities. A product owner tends to wear many hats and gets a lot of pressure from the business teams. Unfortunately, when it comes to prioritization, QA falls to the bottom of the list and is often neglected altogether.
Test suite maintenance and ownership. Due to lack of time and competing priorities, we’ve found that product folks have difficulty maintaining test suites. They tend to add tests without taking time to prune and maintain.

Which Individual Should Own Quality?

Once you’ve determined where it makes sense for Quality to live in your organization, you must decide which individual “owns” it. Someone internal or an external hire?

We suggest thinking about it this way: when starting from scratch, QA is a program. However, once established, QA develops into a process that can be repeated and built on. So, whoever is chosen to own Quality starts off as your Program Manager. Therefore, they must have the right skills, traits, and structures to drive a strategic program to success.

Quality Champion. Quite obviously, this person must care about Quality and have the enthusiasm and interest to champion it within your organization. Most people are not passionate about QA for the sake of it. But maybe there’s a front-end engineer with a passion for customer experience and the energy and drive you need.
Executive-level sponsorship. Quality is vital to your organization; if it wasn’t, you wouldn’t be reading this article. To set up any strategic program for success, you must have executive-level sponsorship. The owner must have the backing of an executive, who can help drive buy-in across the organization and unblock when necessary. Conversely, the owner is accountable for goals and reporting on progress to the sponsor.
Strong interpersonal skills and the ability to establish cross-functional relationships. QA activities span across teams. In addition, your QA program requires buy-in from your stakeholders to be successful. Therefore, the owner must have the ability to influence, negotiate for resources at times (especially if they’re non-technical), and maintain stakeholder engagement.
Strategic, long-term visionary. Like any business problem, improving your app quality requires significant time and effort. The owner can take one of two approaches: they can put in minimal thought upfront and iterate later, or they can put in more thought up-front to cut down on the amount of iteration.

Let’s illustrate with the simplest example: building an initial test suite. A strategic owner thinks critically, prioritizes, and builds a small test suite that provides maximum value. Then, they can continue to build over time.

By contrast, a nonstrategic owner may skip planning entirely and just dive into writing tests, building a large suite that provides little value.

For a lean organization, it’s important to choose an owner who thinks strategically and invests your most precious resource—time—in ways that yield maximum return.

A Culture of Quality Is Required for Success with Any Model

With the right incentives, training, expectations, and a strong owner in place, you can succeed with any ownership model. However, a Culture of Quality is a prerequisite.

How Do You Know When You Have It?

Executive-level accountability. At larger companies, you see titles such as Head of Quality, Director of Quality, and Chief Quality Officer. At smaller organizations, you don’t see that same role. Still, QA is the direct responsibility of at least one leader, usually an engineering lead.
Quality discussed at every stage. Quality is thought about at every stage in the process—whether that’s story definition, how you do code reviews, or how you engage with your clients. So, it’s making quality a part of the conversation at every stage, and the people working on QA have to be at the table.
QA goals/performance metrics. Measuring and reporting on Quality internally is essential to create performance metrics, transparency, and accountability. Quality is so subjective, and without clearly defined goals and performance metrics, you run the risk of varying definitions of Quality between developers, Quality owners, and the leadership team. Reporting on performance metrics drives organizational understanding and buy-in.

How Do You Know When You Don’t Have It?

If you don’t know where you are, how can you figure out where you want to go? If you don’t measure quality somehow, then it’s probably not part of the culture.

There’s no leadership or development presence.
Quality is an afterthought, or it’s thrown in at the end of development.
There are no defined QA goals or measurements.

If you don’t have it, how do you build it?
If you’re a part of an organization with a Culture of Quality, then you’re one of the lucky ones. If you’re not, don’t worry. Quality culture is made, not born. The most common blockers are addressable through deliberate action and time.

Leadership not bought in.
This is quite honestly the hardest to address. You need to have at least one executive sponsor for your quality program, whether a Director of Product or the CTO. The challenge is that QA is one of those functions that if all is going well, you don’t hear about it, so the impact of QA may not be apparent to your executive team.

To get buy-in, create executive-level visibility into how QA activities affect top-line and bottom-line metrics. For example, how much money are we making and how much are we saving? Solidify leadership buy-in by developing a practice of reporting on Quality’s relationship to revenue and cost. A monetary impact of bugs caught is an excellent place to start.

Individual contributors are not bought in.
Most commonly, the struggle is to get developers bought in to Quality, so we’ll speak to that as an example.

We’ve seen that developers don’t like to do QA; very few are excited by it. Given that, we have to understand what motivates developers, or anyone really, to own quality. Generally, developers own it out of responsibility (they’re told to do so) or out of pride (they’re proud of the work they deliver).

Therefore, we must motivate them to own Quality through pride and enforce it through responsibility. This doesn’t happen overnight; it takes time and deliberate interactions for everyone to understand that their reputation is at stake if the quality of their work isn’t good enough. Then there is enforcement. Leaders need to set and enforce goals to ensure developers take quality seriously, and have consequences for when they don’t.

”Ultimately, my best developer will be penalized if the quality of their work isn’t good enough. They could have invented something big, but if the quality of their work isn’t hitting the bar, innovation doesn’t matter.” —Rainforest COO Derek Choy

Lastly, leaders need to make sure that they support their team with training, tools, etc. When they make assignments, they need to make sure engineers have sufficient time to work on quality. All of this ensures that the team is empowered to own quality. So, to conclude, build a culture that promotes intrinsic motivation with external reinforcement.

If you have any questions, reach out to us at [email protected].