02.01.2018

Es gibt Themen, die mit viel Donnerhall durch die technische Medienlandschaft gejagt werden. Andere Themen, obwohl ebenfalls von nicht geringer Bedeutung, erhalten diese Aufmerksamkeit nicht. Über eines dieser Themen sprechen wir in diesem Blog.

Die Bedeutung, Bereitstellung und Verwaltung von Testdaten in Datenbanken

Klingt erstmal nicht besonders spannend. Und doch steckt in diesem Punkt viel Potential!

Dieser Artikel hat seinen Fokus auf den Hintergründen, die für die Bereitstellung von Testdaten für eine Software mit Datenbank-Anbindung eine Rolle spielen. Daher besprechen wir die basischen funktionalen Tests, die jede Software durchlaufen muss und die das prinzipielle fehlerfreie Arbeiten einer Software sicherstellt, hier nicht.

Das Thema „Testdaten in Datenbanken“ ist nicht neu. Es gibt es schon so lange, wie es Datenbanken gibt. Gleichwohl schaffte es dieses Thema nie in den Fokus der öffentlichen Diskussion bzw. in den der Software-Entwickler.

So gut wie jeder Entwickler, der ein System mit Datenbank-Anbindung entwickelt, das Daten aus einer Datenbank liest, hat mit diesem Thema zu tun. Bis zum heutigen Tag erstellen bestimmt noch viele Entwickler per SQL-Skript einige Testdatensätze für Ihre Datenbank, um damit Ihre Systeme zu testen.

Da in heutigen Datenbanken die Datenmodelle gegenüber früher üblicherweise komplexer geworden sind, stößt diese Methodik schnell an ihre Grenzen bzw. der Zeitvorteil durch selbstgeschriebene Skripten verschwindet, wenn ein Datenmodell mehr als 30 Tabellen hat. Außerdem wird die Beherrschung der Abhängigkeiten der Tabellen untereinander (referentielle Integrität) zunehmend schwieriger, je größer das Datenmodell ist.

Der Entwickler befindet sich dabei in dem Dilemma, seine Anwendung anforderungsgerecht, d. h. auch unter realistischer Last, testen zu können aber gleichzeitig möglichst wenig seiner Ressourcen für die Bereitstellung adäquater Testdaten-Volumina aufzuwenden. Der Grund ist, dass ein umfassender Softwaretest auch heute noch oftmals als ‚Beiwerk‘ angesehen wird, für das der Entwickler nur das Nötigste an Zeit investieren soll. Leider sind das gegensätzliche Interessen, die auch üblicherweise nicht miteinander vereinbar sind und meistens zu Lasten aussagefähiger Testreihen geht.

Leider hängt der Software-Branche, teilweise berechtigt, immer noch das Vorurteil an, nicht vollständig ausgetestete Lösungen auf den Markt zu bringen. Frei nach dem Motto: Je schneller ein Software-Produkt auf dem Markt ist, desto schneller kann mit ihm Geld verdient werden. Dass das ein Irrglaube ist, kann man am Beispiel der Automobilindustrie studieren, die für aufgrund von Qualitätsmängeln nötig gewordene Rückrufaktionen erhebliche Summen aufbringen muss, vom Vertrauensverlust der Kunden ganz zu schweigen.

Daher ist auch die Softwarebranche gut beraten, nur Produkte auf den Markt zu bringen, die nach soliden Teststrategien ausgetestet sind.

Das Thema der Bereitstellung von Testdaten kann, je nach Anwendungsfall, als Stand-alone-Thema begriffen oder es muss ein größerer Rahmen aufgespannt werden. Die Trennlinie besteht darin, ob eine Software manuell oder automatisch getestet werden soll. Bei automatischen Tests kommen spezielle Test-Systeme zum Einsatz, die die Erzeugung von Testdaten als Teil des Testprozesses definieren und diese Eigenschaft als immanenten Teil ihres funktionalen Spektrums bereits mitbringen. Solche Test-Systeme sind in der Anschaffung hochpreisig und auch in der Einrichtung und im Betrieb stets mit nennenswerten Aufwand verbunden. Automatische Testsysteme sind im Allgemeinen nur in größeren Organisationen rentabel, die mit vielen Entwicklern parallel und agil an umfangreichen Software-Systemen arbeiten. Alleine um den sinnvollen und störungsfreien Betrieb solcher Testautomaten aufzusetzen und zu betreiben, sind oftmals mehrere Mitarbeiter erforderlich.

