Agile Insider
Published in

Agile Insider

How product managers can collaborate better with the QA team

Photo by Lucas Vasques on Unsplash

Key Problems faced by Product and QA team

  1. Obvious corner cases getting missed during design and development phase.
  2. Lack of clarity: At times, the QA team is not on the same page as product on how the feature is expected to work in certain situations.
  3. Conflicting Priorities: The QA team’s end goal is to ship to a quality, bug-free product. The product and engineering team’s often work with the “ship it asap” type of mentality. This creates bad blood between different stakeholders.
  4. Miscommunication: Often, there is a gap between what the PM or Engineering intended to say and what the QA team interpreted. This leads to a lot of back and forth.
  5. Unrealistic Timelines: Due to deadline pressures and last minute deployments by engineering, the QA team often has to stretch late in the night to test things. If corner cases get missed, then blame comes on the QA team.

Key Principles to Adopt

In order to avoid the above problems, I would suggest to start with internalizing the following principles:

  1. Shared Responsibility: Thinking about edge cases and failure scenarios is not just the QA team’s responsibility. Product and engineering are equally responsible.
  2. Advance Planning: Thinking through corner cases in advance is a better investment than resolving them while QA is reporting it during testing.
  3. Learner’s mindset: Learn from every feature that you ship and strive to make continuous improvement.
  4. Slight delay in shipping is acceptable but poor user experience is not.
  5. Keep Calm: Focus on resolving issues and improving processes rather than playing the blame game.

Techniques to resolve the above problems

With each feature shipped, I keep getting useful insights on how to make the QA team’s life easier. Following is a brief overview of the techniques I have adopted to make everyone’s life easier:

1. Preventing crucial misses

  • Use a corner case checklist to document the initial set of edge cases and expected behaviors in the first draft of your PRD.
  • Having an Acceptance Criteria section in the PRD is a must. It covers all the major scenarios and cases that developer needs to get working before handover to QA. This is a living section of the PRD that you need to keep on updating based on new information that comes and new decisions that are made.

2. Better communication with QA

  • While handing over the PRD to engineering for development, involve the QA team as well. QA team generally comes up with the scenarios which you haven’t thought of. Expected behaviour in these scenarios should be added to the PRD (Acceptance Criteria section).
  • Document whatever decisions are made while discussing implementation with tech. I always provide written updates regarding any decisions that affect how a feature works or a scenario is handled.
  • Review the test cases sheet shared by QA and weed out any tests that might reflect an incorrect understanding of things.

3. Meeting the timelines

The above techniques would have a direct impact on the time it takes for QA to finish the testing. Following are some additional steps you can follow:

  • Test cases sheet to be created and provide by QA in advance before the feature is completed by the developer.
  • The developer must ensure that every scenario mentioned in the Acceptance Criteria and test cases sheet is verified before QA handover. This helps reduce the chance of the QA team reporting obvious bugs. (A separate column called ‘Dev Testing status’ can be created in the sheet. The developer needs to mark it complete before handing it over to QA.)
  • Proper scoping out — If the feature is too big, break it down into versions. Features which are too large take up so much time during testing that the team’s motivation to ship it fast nosedives as time progresses.
  • Do a round of testing (UAT) with the designer and developer before handing over to QA for testing. This helps cover usability and UI related issues, which otherwise come to bite you just before the release.
  • Release cut-off date. If the release is scheduled for Date X, then the cut-off for the release branch should be X — 1.5 days, so that the QA team has enough time to do the final round of regression testing.

4. Mastering the art of bug prioritization

The last 10% part of any project is always the hardest.

5. Post release retrospective

The only way to get better is to learn from your past mistakes. As you ship features one after the other, keep thinking about ways to improve velocity of delivery and make the life of the QA team easier.

  • New questions that you could add to the corner cases checklist.
  • If some bug took long to get fixed, understand from engineering what went wrong. Was the bug avoidable? Do we need a rethink on the particular piece of code?
  • If some obvious bugs were discovered just before release, understand why they weren’t handled earlier? What would need to be done to discover them earlier?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Vikram Goyal

Currently PM@Airmeet — building a kick-ass product for conducting remote events and conferences.