Testdatenmanagement » Basisdaten für: GUI-Test, TDD & Refactoring

von #ctpm · Veröffentlicht 9. Oktober 2018 · Aktualisiert 9. Oktober 2018

CTPM » Business • Health • Travel • Move - Stefan Müller

Autor: Stefan Müller CEO & Senior Consultant

CTPM » Business • Health • Travel • Move

Köln • Berlin • Lindlar im Bergischen Land

Event Katalog 📅

Testdatenmanagement synthetische Testdaten

Aufgabe – Testdatenmanagement mit synthetischen Testdaten!

Maximale Optimierung der Softwarequalität – gleichmäßige Testdaten, kleine Testteams, geringere Kosten für Systemlandschaft, Unterstützung der am Markt vertretenen Testsuiten und einheitliche Testfälle: von der User Story (Analyse) bis zum Sprint Review (Abnahme).

Lösungsansatz – Basis: Oracle mit dyn. SQL / PLSQL!

Das Testen neuer Softwarerelease ist in der heutigen Zeit eines, wenn nicht sogar das Nadelöhr der IT. Komplexe und vielfältige Testszenarien sind erforderlich, um den nicht zuletzt von Wirtschaftsprüfern geforderten Tiefgang der Qualitätssicherungskonzepte in der Softwareentwicklung auch hinsichtlich der Revisionssicherheit zu gewährleisten. Um den Anforderungen gerecht zu werden, braucht es einen maximalen Einsatz von Automatisierungstechniken. Neben GUI-Test sind auch die Netzpläne der Batchabläufe in den Test zu integrieren und deren Ergebnisse (Tracefile, Deltareport, …) sind geeignet zu analysieren und zu reporten.

Die QS-Abteilungen/-Teams oder auch die AGILEN-/SCRUM-Teams gehen unterschiedliche Wege, um ihrer Aufgabe der Qualitätssicherung von Softwareprodukten gerecht zu werden.

Produktionsdaten

Zyklisch (täglich – wöchentlich) werden 1:1 die Daten der Produktion den Testteams auf eigenen Umgebungen als Basis für ihre Testfälle zur Verfügung gestellt.

eingefrorene Datenstände

In größeren Zyklen (monatlich – je Quartal) werden 1:1 die Daten der Produktion den Testteams auf eigenen Umgebungen als Basis für ihre Testfälle zur Verfügung gestellt.

FLASHBACK

Historiendaten unter Verwendung der ORACLE-Datenbanktechnik. Die Daten werden der Produktion den Testteams 1:1 auf eigenen Umgebungen als Basis für ihre Testfälle zur Verfügung gestellt.

Deltadaten – optimiert für die Testszenarien

Gezielte Datenextraktionen von der Produktion werden den Testteams auf eigenen Umgebungen als Basis für ihre Testfälle zur Verfügung gestellt.

Die obige Methodenauswahl hat gemeinsame Stärken und Schwächen, die ich hier grobgranular in einer PRO/CONTRA-Analyse aufliste:

Vorteil

aktuelle fachliche Abläufe
Performancetest möglich -bei identischer Systemlandschaft- und vollständigem Datenbestand

Nachteil

hohe Anforderung an die Systemlandschaft
sensible Daten – sicherheitskritisch Originaldaten – (ggf. anonymisiert)
zeitintensiver Aufbau
Verfügbarkeit währen Initialisierung nicht gegeben
hoher Administrationsaufwand
wenig Automatisierungspotential für GUI-Testsuiten (volatile Testdaten)
geringer Automatisierungsgrad in der Deltaanalyse (SOLL/IST-Vergleich)

Testdatenmanagement – DML Sample

Ich verrate Ihnen sicherlich nichts Neues, wenn ich noch einmal die zuvor genannten Vorteile aufgreife und feststelle, dass ein Performancetest nur unter realen Bedingungen durchgeführt werden kann. Selbst ein interpolieren von Zeiten/Datenvolumen ist nur eine ungefähre „Hausnummer“, die in der heutigen sehr komplexen/globalen Systemlandschaft häufig sehr ungenau ist.

Die Generierung von synthetischen Testdaten wird hier keine vollständige Abhilfe schaffen, aber diese Methode ist zumindest im Stande, durch gleichförmige Abarbeitung der Testszenarien auch hierfür Schwellwerte zu ermitteln und diese in die Deltaanalyse einfließen zu lassen.

