Ein Softwaremigrations-Projekt erfordert einen anderen Testansatz als ein Entwicklungsprojekt. Denn es existiert im Regelfall weder eine Anforderungsspezifikation noch ein Designmodell als Testgrundlage. Das bedeutet, dass für Migrationsprojekte anforderungs- und modellbasierte Testansätze nicht geeignet sind. Vielmehr kann für den Test migrierter Systeme das Altsystem als Testorakel herangezogen werden. Das entscheidende Testkriterium ist dann die vollständige funktionale Gleichheit von Alt- und migriertem System - und dafür müssen spezielle Methoden und Werkzeuge zum Einsatz kommen.

Darüber hinaus sollte im Migrationstest schrittweise vorgegangen werden:

„Man kann nicht planen, was man nicht messen kann“ [1]. Gemäß dieses Zitats von Tom deMarco muss im Rahmen der Planung eines Migrationstests das gemessen werden, was migriert werden soll: der Quellcode.

Denn in Migrationsprojekten ist dieser Code des Altsystems die entscheidende Grundlage für die Aufwandsschätzung [2].

Welche Aspekte einer Messung unterzogen werden, hängt von der gewünschten Information und Zielgröße ab, die man mit der Messprozedur gewinnen will. Die gewünschten Metriken können anhand statischer Analyse aus dem Quellcode, den Datenbank-Schemata, den Definitionen des Benutzerinterfaces sowie den Systemschnittstellen gewonnen werden [3].

Die Erfahrung vergangener Projekte zeigt, dass der Zeitaufwand für die Messung von Quellcode im Regelfall nicht mehr als 1 Woche beträgt; vorausgesetzt, man setzt dafür die geeigneten Messwerkzeuge ein. Der Autor Harry M. Sneed hat im Laufe der Zeit Werkzeuge entwickelt, die sich nicht nur für neue, sondern ebenso für alte Programmiersprachen eignen. Denn in den allermeisten Migrationsprojekten ist das Vorgängersystem in einer alten Programmiersprache wie PL/1, Cobol oder C geschrieben.

Zeit- und Aufwandsschätzung für die Testdurchführung sind Bestandteile der Testplanung. Der Testaufwand bemisst sich hier nach der Anzahl an zu exekutierenden Testfällen (Online-Transaktion, Batch-Prozess etc.) sowie jener an zu validierenden Testobjekten. Ein Testobjekt wiederum kann aus den Produktionsdaten generiert werden: in Form eines Benutzer-Interfaces, einer Datei, einer Datenbank-Tabelle, einer Systemschnittstelle etc. So gelangt man zu einer Rohschätzung für das aktuelle Migrationstest-Projekt. Diese Schätzung kann z.B. mittels Produkttyp oder des Testwiederholungsfaktors verfeinert werden [4].

Das Ergebnis der Testplanung ist ein Testkonzept gemäß ANSI/IEEE-Standard 829. In diesem sollte besonderes Augenmerk auf die Testziele und die Testendekriterien sowie deren Messung gelegt werden. Denn nur wenn diesen beiden Aspekten entsprochen wird, kann der Kunde den Test am Ende abnehmen. Das kann z.B. mittels Kennzahlen über die durchgeführten Testfälle und über die validierten Testobjekte erfolgen [5].

Um einen Migrationstest zu designen, muss man berücksichtigen, was (Testfälle und Testobjekte) und wie (Testvorgehen) zu testen ist. Häufig ist mangels Verfügbarkeit und Aktualität einer Dokumentation des Altsystems die einzige Möglichkeit für die Erstellung eines Testdesigns, dass der Tester aufzeichnet, wie die Endbenutzer das System aktuell bedienen.

Bei den Testobjekten ist die Anzahl an Datenelementen, die jedes Datenobjekt besitzt, von besonderer Bedeutung. Dazu zählen z.B. Felder und Spalten sowie deren Wertebereiche.

In einem Migrationsprojekt gewinnt man die Testdaten am besten direkt aus dem Produktionssystem, indem man einen Teil der Produktionsdaten abzieht (und anonymisiert). Im Testdesign sollte man bereits einzelne Transaktionen, Ereignisse und Batchläufe mit repräsentativem Charakter identifiziert haben.

Vor jedem Test müssen Abbildungen des Benutzer-Bedienfeldes, der Eingabedateien und des Datenbankinhaltes archiviert werden. In der gleichen Form müssen nach jedem Test die neuen Abbildungen derselben Objekte sowie zusätzlich gesendete Ausgabe-Nachrichten und ausgedruckte Reports festgehalten werden. All das führt zu einem großen Aufkommen an Testdaten.

Hier können Testwerkzeuge und Capture-Replay-Tools als nützliche Helfer zum Einsatz kommen [6].

Im sechsten Schritt werden die Ergebnisse des Migrationstests evaluiert, um festzustellen, ob das migrierte System die Erwartungen erfüllt: nämlich dieselbe Leistung (inkl. Performance) wie das Altsystem zu erbringen.

Zu Validierungszwecken werden die Bildschirminhalte, Schnittstellendaten und Datenbank-Tabellen der Tests aus beiden Systemen automatisch miteinander verglichen. Weichen die Formate voneinander ab, muss zugunsten einer Vergleichbarkeit eine Konvertierung in ein einheitliches Format stattfinden.

Zu diesem Zweck hat einer der Autoren mehrere Umwandlungs- und Vergleichs-Werkzeuge entwickelt - die alten wie die neuen Benutzeroberflächen werden in XML-Dokumente transformiert.

Ebenso werden die Inhalte der alten Datenbanken und jene der neuen, relationalen Datenbanken heruntergeladen, und dabei zu Vergleichszwecken in komma-separierte (CSV-) Dateien umgewandelt.

Die vor der Testausführung automatisch im Code eingepflanzten Messfühler oder Verfolgungspunkte werden während der Testausführung in Log-Dateien aufgezeichnet. Nach dem Testdurchlauf werden sie ausgewertet. Messreports können unterschiedliche Informationen dokumentieren: den Testabdeckungsgrad, den Pfad jeder einzelnen Testtransaktion etc.

Beim Test eines komplett neu entwickelten Systems treten z.B. folgende Fehler auf: es werden Funktionen ausgespart, Ergebnisse falsch kalkuliert usw. Beim Test eines migrierten Systems sind die (Transformations-) Fehler allerdings subtilerer Natur: Nachkommastellen gehen verloren, Datensätze werden zerstört, Daten haben sich an einen anderen Ort verlagert usw.

Die einzige Möglichkeit zur Aufdeckung solcher Fehler ist es, alle Daten zu vergleichen; kombiniert mit einer Abdeckung des kompletten Programmcodes. Jede Anweisung muss getestet werden – das bedeutet, dass eine wiederholte Durchführung des Tests notwendig ist [9].

Neben der Messung der Testabdeckung ist es erforderlich, die Richtigkeit der Ausgabedaten und den Prozentsatz an tatsächlich aufgetretenen Fehlern relativ zu jenem der vorausgesagten Fehler zu messen. Mit diesen Informationen kann man feststellen, wann der Test beendet werden kann.