Overview of the Test Life Cycle of the Migration Project

The test life cycle of a migration project is synchronized with the development stages of the project. In the software life cycle, the test life cycle follows the waterfall model, the spiral model, or a combination of both models.

Test Life Cycle Stages

In a migration project, the test life cycle consists of the following stages:

• Stage 1: Plan the migration test . This stage is essentially part of the plan for the entire migration project and is covered in detail in Chapter 4, Assessment and Analysis. In this stage, you establish the main objectives, scope of testing, test criteria, scheduling, infrastructure, resources, success criteria, and requirements for finalizing the deliverable .

• Stage 2: Define the lab strategy and build the test bed . In this stage, you define a strategy for planning the lab environment, network configuration, and hardware and software requirements. You also create a process for installing the test bed for both the native UNIX application and the migrated application.

• Stage 3: Design the test plan and test cases . In this stage, you create a test plan and test cases as defined in the scope of the migration project. You use the input available in the test plans of the native UNIX application. However, if new features are added to the migrated application, some rework may be necessary. In this stage, you also establish the people who will execute the test cases, their responsibilities, and the actual schedule of the migration.

• Stage 4: Execute the test . In this stage, you execute the test and manage the test results.

• Stage 5: Evaluate and analyze results . In this stage, you evaluate the test results and use the final evaluation of the project to determine how to approach the next phase of the migration ” the deployment phase.

Figure 12.1 represents the flow of the different stages involved in testing the migrated application. The details of each stage are explained later in this chapter.

Figure 12.1: Overview of the test life cycle

Best Practices

The following best practices are recommended to ensure that the test phase of your migration project is successful:

• Create a master test plan (MTP) that defines the scope of the test phase. You should do this when you are scoping the requirements, before you begin the design phase of your migration. During the migration process, it is importantto document and finalize the scope of testing and the test coverage. By maintaining an MTP, you can track the scope of the migration project from the start of the project.

• Create one detailed test plan (DTP) that captures all the scenarios related to testing the migrated application. For the detailed test cases (DTCs), you can have multiple documents based on functionality, modules, or group .

• Create a numbering convention for the test scenarios (for example, 1, 2, 3 ) and for the test cases (for example, 1.1, 1.2 2.1, 2.2, 2.3 3.1 ) in the DTP and the DTCs, respectively. This is very important and helps in identifying the test cases effectively.

• Review the DTP with the development team, which can provide valuable input and ensure adequate prioritization of test cases.

• Maintain a test plan matrix for functionality and for the test cases. The test plan matrix is especially useful during integration testing. For example, if you must derive the use-case scenario for some functionality, you can use your numbering convention to map the functionality F1 to test cases 1.2, 3.2, 1.4, 4.5, and so on. This ensures that if there is any specific testing to be done, the test engineer can add or modify the matrix. Also, if any functionality is changed or modified or any bug is fixed, you can use the matrix to conduct strategic testing.

  Another use of the test plan matrix is to trace the requirement changes and identify the impact of testing. If any new feature is added to the migrated application, the scope of testing that feature will have an impact on overall testing; you can use the matrix to track the scope effectively.

• Perform a root cause analysis on all bugs in an early stage of the migration project. The test team can classify the bugs based on the cause (for example, content, code, UI, design, or wrong requirement). Giving feedback about these causes to the development team can ensure that future modules do not contain these defects.

• Collect metrics from the test results to determine the quality and productivityof the project and the team members .

• Track daily status. To maintain control during the migration process, it is strongly recommended that the test lead prepare a daily status report that highlights areas of concern, accomplishments, test metrics, quality, bug statistics, and action items.