Die obigen Ansätze haben mehrere Nachteile gemeinsam! Eine Auswahl, die ich in diesem Rahmen etwas genauer betrachten möchte:

Strukturelle Änderungen – Metadaten
Fehlende fachliche Grundlage
Initialisierung

Strukturelle Änderungen – Metadaten – Metadatenänderungen sind eine Herausforderung für jede Testmethode. Nur welche kann leichter damit umgehen. Originaldaten werden faktisch einer Datenmigration unterzogen. Die damit verbundenen Programmlösungen und Laufzeiten führen zur Bindung von Entwickler-Ressourcen und CPU-Zeiten für den Migrationslauf. Somit sind alle Verfahren, die auf Originaldaten basieren hier sehr anfällig.

Synthetische Daten werden ohnehin generiert, sodass lediglich der Erstellungsprozess, also die Software zum Einfügen der Daten, modifiziert werden muss. Die Entwickler-Ressourcen schlagen hier also auch zu buche, aber ein Migrationslauf entfällt und dieser ist Erfahrungsgemäß der größere „Zeitfresser“. Die Entwicklerzeit kann erheblich gekürzt werden, wenn wir uns die Regel 4 der 12 goldenen Regeln nach Codd für relationale Datenbank-Modelle in die Erinnerung rufen.

Alle Daten, (auch die Datenbank selbst) wird in Tabellen gespeichert. Die Daten, Die Datenbank und Tabellen werden alle auf einer Systemkatalog Ebene gespeichert. Dadurch wird die relationale Datenbank über eine Datenbanksprache abgefragt werden können. 4. Katalogisierter Relationen-Struktur nach Codd

D.h. Zeilen/Spalten-Strukturen einer Benutzer-Tabelle in der Datenbank werden ebenfalls in internen Katalogtabellen gesammelt, sodass per Standard-SQL diese wieder zum Vorschein gebracht werden können. Ein Entwickler ist nun im Stande, diese zur Herstellung von dynamischen PL/SQL-Blöcken zu nutzen, welche individuell auf die gerade vorliegende Satzstruktur automatisch angepasst werden.

Fehlende fachliche Grundlage – Der Einsatz von Echtdaten suggeriert, dass ein Tester kaum näher einen bestimmten Testfall beschreiben kann. Betrachten wir den Gedanken etwas genauer. „Gelebte Daten“ liefern zum Ende hin das, was die Programmlogik in ihrem aktuellen Stand vorgibt. Eine Qualitätsbewertung wird hierbei nicht vorgenommen. Shit-IN/Shit-OUT kommt nicht selten vor.

Testadtenmanagement – Dokumentation

Warum sind die synthetischen Daten hier besser? Ganz einfach, schon bei der Vorgabe wird der ganze Testfall betrachtet. INPUT- und OUTPUT-Wert werden einmal analysiert und im Anschluss manifestiert. Die Folge: Wir besitzen eine klare Vorstellung bzgl. der SOLL- und IST-Daten und somit ist eine Deltaanalyse inkl. Reporting spielend möglich. Hinzu kommt, die Testfallvorgabe inkl. Daten kann schon in den Konzeptionierungsprozess integriert werden. Fachbereiche, Product Owner, Entwickler und Tester erhalten in einem sehr frühen Stadium des möglichen Sprints oder Projektverlaufes ein klares Bild vom Ergebnis. Entwickler können zudem bedingt der synthetischen Testdaten mit einer Realität die Qualität ihrer Arbeit prüfen, die in der Produktion noch gar nicht existieren.

Test Driven Development (TDD) – Testgetriebene Entwicklung ist hier auch ein Aspekt, der bequem unterstützt und betrachtet werden kann. Der Sollzustand der Daten wird definiert, somit hat der Entwickler ein klares Ziel, auf das er sich konzentriert. Die Erstellung von unnötigem Programmcode wird hierdurch eingedämmt bis hin zu vollständig unterbunden. Denn sind die Sollwerte einmal nach einem gezielten Testlauf erreicht worden und bedingt der Prüfung der übrigen Testfälle keine Seiteneffekte eingetreten, ist der Entwicklungszyklus beendet.

