Key Checkpoints
| Key checkpoints consist of a major checkpoint for the track and a few interim checkpoints. Major CheckpointThe major checkpoint concluding a Stabilize Track is release readiness approved. Release Readiness ApprovedLead Advocacy Group: Test A release readiness approved checkpoint signifies that the stakeholders concur a solution is ready to be deployed. Before seeking stakeholder approval, the team addresses all outstanding issues, satisfies all solution release criteria, prepares Operations to take receipt of a solution, and validates that a solution satisfies the needs and expectations of the stakeholders. At this checkpoint, responsibility for ongoing management and support of a solution officially transfers from a project team to operations and support teams. It also signifies that a solution design and scope are frozen for this release. Interim CheckpointsThe interim checkpoints for a Stabilize Track, as depicted in Figure 10-1, in roughly the order expected are as follows:
Figure 10-1. Stabilize Track checkpoints Microsoft Solutions Framework (MSF) avoids alpha and beta checkpoints to describe the state of solution readiness. These terms are widely used, but are interpreted in too many different ways to be meaningful. Teams can use these terms if desired, as long as the terms are defined clearly and the definitions are understood among the team and stakeholders. 1st through nth Functional Testing Pass CompletedLead Advocacy Group: Test Unlike verification testing performed in a Build Track, functional testing assesses capability from a user-based activity perspectiveoften spanning across multiple solution components. For instance, a "create new user" test case looks at a solution from a user's perspective regardless of which solution components are involved. Functionality testing often starts as soon as enough completed solution components enable scenario or activity testing. A functional testing pass is one complete run through test cases that functionally test a solution. Often a few test passes (also called cycles) are needed to make sure there are no active issues related to solution functionality. Getting a sense of solution quality from a functional perspective is important because it drives subsequent testing such as usability testing. Typically, a solution is not presented for end-user testing (e.g., usability testing and pilot) before a solution works reasonably well in those areas being considered. Otherwise, users can get hung up on technical glitches rather than assessing a solution from a usability perspective. Issue ConvergenceLead Advocacy Group: Test Experience shows, on average, that a team has the capacity to resolve issues at a consistent rate. Issue convergence is the point at which the rate of issues identified falls below the rate of issues resolved, as exemplified in Figure 10-2. This is a stabilizing indicator that helps forecast when a solution will be ready for release (i.e., all active issues resolved) and provides an objective indicator of team progress. Figure 10-2. Illustration of issue convergence Because the issue identification rate will still go up and downeven after it starts its overall declineissue convergence usually manifests itself as a trend rather than a fixed point in time. After issue convergence, the number of issues should continue to trend lower. Issue convergence checkpoint is often a morale booster because it signals to the team that the end is actually within reach. Should ongoing analysis of issue convergence show that the trend flattens, or worst yet reverses, it is a clear warning sign that should be investigated. User Interfaces StabilizedLead Advocacy Group: User Experience A user interface is any interaction point between a solution and users or administrators. Whether it is an infrastructure or software development effort, these interaction points need to be planned, built, and stabilized because they are referenced and used within so many project and solution deliverables. For instance, the Training team typically uses screen shots as part of the training material; the Deployment team uses screen shots (e.g., administrator consoles) as part of deployment guides; the User Experience team uses screen shots as part of user manuals; and the Test team uses screen shots as part of test case instructions. As such, it is important to understand when in a schedule that respective team members should plan on incorporating final versions. Issue Log ClearedLead Advocacy Group: Test An issue log cleared checkpoint is the point in a release when the Build team initially, and unfortunately temporarily, clears the issue log of all active issues. Figure 10-3 illustrates this. After the issue log is initially cleared, the subsequent peaks should become noticeably smaller and should continue to decrease until a solution is stable enough for the team to build the first release candidate. Figure 10-3. Illustration of issue log cleared checkpoint Careful issue triaging is vital because every issue that is resolved risks the creation of a new issue. Achieving the issue log cleared checkpoint is a clear sign that the team is in the endgame as it drives to a stable release candidate. Note that new issues certainly will be found after this checkpoint is reached. However, this checkpoint marks the first time when there are no active issueseven if it is only for the momentand it focuses the team on working to stay in that state. Preproduction Testing CompletedLead Advocacy Group: Test Once a solution has been deployed to live production environment(s) (or at least a staging environment that mimics production), preproduction testing is the final battery of tests conducted before making a solution available in production, albeit as a release candidate. This testing ensures a solution still functions properly, is integrated correctly, and its supporting elements are in place and ready for operations (e.g., help desk knowledge base, support systems, online training). Preproduction testing also includes completing and testing rollback plans. This interim checkpoint signifies that everything has been verified and ready for limited production operations (e.g., conduct a pilot, as discussed shortly). Release Candidate 1 Through n CompletedLead Advocacy Group: Test As mentioned in Chapter 6, "Establishing a Solution Delivery Life Cycle," a release is an interim, incremental version of a solution assembled through multiple, progressive iterations. It is an achievement of predetermined criteria, features, and capabilities. A release candidate is a release that has been deemed a possible final release of a solution because the team thinks it satisfies all release criteria. Until a release candidate is proved to satisfy the release criteria, the team continues to refine a solution and produce release candidates. The successful deployment of each release candidate is considered an interim checkpoint. The first release candidate checkpoint typically marks the completion of testing by a project team and select stakeholders and users, and marks the start of testing by a much broader audience. This first release candidate is typically a solution build that passed the preproduction testing. Typically, a release candidate is stable and complete enough to use for the pilot effort and user acceptance tests (both discussed shortly). System Testing CompletedLead Advocacy Group: Test System testing assesses a solution from a black-box perspectivewhen a solution is assessed by its external behaviors and characteristics; the inner workings are not considered. Typically, this type of testing includes the following (each discussed in more detail later):
This interim checkpoint signifies that all system testing has been satisfactorily completed. User Acceptance Testing CompletedLead Advocacy Group: User Experience User acceptance testing secures user agreement that a solution meets user and business needs, as defined previously as user acceptance criteria. These tests measure and confirm usability and capability from an end user's perspective. Testing typically commences during a Build Track when users assess solution components and continues throughout stabilization. As a solution is more complete, the scope of this testing broadens. This interim checkpoint signifies that user acceptance testing has concluded. It is achieved when a representative population of users (sometimes called user champions) has assessed a solution and concurs that the solution meets their needs and is sufficiently usable. User acceptance testing also gives support personnel and users the opportunity to understand and practice using a solution through limited hands-on training. The benefit for the team is that it gives them an early understanding of where users have trouble understanding, learning, and using a solution. Pilot CompletedLead Advocacy Group: Product Management As mentioned in Chapter 8, "MSF Plan Track: Planning a Solution," a pilot is an opportunity to validate with real users the degree of solution usability, as well as that a solution works as expected in a controlled, production-like environment under live conditions. Successful completion of the pilot, or set of pilots as detailed in the pilot plan, typically signifies that a solution is ready to be deployed for general availability. A pilot is not complete until the team ensures that a solution meets all defined release criteria, is viable in the production environment(s), and the prospective users are ready to use a solution effectively (e.g., right level of usability, planned training is sufficient, sufficient support options are effective). Sometimes a pilot does not go as planned, and therefore pressing forward with the pilot might not make sense (e.g., a critical issue is discovered). As with any issue triage, a team needs to assess the situation to determine how to proceed:
|
EAN: 2147483647
Pages: 137