Die Alternative dazu ist das manuelle Testen einer Software. Auch dafür sind mittlerweile Lösungen am Markt verfügbar, die dem Softwareentwickler bzw. -tester eine weit reichende Unterstützung angedeihen lassen.

Ein erstes Problem liegt, wie bereits erwähnt, in der Komplexität des Datenmodells. Die allermeisten der existierenden SQL-Datenbanken arbeiten mit Fremdschlüsseln, d.h. sie können einen Datensatz in einer abhängigen Tabelle nur einfügen oder löschen, falls der referenzierte Satz bereits in der Elterntabelle existiert. Die Berücksichtigung dieser Abhängigkeiten bereitet keine Probleme, wenn das Modell nicht aus allzu vielen Tabellen besteht. Sind aber ca. 20 – 30 Tabellen im Datenmodell voneinander abhängig, wird es schon schwierig, über die Verzweigungen der Abhängigkeiten die Übersicht zu behalten. Jenseits von 50 – 60 voneinander abhängigen Tabellen wird das Ganze zu einem Vabanquespiel, das, unbeabsichtigt, während der Testdatenerzeugung für Fehler durch falsche Referenzierungen und damit für rapide steigende Aufwände sorgen kann. Hilfreich an dieser Stelle erwiese sich ein Tool, das den Entwickler von der Suche nach Abhängigkeiten zwischen den Tabellen seines Datenmodells befreit, da es diese idealerweise von sich aus erkennt und berücksichtigt. Der Entwickler braucht sich dann nur noch um das Aussehen seiner Testdaten zu kümmern.

Unter realistischen Testbedingungen ist es mit der Erstellung eines einzigen Testdaten-Szenarios selten getan. Alleine für den Test unter unterschiedlichen Lastbedingungen sind schon mehrere Szenarien erforderlich. Ganz zu schweigen von dem partiellen Test einer Software, der nicht die Erstellung neuer Testdaten in allen Tabellen erfordert und der bei der Bereitstellung von Testdaten parallel laufende Tests anderer Teile der Software nicht stört! In welcher Kombination auch immer, ist mit einer nicht geringen Anzahl verschiedener Testdaten-Szenarien zu rechnen, die im Fall einer manuellen Skripterstellung mit richtig viel Arbeit und damit Aufwand verbunden ist.

Dank einer grafischen Darstellung bieten manche Tools die Möglichkeit an, bestimmte Tabellen einer Datenbank vom Prozess der Testdaten-Erstellung auszunehmen. Dies ist erheblich schneller realisiert, als ein bestehendes SQL-Skript umzuschreiben.

Damit kommt auch der Organisation dieser Testdaten-Szenarien eine bedeutende Rolle zu. Ein für den Entwickler produktives Tool bündelt alle Szenarien unter einer Oberfläche und kann jedes einzelne auf Wunsch initiieren.

Die Zentralisierung der Arbeiten zur Testdaten-Erstellung kann aber noch weiter gedacht werden. Viele der DBMS-Hersteller bieten eigene, einfache Werkzeuge, wie z. B. SQL-Editoren, zur Erstellung und Ausführung von SQL-Skripten an. Das bedeutet für den Entwickler, falls er mit unterschiedlichen DBMS arbeitet, jedes mal den Wechsel auf ein anderes Werkzeug. Zeitsparender und auch von der Gewöhnung einfacher wäre hier die Verwendung eines einzigen Tools, das in jeder beliebigen SQL-Datenbank Testdaten erzeugen kann! Auch hierfür gibt es bereits Produkte, die diese Anforderung erfüllen. Diese basieren üblicherweise auf der ODBC/JDBC/.NET-Technologie, um damit alle verfügbaren DBMS am Markt ansprechen zu können. Zudem sind Datenbanktreiber für diese Technologien i. Allg. kostenfrei verfügbar.

