Functional Tests: Getting to Level 4

Level 4 Quality means the generated application yields correct results on the target platform. The application is ready for production use on the .NET platform. The application is ready for deployment and further upgrade on the .NET platform.

Generally a migration team will continue to extend and refine re-engineering during the functional testing phase. The reasoning behind this is that sometimes build problems, standards violations, and functional defects can all be resolved by re-engineering portions of the generated code. If the re-engineering solution must be applied in many places then it will be most efficient to do this by configuring the general rules of the translator, but if the problem is localize to a few functions then other techniques for incorporating hand-fixed code (e.g., author/fix or refactor/reauthor) may be employed.

Side-by-Side Testing

Verifying that the .NET codebase is functionally equivalent to the source codebase is of paramount importance to any migration effort. The tool-assisted rewrite methodology makes this much more attainable than a from-scratch rewrite because you will be using the original source as the functional specification of the new code. The original source is be definition the most accurate specification of what the original application does and it describes it in extreme detail.

For most organizations the functional quality gate is expressed as "the new app must produce the same results and have the same behavior as the old app.". This is a fair starting point, but it does not describe how to prove that is the case. The migration team will still have to articulate in significant detail how to execute test cases and inspect the actual results of that doing. Developing a list of use cases and then a list of test cases with expected results is the traditional way of doing this with any rigor.

The good news is that you should be able to say that the actual results of the original system define the expected results of the new system and this is a BIG leg up for defining test cases.

Automated Unit Testing

Another extremely powerful technique to implement as part of your migration effort is automated unit testing. Automated unit testing is a natural extension of GMM's automated conversion pipeline:

• Automated translation/refactoring,
• Automated build tests,
• Automated code reviews,
• Automated unit testing

Teams that invest in a fully automated conversion pipeline will minimize both the Total Cost of Conversion (TCC) and the Total Cost of Ownership (TCO) and thus maximize the ROI of the conversion effort.

A comment about freezing functionality during your migration

Moving to the .NET platform will cause subtle changes in the look and feel of your application and running in the CLR also creates changes in the security, performance, and operation of your application. You will have to account for this. On the other hand, adding or changing the business rules or making major changes in look and feel of the application are, strictly speaking, not in the scope of a conversion effort. Also, beware that changing the new application without making corresponding changes to the source application may complicate your ability to do side-by-side testing.

That said, the GMM assumes a working source codebase, not a frozen source codebase. The legacy application is allowed to be maintained and enhanced for ongoing maintenance. Updated versions of the VB6/ASP/COM codebase may enter the translation refinement process as they become available – typically on the same release cycle as the legacy application.

Forms Designer Test

The Forms Designer Test verifies that the designer code in your .NET UI classes (Forms and UserControls) can run correctly in the visual Studio forms designer: