I remember the cold sweat forming behind my ears the first time a stakeholder asked me, “What’s the Test Plan?” I had no idea. As a new product manager, I had put most of my energy into defining requirements. Without a Quality Assurance team in place, testing became an afterthought – one I didn’t really know how to handle and which frankly gave me a lot of anxiety.

It turns out my experience was not entirely unique. QA is consistently ignored as part of the development process. According to a 2018 State of Testing survey by Practitest, QA testers reported “communicating the value of testing to the organization” as one of the challenges they face most frequently on the job. If QA experts are constantly explaining the importance of their job to their teammates and employers, that’s a red flag. As the product manager leading the product’s vision and execution, gaining a better understanding of how to collaborate with the QA team has become essential to developing and launching products.

RELATED CONTENT: Testing all the time

The QA team is an integral part of the development process. They can catch problems before they happen, raise issues no one else has considered and help the product manager understand the risks of the project. But first, you  — the product manager — must be proactive about reaching out to your QA compatriots and making them partners in the development process.

Here are five tips I wish I’d known earlier and that I consistently continue to work on to ensure a strong partnership with QA. Even if there isn’t a strong QA presence in your company, I hope these tips help build a framework for items you should think about in during product release cycles.

#1: Clear and accurate acceptance criteria is important

We’ve all been there – a rushed user story amounts to poor requirements and anemic acceptance criteria. This is a reminder that the stronger our acceptance criteria, the more clarity developers and QA team members have to do their best work.

Clarity is key when it comes to writing acceptance criteria. The QA team is the first step between you and real end users; if they are confused about something in your user stories, your customers will be too. At the epic level, you’ll want your criteria to outline a concrete expected end to the user journey. At the story level, think about writing your acceptance criteria in BDD (Behavior-Driven Development) format. This type of format challenges you to break down your features into testable chunks.

In some organizations, acceptance criteria also becomes the basis for your release notes, so it is important to be clear about what your story covers and what it does not.

#2: Include QA at the beginning of the process

I’m not sure if anyone is still touting QA as something that happens at the end of the development process…and thank goodness for that. In some organizations, we actually see that paradigm flipping on its head; representatives from product, design, development and QA create the test plan together at the beginning. Working in unison helps to find the critical paths and workflows that will require the most thought and attention.

Having the QA team’s input early in development is helpful in another way. It is this team’s job to see things others don’t and to ask the difficult questions – especially around edge cases. QA can also tell team members what they’ll be looking for during testing. This helps identify dependencies that aren’t visible to the rest of the team, which is invaluable when it comes to refining requirements.

#3: Let QA accentuate the negative

My product management personality tends toward the optimistic. I spend so much of my time extolling the virtues of the product that I often fail to see where things can go wrong. Working with the QA team gives me a healthy reality check. Because their job is to find problems, QA teams have a pretty good idea about where the bumps in the road are likely to lie. Leaning on their expertise, we work together to define edge cases that are not always considered in my initial requirements gathering.

I once worked on an enhancement to a feature on an existing product. I was really excited about what this enhancement could bring for usability but I neglected to understand exactly how deep the tendrils of the existing feature reached into the product. The QA team’s help in thinking through the edge cases saved the day. They were able to map out the different possibilities early on so we could make appropriate design and product decisions as a result.

#4: Understand the QA Mindset

Don’t treat the QA team as a gate holding back your release! Involve QA at the beginning of the project and work together to define:

  •     What success looks like for this release: What does the team want to achieve? What do both groups consider a win?
  •     The risks of the release: What is acceptable to your team? What’s a hard pass?
  •     Your key metrics: What KPIs are you tracking? Is it test coverage, number of bugs or something else entirely?

#5: Help the QA and development team prioritize what gets automated

It’s tempting to want to automate all QA, or to let the QA team decide which tests are automated, but you should have a say in the priorities.

As the voice of the customer, use your knowledge of what is important to users and what is not. It is your job to convey this information to your QA team. The priorities will help define the boundaries of testing and let QA members know where to focus their attention. Automate the paths that are most used and least likely to change over time. As the product grows, continue to assess the risk of the releases – what components of the product are most likely to break and what can you put in place to prevent that from happening?

Plan testing early!

The best teams build testing into their development process. If you think proactively about QA and work closely with your QA team, they’re likely to spot problems before they happen. If you don’t, QA will be catching problems at the end of development, when they’re harder (and more expensive) to fix. This approach will leave you spending many more moments with cold sweat behind your ears trying to figure out what to do with your test plan.

By developing relationships with QA engineers and managers early on, and incorporating QA into product requirements discussions, you’re setting yourself — and your product — up for success.