Last week, I was discussing the concept and process of software acceptance with a friend. He described the process he uses, carefully placing the Product Manager in the position of deciding when to go to market. He finished his point, and I asked him to clarify.
His belief is that the Product Manager, as the business leader in the organization, should be the one to pull the final trigger. Perhaps my background in Quality Assurance is what causes me to disagree, or maybe it’s just my egalitarian approach to life — but I have long believed that Quality Assurance gets to make that final call.
After talking it over with my friend, Steve Johnson of Under10, we realized that the answer truly depends on how the testing function is set up within your company.
Testers vs. Quality Assurance
Traditionally, testers got involved after the product was completed, forcing them to primarily focus on ensuring the product worked as designed. Testers aren’t necessarily given insight into how the product will be used; rather, they build test cases based on the design and specification. Testers live with a falsely constrained line of sight, and the product team expects them to stay within those tightly-defined borders.
When I was on a test team, I recognized this issue and tried to remedy it. I imagined how a user would interact with the software, and logged bugs based on their inability to complete their goals. This quickly evoked a strong negative response from the team. In fact, they reminded the testers that they were NOT designers, and therefore couldn’t log those bugs. Instead, we had to tag user-focused bugs as “working as designed”.
That reaction was hard for me to take, as I had a natural loyalty and affinity toward our users. During that phase, the testers banded together and secured some training from Cem Kaner, a thought leader in software testing. We collectively realized that we were not serving the company as well as we could in our currently assigned role. To truly increase quality, we needed to get involved earlier. We needed to start testing against user expectations, rather than testing against the spec.
The Benefit of Early Involvement
As we moved further upstream, our engineers realized that “testers” have a natural ability to spot problems BEFORE they’re coded. We regularly called attention to areas that might cause future issues for the user or the engineering team. We transformed our test organization into a Quality Assurance department.
From that point forward, responsibility for the release became the domain of Quality Assurance. They were closer to the current state of the product, and they understood the users’ needs at an intimate level.
After I moved into Product Management, Quality Assurance became my go-to resource. They always knew how close the product actually was to release, even over the weekend. If my QA lead told me the product was not ready, we did not release.
The final release decision…..it depends!
If their testers lack full line of sight from the product back to the market, the Product Manager should retain control over launch timing. If, however, the product has a Quality Assurance team, with a goal of understanding usage from the market’s perspective, then they are in the best position to decide when to launch.
Turns out, Steve and I are both right!