Verification_Functional

 Functional Tests: getting to level 3

This page describes level 3 testing concepts and techniques.

1. Level 3 Testing Overview
2. Side-by-Side Testing
3. Automated Unit Testing
4. .NET Designer Test

 Level 3 Testing Overview

Level 2+ quality means that you have a Build-Complete .NET version of the legacy application that meets your technical standards. The next step is to reach level 3 -- Functionally Correct codes.

Generally a migration team pursues levels 2, 2+ and 3 somewhat in parallel. They resolve build, technical re-engineering, and functional defects at the same time. 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. It is usually most efficient to do this by configuring the translator.

 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.

 .NET Designer Test

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