Stage 3: Design the Test Plan and Test Cases

During the migration process, tests must be conducted on various levels to detect bugs as soon as possible, and to limit the complexity of the tests. The following levels of tests are generally accepted:

• Developer testing

  Developer testing is mentioned here for completeness only. It refers to the tests conducted by developers during the development process or prior to submitting work to the tester. These tests are informal, often ad hoc, and are rarely ever documented. They are useful for eliminating most of the simple bugs, and for understanding and defining the scope derived from the specification.

• Unit testing

  The first formal testing activity is unit testing. A unit is the smallest piece of software that can be tested on its own (functions in imperative programming, classes in object-oriented programming). Unit testing ensures correct operationof these small pieces, which form the building blocks for the complete system.In the case of a migration project, unit testing ensures the correct operation ofa migrated application running on the Microsoft Win32 platform as compared with the UNIX platform.

• Integration testing

  The next level of testing is integration testing. This is actually not a one-time activity, but an iterative process in which units are combined into componentsof increasing size until the system is complete. A component is a combinationof units that forms a useful abstraction that has a defined functionality (a module,a subsystem, a framework, or a cluster of classes). The focus in integration testing is on the interfaces between the units or components that constitute the current level of integration. Integration testing requires a detailed design or (for larger components) a specification that can be validated . Integration testing proves that all areas of the system interface operate with each other correctly and that there are no gaps in the data flow. The final integration test proves that the system works as an integrated unit when all the fixes are complete.

• Functional testing

  The next level of testing, functional testing, ensures that each element of the application meets the functional requirements of the business as outlined inthe requirements document or functional brief, system design specification,and other functional documents produced during the course of the migration process (such as records of change requests , feedback, and resolution of issues).

• System testing

  The final level of testing is system testing. This refers to both the internal system testing prior to shipment and the final testing conducted by the customer. As the name implies, system testing focuses on the system as a whole and its visible functionality and performance. Functionality and performance are tested based on the requirements and the validation criteria stated therein. System testing also proves that the documented performance standards or requirements are met. Examples of testable standards include response time and compatibility with specified browsers and operating systems in the native UNIX application andin the migrated Windows application. If the system hardware specifications state that the system can handle a specific amount of traffic or data volume, the system is tested for those levels.

Creating the Detailed Test Plans

DTPs are created in parallel with the lab setup and development work. For large or very complex projects, DTPs are generated from the MTP for the various areas that have been identified for testing. For smaller projects, the DTPs may be included within the MTP.

DTPs, like the MTP, are based on the functional specification and other high-level design documents. The test team assigns a priority to each scenario in a DTP based on the probability that the scenario will occur and its impact on business. DTPs are usually grouped according to the organization of the test group , the availability of various components in the system, or the area of functionality. Essentially , the DTPs have scenarios in the context of high-level considerations, such as functionality, interoperability, or performance criteria. The test cases are derived from these scenarios. Table 12.4 shows the tester s responsibility for each criterion.

Table 12.4: Tester s Responsibility for Test Criteria

Evaluation Criteria	Tester s Responsibility
Features and functionality	Execute tests that demonstrate that the application provides the same functionality as found on the UNIX platform.
Interoperability	Execute tests that demonstrate the ability of the application to share server data with clients that are running the application on the UNIX platform.
Performance	Execute tests that demonstrate the performance of the applications on the Win32 platform. Where data is lacking to make a valid comparison with the performance on the UNIX platform, the tester uses industry-standard benchmarks (when available).

The template of a DTP is provided in Appendix 12.4, Detailed Test Plan Template.

Creating Detailed Test Cases

Each of the scenarios listed in the DTPs is translated into one or more detailed test cases to create the DTC documents. A DTC document essentially describes input,an action, or an event, and an expected response. The quality assurance (QA) engineer or another tester performs the test case to determine whether the specific functionality of the migrated application is working correctly. Alternatively, the QA engineer or tester can compare the results of the original UNIX application and the ported application simultaneously .

Because test case development requires working on the complete operation of the application, the process of developing test cases can help find issues and defects in the requirements or design of the migrated application. It is therefore recommended that the detailed test cases be prepared early in the development cycle.

A detailed test case contains:

• Detailed test setup instructions.

• Detailed test procedures, including step-by-step instructions for executingthe test case.

• Expected results and success (pass/fail) criteria.

Figure 12.2 represents the steps in test planning and test execution.

Figure 12.2: Steps in test planning and test execution