[Evgeniy2020]

ZBB what? This stands for Zero Bug Bounce, or as alternately phrased, Zero Bug Backlog. At this point we have been logging, tracking and verifying all changes to the product in great detail for some time – collectively we refer to this list of logged issues as the “bug list”, though in reality it includes a variety of issues including bug/defect reports, tracking records for artwork or content, usability improvements, numerous suggestions (submitted by team members or beta testers, or representing customer or partner requests), and various other categories of issues.

The ZBB milestone is defined as the date across which we will no longer carry logged product issues that are more than one week old. Hence, the “backlog” of issues has been cleared out, and all older pending decisions on what we are or are not going to change before we ship have been made. It also means that the developers have “caught up” or “outpaced” the incoming find rate of our test efforts.

From here on out, the focus is increasingly on lock down. We are testing for defects literally around the clock, using a variety of methods ranging from automated efforts such as “massive file testing” to targeted manual test passes and “ad hoc” free testing. We also continue to log and fix significant issues found in private beta testing. At this point we remain busy fixing bugs as they are found (any one of our millions of lines of code could be the source of a defect,) but there will now be increased scrutiny on making changes – i.e., is there sufficient customer need to justify a proposed code change given the associated risk of regression (the outside chance that making a given change causes a new and potentially more severe problem.) Stabilizing the product for release requires conscious commitment to slowing and eventually stopping the changes we’re making to it, and as a result we now start reviewing all proposed changes daily in “triage”.