At What Point Should Product Involve QA?

My current company is the first where I’ve been able to actually be impactful with QA process and helping to create something from scratch – that’s the joy of a startup. They’re scary as hell to join, but if you find a good one, one you believe in that also believes in you, it’s amazing what you can accomplish. Everyone in the company has the same goal for releases – a quality product with minimal (or preferably no) bugs. But, with everyone having such different responsibilities that all affect the end goal, how do we align and work together?

Product has a huge responsibility, and the PMs that rock are seriously the best. You don’t always end up working with a seasoned PM though, and even seasoned ones may not involve QA in a way that utilizes them to their full potential, cutting down on the back and forth later on. So, where does QA fit in with Product?

I feel like we fit in after the initial idea has formed and PMs have researched enough to be able to answer questions. For example, I am on this huge feature at my work, Bill Pay. I was the first and only QA on it until it launched. At the beginning, Product was wanting to talk to me about the concept with no designs or much of an idea of what V1, V2, V3,  etc would be. That was…overwhelming. I ended up so confused about what was happening at which point, what the expectations were for launch, all of the unknowns that there were no answers for and path a, b, or c that we could take but didn’t have a plan on which we were doing, etc. In an effort to help, I was brought in way too early which resulted in more back and forth, rather than minimizing that.

Later on, when Bill Pay had turned from just an idea to when it was ready to get started with designs I was brought in. Bringing QA in then was perfect. The whole squad met together – PM, Devs, UX, QA and talked about bill pay, V1. We white boarded our ideas, the flow we pictured, our questions and concerns. When we left that meeting we had a clear idea of what the plan was for V1, as well as what our concerns were as far as blockers for devs, things that needed research from UX, and testing concerns from QA. The best part? No development had been done, so I wasn’t seeing this all for the first time when it was time to test, then raising all of my questions. Every time I’m brought in later it inevitably ends up with something needing to be changed, devs disgruntled that it didn’t come up sooner and annoyed at having to redo work, QA upset about not being involved and all of the time wasted when a 5 minute conversation could have prevented it in the first place, UX scrambling to get everyone updated designs, and PMs stressed about not meeting deadlines.

Honestly, so many issues would be solved if QA were brought in sooner, and involved long before designs were complete and devs had started developing. The relationship with QA and product is also so, so important. They need to be able to trust that QA will do their job, test well, think of edge cases, understand risk, voice concerns, and push for quality. QA needs to trust that PMs will help un-block, provide answers to our questions, communicate accurately with the business and agree to realistic deadlines. By all of us working together earlier and striving to understand what goes into each other’s jobs we can alleviate so much stress and really function as a team.

 

Leave a reply:

Your email address will not be published.

Site Footer