The test scripts may require two versions. The first one is the comprehensive one that will be executed before the migration weekend where you have enough time to go through enough test cases. The second one should be the subset of the first test scripts, and they will be used during the migration/relocation weekend. The outage window during the migration/relocation weekend is limited, so, only a small subset of the test cases is feasible to execute to validate (or invalidate) the migration of an application.
The test scripts should be signed off to make sure they are properly designed to validate the successful migration/relocation of an application.
The test script should have a room to capture the actual test transactions and results. This information will be vital information, if the production data is corrupted by the test.
Develop test scripts in accordance with the test plans. The test planning stage provides the next level of detail. A detailed investigation, analysis and preparation is undertaken which will ensure test scripts can be developed. The test planning stage and deliverables produced will define the test activities that will be carried out for each migration wave and will include the test methods, test coverage, test script descriptions, required data and environments.
A key approach during this stage is the review process which is outlined below:
The review stage of mitigation will allow static test techniques (technical reviews) to be applied to the early deliverables (i.e. requirements, specifications and designs) as soon as these documents are completed. The rationale behind the review stage is that errors in documents can be found quickly and resolved at the earliest possible stage in the development process.
Technical reviews will aim to find a range of issues (e.g. inaccuracy, inappropriate design, ambiguous, incomplete or duplicated requirements) and get these resolved before the errors are implemented further down the development lifecycle.
The specific risks to be addressed by the review stage can be itemized in a separate Excel document.
The review stage can begin as soon as the first document to be delivered is available and appropriate technical reviewers are available for both reviewing the document as well as attending the meeting. Each document to be reviewed can be accepted provided it is complete, versioned, under configuration control and all reference documents are available.
No formal criteria will be defined, the completion of each reviews will be at the discretion of the test manager and the review leader for each individual document. However, as a minimum, review comments will need to be documented.
The approach taken will be to review each document prior to its release into the next stage of development. The method of review of each deliverable is dependent on the type and complexity of the deliverable (e.g. requirements, technical specification). This may take the form of:
- Technical Review
- Peer Review
The responsibility for ensuring that reviews are carried out will be the author of the document. The review team will be made up of business and/or technical experts from the appropriate business and development teams. The author will be present in an advisory capacity only.
A full approach and identified requirements to test against will be produced using a template based on the standard test plan template, which covers the following:
- Test plan identifier
- Test items
- Detailed test approach
- Entry / Exit criteria
- Suspension / Resumption criteria
- Data / Environment requirements
- Resource including but not limited to internal, external, third parties
- Training requirements
- Test schedule
- Testing tasks
- Risks and issues (including mitigating actions)
- Baseline principles
- Defect classification
The deliverables expected of the test planning stage are:
- Test plans (produced as per test approach)
- Test to requirements matrix
Key ‘Inputs’ required, in order to produce the deliverables in the test planning stage are:
- Test approach
- Project Initiation Document
- Business and technical requirements
- Technical architecture documents
- Technical specifications (e.g. migration designs, infrastructure macro and micro designs)
- Discovery signed off
- Test scope
- Overall project plan.
- Develop and document infrastructure test scripts
- Develop and document application test scripts
- Design and document test verification approach
Hints and tips
- Test scripts and verification tests should derive from test plans and be efficient. Focus on points of change and not complex business logic and processes.
- Defect Management should be explained to the test teams such that they know how to raise defects and issues.
- The capture of testing MI should be designed and coordinated to record test defects and report on the quantity, severity and closure rate.