4 Things Product Managers Should Know About QA& Testing

What Is QA & Testing

Quality assurance ensures that your software meets the technical requirements identified in the planning stage of your sprint. Generally speaking, it is an ongoing, preventative measure that occurs throughout your software development process.

Testing ensures that there are no bugs that could disrupt your software’s usability. Generally speaking, this is a corrective measure that happens at the end of each sprint.

While QA and testing are technically separate parts of the development process, us developers group them together because they have the same end goal: make a high-quality product.

While you probably don’t need to understand the finer details of QA and testing, there are a handful of helpfuls that can boost your effectiveness as a product manager.

Why You Should Care About QA & Testing

Imagine this common scenario.

Your development team finishes a new feature and pushes it to staging. You, responsible for this feature, review it on staging and since it seems to work, you sign off.

This feature gets pushed to prod, and soon after, an angry customer emails you, saying the key workflow they rely on doesn’t work. They threaten to switch to your competitor. You have a bad day.

You go to your development team, wondering how this could have happened.

I know how common this scenario is because I’ve lived through it many times. And it likely could have been prevented if everyone was on the same page about QA and testing.

Here are some of the most important things to understand about QA and testing.

Bugs Are Normal

Spoiler alert: There’s no such thing as “perfect, bug-free code.”

To compare this idea to a non-technical one, it is like saying, “If you never have a typo, then you won’t have to proofread.”

However, because bugs can lead to angry stakeholders and customers, they often have emotional baggage attached, especially for folks new to a role.

In other words, bugs stress people out.

In my opinion, the best strategy to counteract bugs is to normalize them. Bugs will happen. They’ll definitely happen during the development process and on staging, and in spite of your best efforts, they’ll happen in prod too.

You should strive for a, “us vs bugs” mentality. They are nobody’s fault, but there is room in your process for improvement. When you’re the point of contact for a potentially angry customer, it can be hard to keep this attitude, since the customer doesn’t agree with your sentiment that bugs are normal. I won’t pretend that’s easy or pleasant to deal with, but it’s your job to calm them down and not bring that emotional baggage into your organization.

Ownership Should Be Clear

When you have a bug in production, who’s at fault?

If it’s not clear, that’s not good.

There are many ways to organize your QA and testing process:

• Dedicated manual QA testers
• Business analysts performing QA
• Product managers performing QA
• Entirely automated test suites

Any of these setups can work well as long as there is a defined owner for every step of the process. That way, when something goes wrong, it’s clear what happened.

In our example scenario, one of two things need to happen:

1. A well-defined testing step needs to be added after step #1
2. The product manager should take ownership in step #2

It’s important to note that even with clear ownership, bugs can still get through. Treat these moments as a learning experience. Is there a test plan for this area of our application? Is it correct? Did they follow it?

If your organization is small, I recommend product managers taking responsibility for QA, at least temporarily. You will earn considerable goodwill from your developers.

Ensuring responsibilities are clear before there is an issue not only ensures that your final product is launched on budget and on time, it makes for a happy team.

Automate the Most Time-Consuming Parts First

Everyone wants a completely automated test suite. And it’s a great goal to work towards. But for most organizations, trying to automate every piece of the puzzle is unrealistic.

I recommend figuring out the highest impact piece and automating them first. Then add additional parts as time allows.

For example, if a customer complains that the key workflow they rely on is broken, it’s affecting everyone using that key workflow which impacts the core functionality of your application. Find those key pieces and get automated tests in place. Using end-to-end testing solutions like Cypress, Selenium, and Puppeteer can be a quick way to do this so that full unit and integration tests can come as time allows.

Once these high-impact tests are out of the way, you can focus on the secondary (but still important) tests.

Fully-Automated Flows are Great but Don’t Skip UAT

It’s your responsibility to delight your customers with your software. But no matter how automated your testing is or how good your development team is at requirements, you need to review your software before it goes in front of a customer.

This is where User acceptance testing (UAT) comes in.

UAT verifies that your software is actually solving your user’s problem. This testing is essential because users behave differently than automated tests. And since users, not bots, are going to be interacting with your software, it’s important (to say the least) that they can interact with it sans errors.

UAT requires real users to test your software before its officially released. While there’s no hard and fast rule about the duration of UAT, make sure that you give yourself adequate time to collect data and feedback.

Final Thoughts

Understanding how QA and testing happen in your organization and working towards an effective process will improve the quality of your product and the collaboration of your team.

Even if you don’t directly manage QA or think it’s your responsibility, think of it like looking both ways before crossing the street. Yes, it’s the bus’s duty to stop, but you’re the one getting hit if it doesn’t.