The Tester as Product Owner
A few years ago I worked on a system that processed packets of paperwork for printing. In a requirements meeting, the customer said, “When packets have condition A, they always go to error.”
“Always,” in that case, was what Jerry Weinberg might call a lullaby word: a term that puts our risk management senses to sleep. I pushed back: “Always?” Yes, always, was the response, and we implemented the feature.
You guessed it: There were hidden conditions when packets shouldn’t error. If they were “fixed” and reprocessed, the calculated run values were still in place, and the packets would error again, leading to an infinite loop—even though the to-be-printed values were now correct.
It was a tricky bug because it was not the consequence of any one feature, but of two features put together. Condition one for requirement A, plus condition eleven for requirement F, combined to make software that didn’t work—because no one really thought of the consequences.
In a way, that’s testing’s little secret: A lot of what we find as “bugs” were never thought through in the first place. Sometimes, like in the case above, the software is behaving as specified, just there was some sort of error in the specifications. Sometimes the product manager never really considered that case at all, and the programmers did what made sense to them. Other times there was a genuine misunderstanding of what to build. In any case, many of these situations are preventable.
Yet instead of prevention, we get the tester playing the role of the product owner—and playing it late. We build the whole thing, and then the tester looks at it and, playing the role of product owner, says, “Nope, that isn’t right.” Arguments and handoffs may happen, but eventually, the organization agrees and we build it twice.
Why is it that we never have time to do it right, but we always have time to do it over?
Moving Forward
The observation that good testing and good product management skills overlap is not just my own. Michael Bolton once told me that his old company viewed testing as a promotion path to product management. Matt Barcomb has been suggesting that the next move for context-driven testing is to move toward context-driven product development, and for the tester role to evolve toward defining the product.
We’ve been trying to get testers involved up front for decades, but typically through reviews and inspections that slowed down the process without adding much value. Agile approaches like The Three Amigos have finally made upfront involvement real in the past few years.
Despite all that progress, I suspect that few people see the true amount of opportunity. They don’t realize just how often we’re all “doing it twice,” nor how often the tester is playing the junior product owner.
My goal here was to get those two ideas out there, and to start a conversation about what to do about them. Let’s keep talking.
