Teststufen

Testdaten sind nicht gleich Testdaten
Die Qualität einer Software befindet sich zu verschiedenen Zeitpunkten ihrer Entwicklung in unterschiedlichen Zuständen und soll zu guter Letzt bei ihrer tatsächlichen produktiven Verwen­dung allen definierten Anforderungen/Kriterien entsprechen. Einen Nachweis, dass keine Fehler (mehr) vorhanden sind, kann das Softwaretesten nicht erbringen. Es kann lediglich festgestellt werden, dass bestimmte Testfälle erfolgreich waren. Dazu werden in den verschiedenen Entwicklungszuständen unterschiedliche Testverfahren angewandt.

Abnahme-, Integrationstests oder Regressionstests benötigen große Datenmengen, möglicherweise alle Produktionsdaten von Strukturanpassungen abgesehen,  mit wenige Änderungen an den Daten, ‘Produktionsqualität’. Testdaten für die Entwicklung sind zu reduzieren, zu modifizieren, sie müssen vielleicht anonymisiert werden.

Während einem Entwickler mehr am ‘white-box’-Testen liegt, (Abdeckung, Durchlauf aller Codezeilen), orientiert sich der Abnahmetest an der Spezifikation (tut das System was es soll?), dazwischen kann es alle Mischformen geben. Der Entwickler wird eher an geringen Datenmengen interessiert sein, ‘nicht mehr als für die Abdeckung notwendig’, während der Regressionstester schon gerne wüsste, ob das System ‘alle’ Produktionsdaten beherrscht. Während letzterer die Produktionsdaten für den Test möglichst wenig ändern möchte, natürlich müssen sie in das neue Datenmodell eingepasst werden, wird die Entwicklung stark modifizierte Daten benötigen, bis hin zu anonymisierten Daten. Dies sind nur zwei Bereiche in denen die am Test Beteiligten völlig unterschiedliche Anforderungen an ein ‘Testdaten-Management’ stellen. Es gibt weitere. Daraus folgt schon, dass ein Werkzeug, das nur eine Methode, ein Verfahren beherrscht, kaum den Anforderungen genügen wird, nicht für den jeweiligen Zweck optimal sein wird. Drei Schwerpunkte kann man leicht ausmachen: Erstens, schneller und kostengünstiger Aufbau und Erneuerung der Vorprod, zweitens, automatisierte Bereitstellung der Massendaten für Regression, Abnahme und Integration, und schließlich drittens, flexibles und leicht wiederholbares Zusammenstellen und Ergänzen von Testfalldaten für die Entwickler. Hinzu treten weitere Anforderungen wie Anonymisierung, Versionierung, Archivierung oder Nutzbarmachung historischer Daten.

XDM ist für den jeweiligen Zweck optimiert, es kommt immer die Methode zum Einsatz, die für die Aufgabe am besten geeignet und am kostengünstigsten ist: Klonen, Schema-Kopieren, Tabellen-Kopieren, EntLaden/Laden oder SQL (Insert, Update, Delete).  Allen gemeinsam ist die Autarkie-Eigenschaft, das heisst, sie sind über die Kommandozeile oder durch einen Scheduler ohne Bedienereingriff ausführbar.

Abnahme-Test
Die letzte Teststufe im Entwicklungszyklus erfordert möglichst reale Daten. Idealerweise wird direkt mit Produktionsdaten getestet, um sicherzustellen, dass die neue Anwendung in der Produktion problemlos funktioniert. Vor-Produktion (Vorprod) als konsistenter Klon der Produktion.
Regressions-Test
Ein typischer Blackbox-Test. Nicht nur die ‘neuen’ Funktionen sollen fehlerfrei arbeiten, sondern auch die ‘alten’ (die, die auch schon in der vorhergehenden Version zur Verfügung standen).  Die Testumgebung benötigt Massendaten. Zur Versorgung am besten geeignet sind Tabellen oder Schemakopien mit allen Hilfsobjekten (Indexes, Views, etc.). Die Daten sollten schnell und kurzfristig erneuert werden können (Refresh). Siehe dazu auch XDM-ICEBOX.
Integrations-Test
Der Integrationstest bzw. Interaktionstest testet die Zusammenarbeit voneinander abhängiger Komponenten. Der Testschwerpunkt liegt auf den Schnittstellen der beteiligten Komponenten und soll korrekte Ergebnisse über komplette Abläufe hinweg nachweisen. Meist werden Massendaten benötigt, möglicherweise nur eine Teilmenge (Vor-) Prod, siehe oben. Umbenennungen sind evtl. notwendig (Schema, Owner), auch strukturelle Anpassungen (neue Version, neue Datentypen).
Komponenten-Test
Der Modultest, auch Komponententest oder Unittest genannt, ist ein Test auf der Ebene der einzelnen Module der Software. Testgegenstand ist die Funktionalität innerhalb einzelner abgrenzbarer Teile der Software (Module, Programme oder Unterprogramme, Units oder Klassen). Die Testdatenversorgung mehr Flexibilität und Varianz (Selektion aus verschiedenen Datenquellen), die Ausführungsgeschwindigkeit ist hier meist von untergeordneter Bedeutung, stattdessen treten flexible Datenergänzung und Veränderung, auch Generierung einzelner neuer Spalten in den Vordergrund, eventuell ist Anonymisierung erforderlich.
Funktions-Test
Hier werden oft schon ‘handverlesene’ Datensätze gebraucht, Daten selektieren, modifizieren, generieren, einbetten in vorhandenes: Insert, Update, Merge. Wichtig ist  relationale Vollständigkeit und Stimmigkeit. XDM mit seiner Table Level Copy Funktion ist hier die ideale Variante. Natürlich ist auf dem Host BCV5/6 ein wichtiger Punkt der mit seinen Vorteilen noch mal separat erklärt werden muss.
Unit-Test
Ähnlich Funktionstest. Siehe auch Icebox für alle Varianten von Integrations- bis Unit-Test.

Natürlich ist die hier verwendete Typisierung nur als ein Beispiel aufzufassen, im konkreten Unternehmen kann diese auch völlig anders vorgenommen werden. Es geht hier nur darum, zu verstehen, dass ganz unterschiedliche Methoden zum Einsatz kommen müssen, um der Zielsetzung der Effizienz gerecht zu werden. Die gemeinsame Klammer um diese Methoden sollte die einheitliche Systematik hinsichtlich der Bedieneroberfläche und der Durchführung von Datenbeschaffungsaufträgen sein.