Refactoring – der „Aufräum-Prozess“ des Programmcodes wird ebenfalls effektiver unterstützt. Auch hier gilt, solange nach einer Änderung die geforderten Sollwerte erzielt werden, ist die Welt noch in Ordnung. So entsteht schlanker effektiver Quellcode!

Initialisierung – Systeme müssen eingerichtet werden. Programmstände werden aktualisiert. Systemordner zur Verfügung gestellt und allgemeine/spezielle Rechte werden gepflegt. Soweit so gut, aber wie sieht es mit einem vertretbaren Aufwand im Fall der Wiederholung eines Testfalles aus. Echtdaten gibt es genug. Richtig! Aber, diese sind oft sehr unterschiedlich in ihrer fachlichen Qualität und somit zur Standardisierung eher ungeeignet. Meist folgt zur Testwiederholung ein Reset. D.h. die Systeme werden abermals neu installiert und der notwendige Datenbestand auf Basis eines DUMP’s nach geraumer Zeit dem Tester wieder zur Verfügung gestellt.

Sind die synthetischen Testdaten nach meinem Verständnis organisiert und eingerichtet, so lassen diese sich wiederholt für Testläufe heranziehen und liefern bis auf Änderung der ID’s und Zeitstempel in ihrer fachlichen Bedeutung den gleichen Inhalt. Parallel geführte Mappingtabellen liefern den weiterverarbeitenden Testsystemen (GUI-Test) die benötigten Informationen zur eindeutigen Identifizierung des Testfalles. Hierbei entsteht ein Gefühl von Echtzeitverarbeitung.

Weitere wichtige Stärken der synthetischen Testdatengenerierung führe ich gleich auf, wobei die Liste keinen Anspruch auf Vollständigkeit besitzt. Ich bin jedoch davon überzeugt, dass schon alleine die folgenden Punkte – in Verbindung mit den vorherigen Ausführungen – das Potential, synthetische Testdaten für Ihr Unternehmen zu erstellen, aufzeigt:

Einbindung in verbindliche Abnahmeprozesse (Sprint Review)
Unterstützung des DevOps-Ansatzes
Revisionskonforme/-sichere Testverläufe und Reporting
Senkung der Kosten für die Systemlandschaften
höherer Automatisierungsgrad und dadurch kleine Teamstruktur
Skalierung der Testressourcen jederzeit möglich

Testdatenmanagement – HTML

GUI-Testsuiten, die keinen oder einen eher ungeeigneten Generator von synthetischen Testdaten besitzen, kann von „außen“ geholfen werden. Einzige Voraussetzung hierfür ist das Integrieren eines interaktiven Aufrufprozesses für die Programmroutinen des externen Datengenerators. Alternativ füllt der Individual-Datengenerator vor dem GUI-Test per manuellen Aufruf die Zielumgebung, dieser wiederum kann auch in den Aufbauprozess (DEPLOY) der Testumgebung eingebunden werden.

Der Ansatz von GUI-Testsuiten, ein eigenes Datenmodell zu entwerfen und vor Teststart die Daten per DML-Anweisung (INSERT) in die Datenbank zu „pumpen“, ist bei einfachen Datenstrukturen ohne Constraint- und Trigger-Landschaft noch denkbar. Komplexe Ladeprozesse, die auch die implementierten Unternehmensregeln (Constraint/Trigger) berücksichtigt, sind individuell zu entwickeln. Dieses Fundament zu schaffen ist zunächst etwas aufwendiger, dafür aber nachhaltig! Nutzt der Entwickler bei diesem Ansatz die existierende Programmlogik, wird bei jedem Testszenario z.B. das Anlegen der Testdaten direkt mit überprüft, sodass wir uns bereits im Bereich eines ganzheitlichen Systemtestes befinden. Ergänzend kann die SOLL-/IST-Datenstruktur für den Deltavergleich mit dem gleichem Mechanismus abgebildet werden.

Möchten Sie von unserem langjährigen Expertenwissen in der Testautomation mittels synthetischer Testdaten partizipieren? Großkunden, Branchenvielfalt, unterschiedliche Projekteinstiege und wechselnde Rollen, haben eine Vielzahl von „wertvollen Eindrücken“ hinterlassen, die wir Ihnen in Form von Coaching-/Management-/Developer-MANPOWER anbieten.