Die Krönung der Unterstützung für einen Entwickler wäre natürlich, wenn ihm ein Tool jegliche Arbeit mit der Erstellung von Testdaten abnehmen würde! Wenn es
• Die Organisation der DB-Tabellen mittels Scan selbst erkennt
• Den einzelnen Tabellenfeldern automatisch Testdaten-Definitionen zuweist
Dann bräuchte der Entwickler nur noch die Anzahl der in der Datenbank zu erzeugenden Datensätze festzulegen (falls diese vom Standardwert abweicht) und dann nur noch den Start-Button zu drücken, um die Testdaten in der Ziel-Datenbank zu erzeugen.
Das wäre natürlich gegenüber den sonstigen Methoden und Verfahren ein unschlagbarer Produktivitätsvorteil, was u. U. die Kosten für die Anschaffung eines solchen Tools mit nur einem einzigen Anwendungsfall bereits amortisiert!

Eine solche ideale Nutzung ist natürlich nur denkbar, wenn die Anforderungen an die Testdaten nicht besonders hoch sind, da dabei Standard-Algorithmen verwendet werden, die darauf ausgelegt sind, eine theoretisch unbegrenzte Anzahl Testdatensätze produzieren zu können.

Wenn ein solches Tool dem Entwickler aber die Möglichkeit lässt, das Aussehen der Testdaten an den ihm wichtigen Stellen zu verfeinern, so hat er immer noch einen riesigen Produktivitätsvorteil, da die anderen Testdaten-Definitionen vom Tool selbst automatisch in Sekundenschnelle erzeugt werden.

Eine weitere Hilfestellung bieten manche Tools durch Visualisierung der Testdaten im Tool selbst, noch bevor sie in die Datenbank geschrieben werden.
Dadurch kann der Entwickler erkennen, welche Testdaten seinen Anforderungen genügen und welche nicht. Und er kann sehen, dass ggf. Testdaten-Beschreibungen noch fehlen.
Das erspart sehr viel Zeit gegenüber dem Fall, dass eine Kontrolle der Testdaten erst nach dem Schreiben in die Datenbank möglich ist und Fehler mühsam durch Rekursion der Prozessabläufe „Schreiben – Kontrollieren – Skript ändern – DB zurücksetzen – erneut Schreiben“ beseitigt werden müssen.

Fazit:
Das bereits erwähnte „Mauerblümchen-Dasein“ des Themas Testdaten-Management hat dank der heute verfügbaren, leistungsfähigen Werkzeuge keine Berechtigung mehr.
Mit Hilfe solcher Tools kann heute jeder Entwickler, der mit an einer SQL-Datenbank angeschlossenen Software arbeitet, seine Produktivität bei der Bereitstellung von Testdaten und deren Management signifikant erhöhen.
Mehr noch: Diese Tools stellen Funktionalitäten zur Verfügung, die er bisher schlicht nicht hatte bzw. nur mit unvertretbar hohem Aufwand hätte realisieren können.

Einige dieser Tools treten in moderner Optik auf, sind intuitiv bedienbar und bieten durchaus auch etwas für das Auge. Auch das kommt der Wertschätzung der Arbeit eines Entwicklers entgegen.

Zudem sind einige dieser Tools im unteren Preissegment zu haben, so dass der Kauf einer solchen Software im Vergleich zu den eingesparten Ressourcen eine lächerlich geringe Investition darstellt.

Auch im ureigensten Interesse, sich die Arbeit der Testdaten-Erstellung möglichst schmerzfrei zu machen, sollte jeder Entwickler die Anschaffung eines solchen Tools erwägen.

Es wird Zeit, die Unternehmen (und die Entwickler) für die Vorteile solcher Lösungen zu sensibilisieren. Sie sind am Markt verfügbar, teilweise für wenig Geld zu erwerben und bieten echtes Potential für eine Arbeitserleichterung der Entwickler und Tester.

Es wäre töricht, würden Unternehmen Wettbewerbsvorteile, die diese Tools bieten, ignorieren. Denn hier lässt sich tatsächlich eine deutliche Produktivitätssteigerung realisieren, die Unternehmen hilft, ihre Produkte fit für ihre Märkte zu machen und sich gegenüber ihren Konkurrenten besser zu positionieren.