Getting to Done

Getting to "Done"

Unlike during a Build Track where testing focuses on assessing a solution against what was specified, a Stabilize Track readies a solution from a more subjective perspective (e.g., usability, end-user acceptance, and stakeholder expectations) as well as from more classic, measured approaches such as functional testing and system testing. Unlike classic testing, which usually has defined test cases, subjective testing presents a challenge to know when the team has sufficiently stabilized a solution (i.e., when they are done). For example, how does a team quantify usability to know when a solution is sufficiently usable? Especially with subjective testing, everyone having a fixed ship date mindset clearly helps getting to done.

What Is Done?

Lead Advocacy Group: Product Management

Being done means a solution and all of its supporting elements satisfy their respective release criteria and have been signed off by users and stakeholders. It is critical that release criteria are clear and quantifiable so as to not under- or overdeliver. These criteria should be defined within their respective project plans for each aspect of solution delivery. A team needs to be able to track and report on all criteria throughout a Stabilize Track (and hopefully as early as Build Track testing).

Often overshadowed by completing a solution, being done includes completing the various supporting elements, such as finalizing training; hosting launch events; finalizing end-user communications announcing what, why, and when it is happening; training operations and support teams; and finalizing user and operations documentation.

Predicting Done

Lead Advocacy Group: Test

Early during this track, it is common for testing to report issues at a rate faster than the team is able to resolve them. There is no way to tell how many issues there will be or how long it will take to resolve them. There are, however, statistical indicators such as issue convergence and issue log cleared that help the team estimate when a solution will achieve defined release criteria.

With the end-state criteria clearly understood, a team needs effective techniques to make accurate predictions confidently as to the current stability status of a solution and when a solution is likely to satisfy its release criteria. This is accomplished using various techniques such as trend analysis supported by a set of trusted metrics and indicators. Many books are written on this topic; here is just a sample of useful quality indicators commonly tracked:

• Rate of issues identified vs. rate of issues resolved

• Percentage of solution revisited

• Percentage of test cases passed

• Percentage of scenarios tested

• Percent coverage

• Number of issues found per solution component