Build and test prior to production

Build and test planning establishes the approach to building, testing and maintaining the controlled environments prior to production. The activities include:

• Developing build plan s from the SDP, design specification s and environment configuration requirement s
• Establishing the logistics, lead times and build times to set up the environments
• Testing the build and related procedure s
• Scheduling the build and test activities
• Assigning resource s, roles and responsibilities to perform key activities, e.g.:
• Security procedures and checks
• Technical support
• Preparing build and test environment s
• Managing test databases and test data
• Software asset and licence management
• Configuration Management – configuration audit, build and baseline management
• Defining and agreeing the build exit and entry criteria.

Figure 4.21 Service V-model to represent configuration levels and testing

Figure 4.21 provides an example of a model that can be used to represent the different configuration levels to be built and tested to deliver a service capability. The left-hand side represents the specification of the service requirements down to the detailed Service Design. The right-hand side focuses on the validation and test activities that are performed against the specifications defined on the left-hand side. At each stage on the left-hand side, there is direct involvement by the equivalent party on the right-hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirement s. For example, customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan.

The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. Within each cycle of the iterative development, the V-model concepts of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trial and assessment.

Further details on validation, testing and service evaluation are provided in sections 4.5 and 4.6. The test strategy defines the overall approach to validation and testing. It includes the organization of validation and testing activities and resource s and can apply to the whole organization, a set of services or an individual service.

Typical levels of configuration for build and testing are shown in Table 4.8.

Level	Requirements and design	Build/deliverable	Validation and testing
Level 1 Customer/business needs	Structured definition of contract requirements	Customer contract (based on Service Portfolio, SLP)	Service test and evaluation Determines whether a service can enable the user s and customers to use the service to support their business needs (is fit for purpose and fit for use).
Level 2 Service requirements	Service requirement specification s and SAC, traceable back to the contract requirements	Service capability and resource s to deliver against the SLA and service requirements	Service test Test the Service Acceptance Criteria are met. Includes validation of service performance against the service level requirement s and SLA in pilot s, deployment and early life support.
Level 3 Service solution	SDP, Service model, service environment s	Solution/ system required to deliver the service capability; includes the Service Management and Service Operation s systems and capabilities	Service operational readiness test To evaluate the integration and operation of the service capability and resources. It verifies that the target deployment organization and people are prepared to deploy and operate the new or changed service in the live environment, e.g. deployment team, Service Operations, customers, user s and other stakeholder s. Tests include scenario-based testing such as simulation and service rehearsal.
Level 4 Service release		Release package	Service release test A test that the service component s can be integrated correctly and that the release can be installed, built and tested in the target environment s. Service release testing includes non-functional testing that can be performed at this level.
Level 5 Component and assemblies	Component and assembly test specification	Component or assembly of components	Component and assembly test Test that a service component or assembly of components matches its detailed specification. Component s or assemblies are tested in isolation, with a view to their delivering as specified, in terms of inputs generating expected outputs. Evidence of component quality or testing earlier in the chain may be obtained for test evidence, from both internal and external supplier s.

Table 4.8 Levels of configuration for build and testing

Various controlled environment s will need to be built or made available for the different types and levels of testing as well as to support other transition activities such as training. Existing deployment processes and procedure s can be used to build the controlled test environment s. The environments will need to be secure to ensure there is no unauthorized access and that any segregation of duty requirement s are met. The types of environments, both logical and physical, required during release and deployment include:

Дата добавления: 2015-10-29