QA Structures for Product Managers

Many product organizations have a quality assurance (QA) team to ensure that their products function as expected. As a product manager, you’ll regularly work with different QA structures across the course of your career.

Some QA teams are embedded within engineering, some QA teams are embedded within the product team, and some QA teams are standalone teams that serve as a support function.

But at the end of the day, ownership over product quality belongs to the product manager! QA simply helps to reduce the burden of having to test everything yourself.

So, let’s discuss the different QA reporting structures that you might run into, as well as how to identify which QA structures and processes make the most sense for you and your team’s needs.

Different QA Reporting Structures

The way that you interact with QA depends heavily on how your QA team is structured within the rest of your organization. Here are some of the most common structures.

Separate QA team

Some organizations – especially larger, more mature organizations – have created dedicated QA departments for tackling the work of testing. The value of dedicated QA teams is that QAs can specialize in focusing on quality. They can assemble a battery of manual test cases that checks across various products, and they can also automate test cases to ensure that any new code that’s released doesn’t cause a blocker.

The value of dedicated QA teams is that these QAs have a fresh set of eyes. When engineers or product managers self-QA, they may forget about particular edge cases that they need to check for. Dedicated QAs won’t miss those kinds of details!

QA team embedded in engineering

Other organizations might embed QA within the engineering team itself, since engineering is at the forefront of the features being released. These kinds of QAs have the same reporting structure that engineers do, and attend the same standups, meetings, and kickoffs.

The benefit of having QAs be embedded in engineering is that testers have more insight into what’s being released, what’s changed, timelines, etc. Plus, these kinds of QAs will have a much deeper understanding of the tech stack, which means that they’ll be able to write effective test automation that appropriately checks across the various codebases that make up the product.

No QA teams at all

Some organizations may decide not to have QA as an individual function at all. These kinds of organizations tend to be much smaller, and typically prioritize speed and cost-efficiency.

For these kinds of organizations, engineers are responsible for their own testing, and they must pass a major set of unit tests before any code makes it to production as part of testing best practices. And, product managers are responsible for testing their own features and the cross-interactions with other features.

When support and customer success are then trained on the new product release, they’ll flag any missed issues and call out any place where there’s insufficient documentation.

Which QA Reporting Structure Should I Use?

Any software company lives and dies by the quality of its product offering. A shoddy product that regularly breaks is one that people will refuse to use in the long run. Therefore, testing is critical, no matter who performs the testing.

The key question that appears as teams scale is, “who should own testing?” In small organizations, there may not be enough money to afford a dedicated QA resource.

Therefore, while engineers should write unit tests as part of good development hygiene, product managers are the ones who must own the end-to-end quality of the product at this scale.

Then, as companies scale, they are able to hire dedicated testers to focus on testing. At this point, multiple approaches can work, depending on company culture, departmental structure, and product complexity. Testers may either be part of engineering, part of product, or remain as a standalone department.

In some cases, testers are in charge of just manual testing. In other cases, the QA team is also in charge of automating testing and creating testing best practices to ensure that all stakeholders are aligned.

Establishing Testing Processes

Generally speaking, testing depends on the size of the release.

For example, a visual change wouldn’t need to involve engineering, and a copy update could be validated by customer success.

On the other hand, if you’re tackling a significant feature, you’ll need to involve everyone: engineering, product, design, customer success, and users (in that order).

To implement cross-functional testing processes, make it clear to each group about what should be tested at each stage, both from a holistic level and from a specific user flow.

That is, the feature itself should be tested, but each tester should also spend some time within the larger product itself to look for any unexpected interactions.

Provide user stories as part of testing best practices. After all, if you’re working with a separate QA department with dedicated team members, you’ll want to ensure that they can devote time to fleshing out these user stories so that they can develop their own test cases and create a system around testing best practices.

Summary

No matter what, product quality is critical to success. By considering the various approaches above, you’ll strengthen the quality of your product, and therefore strengthen the health of your company!