DEV Community

Cover image for Managing QA in Production
Kat Markava
Kat Markava

Posted on

Managing QA in Production

One can judge the maturity of the product by how stabile its production system is. But bugs happen, and having an efficient issue tracking and resolution flow is critical.

As a product manager, I see the need to be able to work with the QA closely and efficiently. This collaboration might be in part definitive of the the whole team's dynamic (I want to write more on this sometime).

Here's in short how we have it organized:

Logs - real-time monitoring tools may show that there is an issue. I like the level of usability on Rollbar or Kibana. Especially if their notifications integrate into Slack.

Customer Success - requests come from customers directly to the success team. They try to reproduce it, collect as many details as possible before informing the QA or handing it over to the engineering.

Daily Testing - QA team monitors automated daily tests that run in Selenium or does spot-check user tests and discovery.

Customer Surveys- alert about unknown problems, mostly with the user experience.

So once the issue is reported, the QA needs to follow these steps:

1. Verify:

  • reproduce the issue to make sure it was really an issue

2. Categorize:

  • Is it a newly 'Discovered' issue?
  • Is it an old one that's 'Happened' again?
  • Is it something that was 'Designed' this way, but turned out to be a clunky experience?

3. Prioritize:

  • after step 1 and 2, get together with the product manager and/or engineer to discuss the severity and the need to escalate.

IF the issue is escalated then it's assigned to the engineer who is most familiar with this particular logic in the form of a ticket (we use Jira).
The hotfix is pushed as soon as possible to PROD and the users who experienced the issue are informed about the resolution.

IF the issue is NOT escalated then the additional data goes into the QA tracking board where it lives until it's escalated or prioritized later in the development cycles.

In the early days of a young product, the role of the QA is often overlooked. Everyone does testing and debugging. Which is ok to a certain point.

As the product scales and the team grows, however, what I found to be the most important part of the process, is having the dedicated QA person. The person who has this strong sense of ownership and is passionate about the system doing its best to support the customers through their journey. Without that passion, things become much more complicated and even dangerous.

Top comments (0)