Testing and Deployment Plan

From MIKE2.0 Methodology

Activity: Testing and Deployment Plan

Objective

This activity defines the Testing and Deployment Plan. The Detailed Test Plan describes the plan, roles and responsibilities, schedule, and entry and exit criteria for each of the relevant testing phases – Functional, System Integration, User Acceptance Testing, PVT and UAT. The Detailed Test Plan identifies all the test scenarios that are to be executed as part of relevant testing stage. Deployment Plans define how software will be implemented into a production environment.

Testing Plans will vary in the complexity depending on the project scenario, but as a starting point the overall process should be seen to be similar for most Information Management projects. Some examples of where major variances in testing for different project scenarios:

• For Data Quality projects, the development and testing cycle tends to be very iterative as data quality issue resolution tends to follow the Pareto Principle "80/20 rule".

• Testing Business Intelligence applications will require different levels of testing. The more structured the application the more prescriptive the testing and the more involved the technical staff will be. In the case of unstructured types of analytical applications the testing may be limited to validating the accuracy and currency of the data. Beyond this the user is in control to determine the validity and interpretation of the results of the analysis developed spontaneously.

• Testing shared platform and infrastructure can be challenging as it is often difficult to replicate the scenarios that will be seen in a production environment. In this case, close operational monitoring as an ongoing process is just as important as pre-production testing.

In general, the testing for an information system is different than the testing required for operational systems. Testing and Defect Management must always be prioritised on risk and business impact opposed to just trying to test all possible scenarios.

Testing should be defined across the workstream to be tested (applications, infrastructure, information) and by cycle of testing (Functional, SIT Testing, E2E Testing, SVT, UAT and PVT). Each cycle of testing will include:

Definition of overall testing scope and approach

• Define scope of each testing cycle
• Identify business and system functions that require validation
• Identify the different types of testing required
• Determine what is required from a development perspective and dependencies between test cycles
• Define test documentation and provide a revision of baseline testing documentation

Definition of Entry and Exit Criteria for Testing

• Defect Definition
• Defect Status
• Escalation
• Define Testing Signoff process and Handover procedures

Definition of testing resources and responsibilities

• Create a skills development plan
• Assign responsibilities
• Define test environments and configurations
• Define testing tool suite
• Test case libraries
• Defect report template
• Overall traceability matrix
• Ensure alignment with Risk and Issue Management Processes

Testing Plan

• Produce testing task plan
• Define detailed schedule
• Define major milestones and dependencies

After the Testing Plan has been completed, a summary view of the Testing and Deployment Plans are added into the Roadmap.

Major Deliverables

• Detailed Test Plan for each phase of testing
• High level requirements for test data and areas to be tested
• Test Schedule (revised during Test Design)
• Begin to gather Test Data (completed during Test Design)
• Deployment Plan

Tasks

Define Test Plan for Applications

Objective:

An overall plan is created for testing applications, using the categories defined above. For testing Applications, Functional Testing and E2E Testing will be the areas of highest complexity.

Input:

• Detailed Application Requirements for Increment
• Technical Risks & Constraints
• Risk Management Plan
• Infrastructure Dependencies
• Design Dependencies
• Acceptance Procedures
• Test Strategy

Output:

• Overall Application Test Plan

Define Test Plan for Infrastructure

Objective:

This will provide a test plan focused primarily on integration and infrastructure management functions (backup & recovery, security, operations & management). For testing Infrastructure, Functional Testing (for Integration), SIT Testing and SVT Testing will be the areas of highest complexity.

Input:

• Detailed Infrastructure Requirements for Increment
• Technical Risks & Constraints
• Risk Management Plan
• Infrastructure Dependencies
• Design Dependencies
• Acceptance Procedures
• Test Strategy

Output:

• Overall Application Test Plan

Define Test Plan for Information Development

Objective:

An overall plan is created for testing applications, using the categories defined above. For testing Information Development, Functional Testing and E2E Testing will be the areas of highest complexity.

Input:

• Detailed Information Requirements for Increment
• Technical Risks & Constraints
• Risk Management Plan
• Infrastructure Dependencies
• Design Dependencies
• Acceptance Procedures
• Test Strategy

Output:

• Overall Application Test Plan

Define Test Schedule

Objective:

An overall schedule is created for testing applications, infrastructure and information development. This schedule will be developed in parallel with the Test Plans of each area and added to the overall Test Plan

Input:

• Develop Test Plan for BI Application Development
• Develop Test Plan for Infrastructure Development
• Develop Test Plan for Information Development

Output:

• Updated Test Plans with Test Schedule

Acquire Test Data

Objective:

In this step we begin to acquire test data for the execution of the testing process. This is typically a long-running task, and one that takes significant amounts of time due to technical complexity, security issues and personnel problems. In summary, some of this data can be gathered during some of the initial extract processes whilst other aspects of required test data won\’t be known until business rules are more defined. Therefore, although the test data isn’t really required until test cases are developed, it is better to start at least some aspects of the procurement process as soon as possible.

Input:

• Detailed Requirements for Release
• Testing Strategy
• Test Plan for Information Development
• Test Plan for Infrastructure
• Test Plan for Applications

Output:

• Initial extracts of test data

Define Deployment Plan

Objective:

The Deployment Plan provides the major tasks and timelines for implementing the solution into production. It includes a strategy for how the solution will be implemented, success factors, go/no-go checkpoints, contingency measures and procedures for system maintenance and outages. The complexity of the Deployment Plan depends greatly on the type of solution being implemented, especially factors such as number of users, whether it an operational system, its availability and number of downstream systems that would be impacted.

Input:

• Risk Management Plan
• Infrastructure Dependencies
• Design Dependencies
• Overall Release Functionality
• Detailed Requirements for Increment
• Test Plan for Applications
• Test Plan for Infrastructure
• Test Plan for Information Development

Output:

• Deployment Plan for Increment

Core Supporting Assets

Yellow Flags

• Test Plan has major diversions from Test Strategy
• Testing infrastructure is insufficient to execute on Test Strategy
• Lack of an architectural foundation to support automated testing and deployment techniques
• Major issues (quality problems, delays) during testing execution during previous increments

Key Resource Requirements

• Test Manager