Testing and Quality Assurance

Testing a migrated application is not always as straightforward as testing an application that you have defined and built yourself. When you port an application, you do not understand its functionality the way you would if you had written the program. Typically, you do not have time to learn the application s internal architecture and design (this time constraint may be part of the reason a porting strategy was selected).

Despite some complexities, the testing activities are similar to those used for a homegrown application. First, write a test plan that describes test objectives and a plan of action for meeting them. Next, write tests that provide adequate coverage of the testing objectives. Finally, complete the tests and analyze the results to ensure that the application migration has been a success.

Testing is covered in greater detail in Chapter 12, Testing the Migration.

Writing a Test Plan

The test plan includes a testing strategy that specifies the areas to be tested and describes the resources (both hardware and personnel) that the test team requires in order to do its job.

The testing strategy defines the overall approach to testing, and takes the following into account:

• The type of application to be tested (for example, user facing or process control) as well as the main functional aspects of the application

• Key quality criteria for the application (for example, whether it requires being transaction intensive , highly reliable, or scalable)

Based on these factors, the test plan proposes how the application should be tested. For example, the plan may stipulate that the application requires mainly user-facing tests, or that it specifically requires loading tests.

The strategy should also take into account any testing requirements and facilities already in place or defined to enable testing of the migrated application. The following are some questions to ask:

• Does the application include test application(s) or script(s) that can be used to perform functional or performance-verification tests?

• Does the configuration and build environment build the test application(s) along with the target application?

• How portable to the Windows environment are the test application(s) or script(s)?

The type and amount of testing to be done depends on the application that is being ported, the strategy chosen for the migration, and the availability of existing information and resources. If no testing applications or documentation exists, a side-by-side comparison of functionality of the UNIX application and the ported application is the only alternative.

Writing the Tests

The following are some applicable test categories:

• Coverage testing (used primarily during the development phase)

  • Test every feature of the migrated application (a functional test).

  • Test the code base of the application (check-in, build verification, and regression tests).

• Usage testing (used primarily during the stabilizing phase)

  • Test to discover the sections of code on which the application spends most of its execution time.

• Integration testing (used to verify the correct interactions between the application components and other systems)

  • Test the synchronization and coordination between components (for example, the way that UNIX and Windows workstations use the migrated application to access data).

  • Test the data integrity, especially when the application requires intensive file record-locking.

  • Test the features and the usage scenarios.

Tests should also be planned for any configuration, run-time, or deployment scripts.

Running the Tests

After the tests are written and the application build is successful, you can actually run the application. If it works, you can continue to test its functionality and performance by using the tests that have been defined for the application.

If the application is packaged with its own suite of testing applications or scripts, perform a portability analysis of the test suite by using the same tools and methodology that you used with the target application. If the application does not have a testing suite, use a symbolic debugger as the main testing tool if the application fails.

If both the UNIX and ported programs have testing applications or scripts, and the testing applications or scripts have also been ported, then the tests can be performed on both the original UNIX application and the ported application. The comparison of the test results can be automated by using tools such as diff to compare the functional output line by line.

Even if no testing applications or scripts exist, the UNIX application may be bundled with documentation that describes its input-output functionality. You can then compare the test results to this documentation.