Keep Open Bug Counts Visible
The number of bugs found isn't always an assessment of quality. For example, low testing depth may return a low number of bugs, where high testing depth will likely return a higher number of bugs. Even with a low number of bugs, a subjective quality assessment could indicate low quality: "I didn't test much, but everything I tested was broken."
The team should know about all bugs and do their best to address them as quickly as they're found.
Will keeps the number of bugs found visible all the time by using a chart that looks similar to an agile burn chart. This two-dimensional chart uses number of known bugs for its vertical axis and time for its horizontal axis. Will publishes a new version of the chart every day and posts it on the wall in the team room. The chart shows a curve that increases slowly over time and lurches down every once in a while when the development team fixes the bugs in an effort to reduce the bug count. Keeping the total low has become a point of pride for the development team, which now reserves a couple days at the end of each development cycle to work on bugs. They don't want the cycle to end with a high bug count since they know this number is visible to all, and a high number of bugs will affect the testing team's quality assessment.
At release time, the product manager ultimately decides to ship or not, but at least the whole team is aware of the quality of the software being shipped. The decision to ship a product with a low level of testing and moderate quality would be a risky one, but now that risk is visible to all.