Testprozess in Migrationsprojekten
Die entscheidende Grundlage für die Aufwandsschätzung in Migrationsprojekten ist der Quellcode des Vorgängersystems.
...weiter lesen
Es gibt IT-Projekte, bei denen der Test- sowie Zeitaufwand gut berechenbar ist. Dies ist dann der Fall, wenn das zu entwickelnde Produkt gegen die Anforderungsspezifikation getestet werden kann und es sich um ein sauber spezifiziertes und stabiles Entwicklungsprojekt handelt.
Bei Wartungs- oder Reengineering-Projekten, bei denen die Software selbst nur leicht abgeändert wird, kann der Testaufwand auf Basis der Differenz zwischen Original- und geänderter Version geschätzt werden.
Bei Migrationsprojekten sieht es anders aus. Eine Softwaremigration erfordert einen anderen Testansatz als ein Entwicklungsprojekt. Im Regelfall existieren weder Anforderungsspezifikation noch Designmodell, welche als Testgrundlage herangezogen werden können. Das bedeutet, dass für Migrationsprojekte anforderungs- und modellbasierte Testansätze nicht geeignet sind. Das entscheidende Testkriterium ist die vollständige funktionale Gleichheit von Alt- und migriertem System – und dafür müssen spezielle Methoden und Werkzeuge zum Einsatz kommen.
Bei Wartungs- oder Reengineering-Projekten, bei denen die Software selbst nur leicht abgeändert wird, kann der Testaufwand auf Basis der Differenz zwischen Original- und geänderter Version geschätzt werden.
Bei Migrationsprojekten sieht es anders aus. Eine Softwaremigration erfordert einen anderen Testansatz als ein Entwicklungsprojekt. Im Regelfall existieren weder Anforderungsspezifikation noch Designmodell, welche als Testgrundlage herangezogen werden können. Das bedeutet, dass für Migrationsprojekte anforderungs- und modellbasierte Testansätze nicht geeignet sind. Das entscheidende Testkriterium ist die vollständige funktionale Gleichheit von Alt- und migriertem System – und dafür müssen spezielle Methoden und Werkzeuge zum Einsatz kommen.
Die Testplanung beinhaltet die Festlegung der Testziele, die Ressourcen- und Budgetplanung sowie eine Zeitplanung und Aufwandsschätzung für die durchzuführenden Arbeitsschritte des Migrationstests.
Der Testaufwand bemisst sich hier nach der Anzahl der durchzuführenden Testfälle sowie der zu validierenden Testobjekte.
Ein Testfall kann aus dem Nutzungsprofil der Produktionsumgebung abgeleitet werden und in Form einer Online-Transaktion, eines Ereignisses, eines Vorganges oder eines Batch-Prozesses definiert sein. Ein Testobjekt kann aus anonymisierten Produktionsdaten generiert werden und ein Benutzer-Interface, eine Datei, eine Datenbank-Tabelle, eine Systemschnittstelle oder ein erstellter Report sein. Testfälle und Testobjekte stellen zusammen den Testumfang dar.>br> Die Testplanung sowie Testaufwandsschätzung inklusive der zeitlichen Aspekte (Testdauer) fließen als Ergebnis in das Testkonzept ein. Auf dieser Grundlage lässt sich ein Preisangebot für den Migrationstest erstellen.
Der Testaufwand bemisst sich hier nach der Anzahl der durchzuführenden Testfälle sowie der zu validierenden Testobjekte.
Ein Testfall kann aus dem Nutzungsprofil der Produktionsumgebung abgeleitet werden und in Form einer Online-Transaktion, eines Ereignisses, eines Vorganges oder eines Batch-Prozesses definiert sein. Ein Testobjekt kann aus anonymisierten Produktionsdaten generiert werden und ein Benutzer-Interface, eine Datei, eine Datenbank-Tabelle, eine Systemschnittstelle oder ein erstellter Report sein. Testfälle und Testobjekte stellen zusammen den Testumfang dar.>br> Die Testplanung sowie Testaufwandsschätzung inklusive der zeitlichen Aspekte (Testdauer) fließen als Ergebnis in das Testkonzept ein. Auf dieser Grundlage lässt sich ein Preisangebot für den Migrationstest erstellen.
Die Analyse des zu migrierenden Quellcodes steht am Beginn jedes Migrationstests. So lässt sich herausfinden, was und mit welchem Aufwand getestet werden soll. Erst wenn die Software einer Analyse unterzogen wurde, ist es möglich, den Test zu planen. Die Komplexität des Kontrollflusses, der Datenverwendung, der Modulinteraktionen, der Wiederverwendbarkeit, der Wartbarkeit, der Konformität oder anderer Größen stellen Aspekte dar, die analysiert werden können. Welche Aspekte einer Analyse unterzogen werden, hängt von der gewünschten Information und Zielgröße ab, die man durch die Analyse gewinnen möchte. Um den funktionalen Anforderungen zu entsprechen, gilt es, im Test Code-Einheiten, Datenbanktabellen und Schnittstellen zu berücksichtigen. Die Analyseergebnisse zeigen, wie viele Schnittstellen bedient und wie viele Datenbanktabellen benötigt werden, um jede definierte Komponente testen zu können. Hier kann ein statisches Analyse-Werkzeuge unterstützen, das die Testbarkeit des Systems errechnet.
Das Design des Migrationstests ist von großer Wichtigkeit. Die Testobjekte sind zu identifizieren. Dazu zählen Benutzerschnittstellen, Datenbanktabellen, Systemschnittstellen und Berichte. Das Testvorgehen – d.h. die Festlegung der einzelnen Testschritte und deren Reihenfolge – ist zu definieren.
Auf eine vorhandene Dokumentation des Altsystems sollte man sich beim Testdesign nicht verlassen. Wenn überhaupt vorhanden, ist diese häufig veraltet und spiegelt die aktuellen Systemeigenschaften nur unzureichend wider. Die effizienteste Möglichkeit des Testdesigns ist es, sich mit den Endbenutzern des Systems zusammenzusetzen. Dieses Vorgehen läuft auf eine nachträgliche Dokumentation der betrieblichen Nutzung hinaus. Ein solches schriftliches Belegmaterial stellt einen Großteil der Aufwände für die Regressionstests dar.
Die Testobjekte, die in der Analysephase aufgezeigt wurden, sind leichter zu identifizieren. Von besonderer Bedeutung ist die Anzahl an Datenelementen, die jedes Datenobjekt besitzt. Dazu zählen z. B. Felder, Spalten, Tags (sichtbare Zeichen zur Daten- und/oder Textstrukturierung). Ebenso relevant sind die Wertebereiche dieser Elemente, die man aus der Produktionsumgebung ablesen kann.
Aus dem Testdesign geht hervor, woher die Testobjekte gewonnen werden und mit welchen Mitteln die Testfälle aufgezeichnet werden können.
Die Testdaten für eine Migration werden oftmals aus dem Datenbestand der Produktion abgezogen und anonymisiert. Die Anonymisierung dient dazu, den Datenschutzanforderungen zu genügen. Der Abzug von Produktionsdaten passiert, indem man das Altsystem in einer kontrollierten Umgebung laufen lässt. Dabei werden sowohl Eingabe- als auch Ausgabewerte sowie die jeweiligen, aktuellen Datenbank-Zustände aufgezeichnet und festgehalten. Die größte Herausforderung liegt in der Datenqualität und darin, hohe Datenvolumina (wie sie eine Produktionsdatenbank mit sich bringt) korrekt zu handhaben. Genauso wichtig ist es, ggf. vorhandene Batchprozesse abzubilden und mit der Vielzahl an Importen, Exporten, Berichten und der Aufzeichnung der Benutzerinteraktionen sorgfältig umzugehen.
Der Migrationstest erfolgt mit dem zuvor gewonnenen (Test-)Datenbestand.
Da in der Regel in einem Migrationsprojekt explizit definierte, ausformulierte Anforderungen fehlen, müssen konkrete Testfälle über andere Wege definiert werden. Dazu bieten sich üblicherweise die Online-Transaktionen und Batchprozesse an. Die Menge an Dateninput, die in solche spezifischen Migrations-Testfälle fließen muss, kann eine beachtliche Größe annehmen und kann schwierig zu spezifizieren sein. Das trifft gleichermaßen auf die Testfallmenge im Falle von Regressionstests zu. Konsequenterweise empfiehlt sich an dieser Stelle eine Automatisierung der Migrations-Testfälle – schließlich hat die Testdurchführung in einem Migrationsprojekt hauptsächlich mit der erfolgreichen Anwendung von Werkzeugen zu tun.
Nach der operativen Testdurchführung sind die Ergebnisse des Migrationstests zu evaluieren, um festzustellen, ob das migrierte System die Erwartungen erfüllt: Also dieselbe Leistung (inkl. Performance) wie das Altsystem erbringt. Dazu vergleicht man die Ergebnisse der beiden Systeme und hält jegliche Abweichungen als Nicht-Übereinstimmung fest.
Da in der Regel in einem Migrationsprojekt explizit definierte, ausformulierte Anforderungen fehlen, müssen konkrete Testfälle über andere Wege definiert werden. Dazu bieten sich üblicherweise die Online-Transaktionen und Batchprozesse an. Die Menge an Dateninput, die in solche spezifischen Migrations-Testfälle fließen muss, kann eine beachtliche Größe annehmen und kann schwierig zu spezifizieren sein. Das trifft gleichermaßen auf die Testfallmenge im Falle von Regressionstests zu. Konsequenterweise empfiehlt sich an dieser Stelle eine Automatisierung der Migrations-Testfälle – schließlich hat die Testdurchführung in einem Migrationsprojekt hauptsächlich mit der erfolgreichen Anwendung von Werkzeugen zu tun.
Nach der operativen Testdurchführung sind die Ergebnisse des Migrationstests zu evaluieren, um festzustellen, ob das migrierte System die Erwartungen erfüllt: Also dieselbe Leistung (inkl. Performance) wie das Altsystem erbringt. Dazu vergleicht man die Ergebnisse der beiden Systeme und hält jegliche Abweichungen als Nicht-Übereinstimmung fest.
Abschließend gilt es noch die Testabdeckung, also das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen bzw. der Menge der gewünschten treffbaren Aussagen, zu messen. Wurde die, im Testkonzept definierte Testabdeckung erreicht, kann der Test abgeschlossen werden; andernfalls muss er so lange fortgesetzt werden, bis die erwähnten Ziele erreicht worden sind.
Video
Fazit
Ein Migrationstest erfordert einen anderen Ansatz als ein klassischer Systemtest. Ein migriertes System einem Software-Test zu unterziehen, betrifft wesentlich stärker den Aspekt der Massenproduktion. Denn eine enorme Anzahl an konvertiertem Programmcode und an Daten muss quasi blindlings innerhalb eines begrenzten Zeitrahmens getestet werden. Um das Ziel der Demonstration einer funktionellen Gleichwertigkeit zwischen Alt- und migriertem System zu erreichen, müssen idealerweise alle konvertierten Code-Elemente mittels einer großen Datenprobe aus dem Produktivsystem getestet werden. Dieser Datenbestand und die Unmenge an Transaktionen, die wiederholt durchgeführt werden müssen, sprechen stark für den Einsatz einer Testautomatisierung.
In meinen Kundenprojekten haben ich über zahlreiche Migrationsprojekte viele und wertvolle Erfahrungen gesammelt. In mir finden Sie die Experten, um Ihr Migrationsvorhaben gewinnbringend durchzuführen.
Sprechen Sie mich gerne an.
In meinen Kundenprojekten haben ich über zahlreiche Migrationsprojekte viele und wertvolle Erfahrungen gesammelt. In mir finden Sie die Experten, um Ihr Migrationsvorhaben gewinnbringend durchzuführen.
Sprechen Sie mich gerne an.
Blog
Ersetzt Künstliche Intelligenz (KI) uns menschliche Tester?
“Die KI ist ein mächtiges Werkzeug, das den manuellen, menschlichen Softwaretest verbessern, aber nicht ersetzen kann. Die menschlichen Tester sind weiterhin unverzichtbar für den Erfolg des Softwaretests. Sie müssen sich jedoch an die Veränderungen anpassen, die die KI mit sich bringt. Sie müssen lernen, wie sie mit der KI zusammenarbeiten können, um ihre Stärken zu nutzen und ihre Schwächen auszugleichen. Sie müssen auch ihre Fähigkeiten weiterentwickeln, um ihre Werte zu steigern und ihre Karriere zu fördern. Die Zukunft des Softwaretests ist also nicht eine Konkurrenz zwischen Menschen und Maschine, sondern eine Kooperation zwischen Mensch und Maschine. Die KI ist kein Feind, sondern ein Freund der menschlichen Tester.”
Warum sich Software weiterentwickeln muss
“Für die Weiterentwicklung von Software gibt es eine Vielzahl von guten Gründen. Allen gemein ist, dass ein kontinuierlicher und iterativer Prozess, der eine ständige Überwachung und Bewertung erfordert, unabdingbar ist. Die Weiterentwicklung von Software ist eine notwendige und lohnende Investition für die Schaffung eines qualitativ hochwertigen und nachhaltigen Produkts. Wenn auch Sie hochwertige und nachhaltige Software entwickeln wollen, sprechen Sie uns gerne an. Wir beraten Sie gerne im Softwareentwicklungsprozess und unterstützen Sie vom Anforderungsmanagement über die Entwicklung, bis hin zum Softwaretest.”
Kayla Bryant
“There live the blind texts. Separated they live in Bookmarksgrove right at the coast of the Semantics, a large language ocean.”
Lade...