Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: dpunkt.verlag
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2018
Testdaten werden in jedem Softwareentwicklungsprojekt benötigt. Das Management von Testdaten stellt sicher, dass diese jederzeit bedarfs-, zeit- und regelgerecht bereitstehen, und erhöht so die Effizienz und die Qualität des Testens. Dieses Buch bietet eine umfassende Einführung in Testdaten und ein effizientes Testdatenmanagement. Dabei werden sowohl fachliche als auch technische Konzepte vorgestellt. Es gliedert sich in drei Teile: - Teil I erläutert die Eigenschaften von Testdaten, die Anforderungen, Probleme und Risiken im Umgang mit ihnen sowie das Gewinnen und Archivieren. Auch auf Regelungen zum Datenschutz und auf Testdaten in der Cloud wird eingegangen. - Teil II behandelt Modelle und Best Practices für das Testdatenmanagement, die Organisation und Test-Rollen sowie Werkzeuge und Metriken für Testdaten und Testdatenmanagement. - Teil III enthält ein Vorgehen zum Einführen bzw. Verbessern eines Testdatenmanagements sowie Checklisten, Mustergliederungen und Fragenkataloge.Zahlreiche Erfahrungsberichte und Praxisbeispiele geben Einblicke in die reale Welt des Testdatenmanagements und erlauben dem Leser einen direkten Transfer zu seiner täglichen Arbeit.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 571
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Beliebtheit
Ähnliche
Janet Albrecht-Zölch ist seit 2007 in verschiedenen Positionen im Bereich Softwaretest und Testmanagement tätig. Neben ihrer beruflichen Tätigkeit schloss sie 2014 den Masterstudiengang Informatik an der Fernuniversität in Hagen ab. Frau Albrecht-Zölch ist ISTQB® Certified Tester Advanced Level – Testmanagement und seit 2015 Mitglied des Conference Board des German Testing Day sowie des Local Board der German Testing Night. Ihre besonderen Interessen liegen in den Bereichen Qualitätssicherung, Testprozessverbesserung und Testdatenmanagement.
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:
www.dpunkt.plus
Janet Albrecht-Zölch
Testdaten und Testdatenmanagement
Vorgehen, Methoden und Praxis
Janet Albrecht-Zölch, [email protected]
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz: III-satz, www.drei-satz.de
Herstellung: Susanne Bröckelmann
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Buch978-3-86490-468-8
PDF978-3-96088-192-6
ePub978-3-96088-193-3
mobi978-3-96088-194-0
1. Auflage 2018
Copyright © 2018 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1
Vorwort
Wozu ein Buch über Testdaten und Testdatenmanagement?
Nun, jeder Tester benötigt Testdaten zum Testen seines Testobjekts! Daraus ergibt sich automatisch der Bedarf, sich mit dem Thema Testdaten und einem zielführenden Testdatenmanagement zu befassen. Die gewichtigste Motivation stellen die folgenden fünf Punkte dar:
Komplexität und Vernetzung
Dank verschiedener Fortschritte in der IT sind wir heute in der Lage, IT-Systeme und Anwendungen zu entwickeln, die sehr große Mengen an Daten in sehr kurzer Zeit verarbeiten können. Darüber hinaus nehmen Anzahl und Komplexität der Systeme sowie der Grad ihrer Vernetzung zu. Dies stellt uns vor allem bei Integrationstests vor große Herausforderungen in Bezug auf die Testdaten.
Verbreitung von Software
Zudem dringt Software in immer mehr Anwendungsgebiete vor. Auch dadurch erhöht sich der Bedarf, die Qualität und Sicherheit der Software abzusichern. Dies gilt vor allem auch für den Bereich der eingebetteten Systeme und Data-Warehouse-Lösungen.
Kosten
Ein bezifferbarer Grund für ein professionelles Testdatenmanagement liegt in den Kosten, die auf Bereitstellung und Wartung von Testdaten entfallen. Folgekosten aufgrund fehlender Testdaten, mangelnder Qualität derselben oder ineffizienter Handhabung der Testdaten gefährden den Erfolg des Softwareentwicklungsprojekts. Unterstützung bietet Ihnen dieses Buch u.a. beim Erstellen eines Business Case für das Testdatenmanagement.
Datenschutz
Wenn von Daten die Rede ist, geht es auch um Datenschutz. Das vorliegende Buch zeigt, wie Sie die Aspekte des Datenschutzes im Test umsetzen können und wie Sie so das Risiko von Datenschutzverletzungen und deren Konsequenzen mindern können.
Wissensbasis
Softwaretesten wird immer anspruchsvoller. Gleichzeitig wächst der Markt für Werkzeuge rund um den Softwaretest. Testdatenmanagementsysteme versprechen die Lösung all Ihrer Testdatenprobleme. Dieses Buch führt Sie in die Grundlagen von Testdaten und Testdatenmanagement (TDM) ein. Es versetzt Sie in die Lage, den Leistungsumfang von Testdatenmanagement-Werkzeugen realistisch einzuschätzen. Zudem unterstützt Sie dieses Werk mit der Beschreibung eines möglichen Vorgehens beim Aufbauen eines eigenen Testdatenmanagements.
Bedarf
Meine persönliche Motivation zu diesem Buch ergibt sich aus eigener Erfahrung: Im Laufe meiner Berufsjahre stand ich in der Rolle als Softwaretesterin und noch stärker als Testmanagerin immer wieder vor der Frage, wie ich zu den Testdaten für meine Testfälle komme oder wie ich ein Testprojekt sinnvoll mit Testdaten versorgen kann. Mit diesen Fragen war ich nicht allein.
So begann ich zu recherchieren. Ich sprach mit Kolleginnen und Kollegen, las Bücher zum Softwaretesten, schloss mich einer Arbeitsgruppe zum Testdatenmanagement an und fahndete im Internet nach Antworten auf meine Fragen. Ein deutsch- oder englischsprachiges Buch zum Thema Testdatenmanagement war nicht aufzufinden, stattdessen eine große Anzahl verschiedener Publikationen, die sich zumeist einzelnen Aspekten des Themas widmeten.
Daher beschloss ich, die Rechercheergebnisse und meine eigenen Erfahrungen zu einem Buch zu verarbeiten. Dabei greife ich auf Erkenntnisse zurück, die ich in klassischen und in agilen Projekten erwarb, beim Testen von Webapplikationen und Desktop-Anwendungen, im Bereich der öffentlichen Verwaltung und im Privatsektor. Ich hoffe, Sie haben Freude beim Lesen und finden Ihrerseits Antworten auf einige Ihrer Fragen.
Dank
Ein Buch zu verfassen bedeutet eine ganze Menge Arbeit, die ein Autor nicht allein leistet. Wahrscheinlich ist das einer der Gründe, warum es noch kein Buch zum TDM gab.
Mein Dank gebührt daher den Personen, die dieses Werk mit ihren Erfahrungsberichten bereichern: Helmut Pichler, Stephan Grünfelder und eine Person, deren Name aus Rücksicht auf den Arbeitgeber ungenannt bleibt. Mit Herbert Stauffer tauschte ich mich zum Thema Werkzeuge und Werkzeugkategorien aus. Vielen Dank für all die freundlichen E-Mails, Telefonate und dafür, dass die Kollegen ihre knappe Zeit mit mir teilten.
Einen wirkungsvollen Beitrag leisteten auch die Reviewer dieses Buches, vor allem Matthias Daigl, die mit ihrer konstruktiven Kritik und zahlreichen Anregungen maßgeblich zur Qualität des Buches beigetragen haben. Vielen Dank dafür!
Den in diesem Buch zitierten Autoren danke ich sehr herzlich. Sie trugen dazu bei, dass ich beim Schreiben das eine oder andere dazulernte.
Mein besonderer Dank gilt Christa Preisendanz, meiner Lektorin, für ihr Vertrauen und ihre Geduld sowie dem dpunkt.verlag, der dieses Buch veröffentlicht. Nicht zuletzt danke ich meiner Familie für ihre Unterstützung und Geduld.
Janet Albrecht-ZölchMünchen, im Oktober 2017
Inhaltsübersicht
1Einleitung
Teil ITestdaten
2Testdaten – ein Überblick
3Eigenschaften von und Anforderungen an Testdaten
4Probleme mit Testdaten und Risiken
5Gewinnen und Archivieren von Testdaten
6Testdaten und Datenschutz
Teil IITestdatenmanagement
7Testdatenmanagement – ein Überblick
8Vorgehensweisen im Testdatenmanagement – Modelle
9Vorgehensweisen im Testdatenmanagement – Best Practices
10Organisation – Rollen im Testdatenmanagement
11Werkzeuge für Testdaten & Testdatenmanagement: Anforderungen und Kategorien
12Metriken für Testdaten & Testdatenmanagement
13Testdaten & Testdatenmanagement im Kontext
Teil IIIPraxis
14Vorgehen zum Verbessern eines Testdatenmanagements
15Checklisten, Mustergliederungen, Fragenkataloge
Anhang
AAbkürzungen
BGlossar
CLiteratur
Index
Inhaltsverzeichnis
1Einleitung
Teil ITestdaten
2Testdaten – ein Überblick
2.1Begriffe Testdaten, ideale Testmenge, gute Testdaten
2.1.1Testdaten
2.1.2Gute Testdaten
2.1.3Ideale Testmenge
2.2Kategorien von Testdaten
2.2.1Kategorien nach Reimann
2.2.2Kategorien nach Chace
2.2.3Testdatentypen nach Jagers und Kollegen
2.2.4Definition Testdatenkategorien
2.3Testdatenbestandstypen
2.4Unterscheidung in Primär- und Sekundärdaten
2.5Unterscheidung nach Testobjekt in Testdatentypen
2.6Ergebnisse eines Testlaufs: Soll, Ist, Testergebnis
2.7Metadaten für Testdaten
2.8Testdaten, Testfälle, Testentwurfsverfahren und Testabdeckung
2.9Zusammenfassung
3Eigenschaften von und Anforderungen an Testdaten
3.1Eigenschaften von Testdaten
3.2Anforderungen an Testdaten – ein Überblick
3.3Inhaltliche Anforderungen
3.4Technische und organisatorische Anforderungen
3.5Wirtschaftliche und rechtliche Anforderungen
3.6Wunsch und Wirklichkeit
3.7Erheben und Dokumentieren von Anforderungen an Testdaten
3.8Zusammenfassung
4Probleme mit Testdaten und Risiken
4.1Häufige Probleme mit Testdaten
4.1.1Probleme mit Testdaten, die auf den Faktor Mensch zurückzuführen sind
4.1.2Probleme mit Testdaten, die in den Testdaten selbst liegen
4.1.3Probleme aufgrund fehlerhafter, ungeeigneter oder vergessener Testdaten
4.1.4Herausforderungen bei Gewinnung, Herstellung und Wartung von Testdaten
4.1.5Organisatorische Problemstellungen
4.2Risiken bei Testdaten
4.2.1Fehlende und fehlerhafte Testdaten als Produktrisiko – unentdeckte Fehler
4.2.2Fehlende und fehlerhafte Projektrisiko als Projektrisiko – Verzögerungen und spät entdeckte Fehler
4.3Zusammenfassung
5Gewinnen und Archivieren von Testdaten
5.1Wege zum Gewinnen von Testdaten
5.1.1Herkunft der Daten: Echtdaten versus synthetische Daten
5.1.2Vorgehen: Ansätze zum Aufbauen von Testdatenbeständen
5.1.3Vorgehen: Konstruktion von Testdaten
5.1.4Zufallsdaten
5.1.5Selbstbeschreibende Testdaten
5.1.6Migrieren von Testdaten
5.2Quellen für das Gewinnen von Testdaten
5.2.1Ermitteln von Anforderungen an Testdaten oder Testdaten aus Artefakten des Softwareentwicklungsprojekts
5.2.2Welche Art Information aus welcher Quelle kommen kann
5.2.3Quellen für das automatisierte Generieren von Testdaten
5.3Wie bekommt man die Testdaten in das zu testende System?
5.3.1Direktes Eingeben über Systemschnittstellen
5.3.2Kopieren und Editieren
5.3.3Spezialisierte Testdatenmanagementlösung
5.3.4Automatisieren von Testeingaben
5.4Trennen der Testdaten von Testfällen
5.5Trennen und Reservieren von Testdaten
5.6Versionieren von Testdaten
5.7Archivieren von Testdaten
5.7.1Wozu archivieren?
5.7.2Vor dem Archivieren: Bereinigung der Testumgebung
5.7.3Wie archivieren?
5.7.4Was archivieren?
5.7.5Datenschutz für archivierte Testdaten
5.8Zusammenfassung
6Testdaten und Datenschutz
6.1Regelungen zum Datenschutz
6.1.1EU-Datenschutzrichtlinie
6.1.2Europäische Datenschutz-Grundverordnung (DSGVO)
6.1.3Bundesdatenschutzgesetz (BDSG)
6.1.4Datenschutz auf Länderebene, branchen- oder unternehmensbezogene Vorgaben
6.1.5Standards zum Datenschutz in der Cloud
6.2Anonymisieren, Pseudonymisieren, Verfremden, Maskieren
6.2.1Anonymisierung
6.2.2Pseudonymisierung
6.3Testdaten in der Cloud
6.3.1Testumgebungen in der Cloud
6.3.2Datenschutz nach DSGVO
6.3.3Datenschutz nach ISO/IEC 27018
6.4Zusammenfassung
Teil IITestdatenmanagement
7Testdatenmanagement – ein Überblick
7.1Begriff Testdatenmanagement
7.1.1Testdatenmanagement-Begriff nach ISTQB® – datenorientiert
7.1.2Testdatenmanagement-Begriff nach Gawlik – Mischform, Erzeugung von Testdaten im Fokus
7.1.3Testdatenmanagement-Begriff nach Kruse – managementorientiert
7.1.4Testdatenmanagement-Begriff nach Haller – managementorientiert, Werkzeuge
7.1.5Testdatenmanagement-Begriff nach Haber – prozessorientiert
7.1.6Testdatenmanagement-Begriff nach German Testing Board – Mischform
7.1.7Der Begriff Testdatenmanagement
7.2Wozu Testdatenmanagement?
7.3Ziele des Testdatenmanagements
7.4Inhalte des Testdatenmanagements
7.4.1Testdaten
7.4.2Prozesse, Aktivitäten, Rollen, Artefakte, Standards
7.4.3Organisationsstrukturen
7.4.4Werkzeugunterstützung
7.4.5Regularien
7.5Wie ist das Testdatenmanagement in den Testprozess eingebunden?
7.5.1Testplanung und -steuerung → Testdaten als Testmittel, Werkzeuge
7.5.2Analyse und Design → Testdatenanforderungsermittlung, Testdatendesign
7.5.3Testumgebung, Deployment → Testdaten: Umgebungsdaten, Bestandsdaten
7.5.4Realisierung und Durchführung → Testdatenerstellung (Bestandsdaten, Eingabedaten u. a.)
7.5.5Testauswertung und -bericht → Aussage zu Testdaten
7.5.6Abschluss der Testaktivitäten → Archivierung der Testdaten, Übergabe an die Wartungsmannschaft
7.5.7Testdatenmanagement ist überall
7.6Der richtige Zeitpunkt
7.7Abgrenzung Testdatenmanagement und Datenmanagement
7.7.1Der Begriff Datenmanagement
7.7.2Datenmanagement versus Testdatenmanagement
7.7.3Konzepte und Techniken übertragbar
7.8Abgrenzung Testdatenmanagement und Konfigurationsmanagement
7.8.1Begriffe Konfigurationsmanagement, Konfiguration, Konfigurationsobjekt
7.8.2Testdaten und Testdatenmanagement versus Konfiguration und Konfigurationsmanagement
7.8.3Testdatenmanagement mit Konfigurationsmanagement
7.9Zusammenfassung
8Vorgehensweisen im Testdatenmanagement – Modelle
8.1Prozess nach ASQF-Arbeitsgruppe Testdatenmanagement
8.1.1Inhaltsüberblick (Begriff Testdaten & Testdatenmanagement, Rollen, Werkzeuge, Dokumentation)
8.1.2Eignung/Einschränkung
8.1.3Was bietet die Vorgehensweise?
8.1.4Rollenkonzept
8.1.5Das Vorgehen gemäß diesem Prozess
8.1.6Methoden und Techniken
8.1.7Dokumentation
8.1.8Werkzeuge
8.1.9Prozesse, Schnittstellen zu anderen Prozessen
8.1.10In drei Sätzen
8.2Framework von Samuel T. Redwine Jr.
8.2.1Inhaltsüberblick (Begriff Testdaten & Testdatenmanagement, Rollen, Werkzeuge, Dokumentation)
8.2.2Eignung/Einschränkungen
8.2.3Was bietet die Vorgehensweise
8.2.4Das Vorgehen gemäß dieser Best Practice
8.2.5Methoden und Techniken
8.2.6Dokumentation
8.2.7Werkzeuge
8.2.8Prozesse, Schnittstellen zu anderen Prozessen
8.2.9In drei Sätzen
8.3Test Data Management Framework von Borghers und Demey
8.3.1Ansatz
8.3.2Aufbau des Rahmenwerks
8.3.3In drei Sätzen
8.4Weitere Modelle im Überblick
8.4.1Prozessrahmenwerk Test Data Management nach Nittur und Sengupta
8.4.2Strategie nach Murthy und Channagiri
8.5Zusammenfassung
9Vorgehensweisen im Testdatenmanagement – Best Practices
9.1Best Practice nach Chace
9.1.1Inhaltsüberblick (Begriff Testdaten & Testdatenmanagement, Rollen, Werkzeuge, Dokumentation)
9.1.2Eignung/Einschränkungen
9.1.3Was bietet die Vorgehensweise
9.1.4Das Vorgehen gemäß dieser Best Practice
9.1.5Methoden und Techniken
9.1.6Dokumentation
9.1.7Werkzeuge
9.1.8Prozesse, Schnittstellen zu anderen Prozessen
9.1.9In drei Sätzen
9.2Best Practice nach Haller
9.2.1Inhaltsüberblick (Begriff Testdaten & Testdatenmanagement, Rollen, Werkzeuge, Dokumentation)
9.2.2Eignung/Einschränkungen
9.2.3Was bietet die Vorgehensweise
9.2.4Werkzeuge
9.2.5Rollenkonzept
9.2.6Das Vorgehen gemäß dieser Best Practice
9.2.7Methoden und Techniken
9.2.8Dokumentation
9.2.9Prozesse, Schnittstellen zu anderen Prozessen
9.2.10In drei Sätzen
9.3Weitere Best Practices im Überblick
9.3.1Best Practice nach Schauber und Leimsner
9.3.2Best Practice nach Govindasamy und Murugesan
9.3.3Best Practice nach Madia
9.4Zusammenfassung
10Organisation – Rollen im Testdatenmanagement
10.1Testdatenmanagement-Rollen
10.1.1Der Testarchitekt als oberster Verantwortlicher (nach ISTQB®)
10.1.2Der Testdatenarchitekt (Test Data Architect)
10.1.3Testdatenmanager, Testdatenmodellierer, Testdatenrealisierer
10.1.4Testdatenmanager und Testdatenteam
10.1.5Testdaten-Consultant, Testdaten-Designer, Solution Implementer, Technical Operator
10.2Test-Rollen ergänzt um Testdatenmanagementaktivitäten
10.2.1Ergänzen vorhandener Tester-Rollen um Testdatenmanagementaktivitäten, eine optionale Testdatenmanagement-Rolle
10.2.2Keine Testdatenmanagement-Rollen, stattdessen zu vorhandenen Rollen des Testteams zuordnen
10.2.3Spezialisierung einer vorhandenen Rolle
10.3Personalunion versus Eigenständigkeit
10.4Zentrales oder dezentrales Testdatenmanagement?
10.5Zusammenfassung
11Werkzeuge für Testdaten & Testdatenmanagement: Anforderungen und Kategorien
11.1Was Testdatenmanagement-Werkzeuge leisten sollen: Anforderungen an Testdatenwerkzeuge
11.1.1Anforderungen an Werkzeuge zum Erstellen von Testdaten
11.1.2Anforderungen Testdatenmanagement-Werkzeuge
11.1.3Weitere Anforderungen
11.2Kategorien von Testdatenmanagement-Werkzeugen
11.2.1Analyse- und Data-Mining Werkzeuge
11.2.2Werkzeuge für das Erstellen oder Bearbeiten von Testdaten
11.2.3Werkzeuge für die Testdatengenerierung
11.2.4Drei Klassen von Testdatengeneratoren
11.2.5Unterscheidung der Funktionalitäten verschiedener Werkzeuge
11.2.6Weitere Testdatenmanagement-Werkzeuge
11.3Auswahl eines Testdatenwerkzeugs
11.3.1Weitere Voraussetzungen für die Auswahl eines Werkzeugs
11.3.2Testfälle für die Machbarkeitsstudie
11.4Zusammenfassung
12Metriken für Testdaten & Testdatenmanagement
12.1Metriken im Softwaretest
12.1.1Arten von Metriken
12.1.2Aussagen über Testdaten möglich?
12.2Kategorien von Metriken für Testdaten
12.2.1Mengenbezogene Metriken
12.2.2Qualitätsbezogene Metriken
12.3Konkrete Metriken für Testdaten
12.3.1Datenüberdeckungsmaße für Testdaten im Systemtest
12.3.2Metriken zum Messen der Datenqualität von Testdaten
12.3.3Metriken für das Testdatenmanagement
12.4Zusammenfassung
13Testdaten & Testdatenmanagement im Kontext
13.1Testdaten und Fehlerkategorien als Hilfe zur Priorisierung der Testdatenbereitstellung
13.2Testdaten im automatisierten Test
13.3Testdaten beim Testen von Data-Warehouse- und Business-Intelligence-Systemen
13.3.1Testumgebung
13.3.2Gewinnen von Testdaten für den Test von Data-Warehouse- und Business-Intelligence-Systemen
13.3.3Maßnahmen zum Schutz der echten Daten in den Testdaten
13.3.4Vor- und Nachteile von Echtdaten als Testdaten
13.3.5Weitere Quellen zum Ableiten von Testdaten
13.3.6Besondere Gruppen von Daten
13.3.7Überblick: Wie testet man Data-Warehouse- und Business-Intelligence-Systeme und was für Daten(bestände) benötigt man dafür?
13.3.8Begriffe in Data-Warehouse- und Business-Intelligence-Systemen
13.4Testdaten im Test von Embedded Systems
13.4.1Besonderheiten beim Testen eingebetteter Systeme
13.4.2Die Testdaten im Testen von Embedded Systems
13.4.3Erfahrungsbericht: Testdaten im Test von Embedded Systems im Bereich Videotechnik
13.5Testdaten in klassischen und in agilen Projekten
13.5.1Klassisch
13.5.2Agile, Scrum
13.6Testdaten in Normen für Softwareentwicklung und/oder Softwaretest
13.6.1Die neue Normenreihe ISO 29119
13.6.2Welche Regelungen zu Testdaten und Testdatenmanagement finden sich in ISO-29119-Reihe?
13.6.3Weitere relevante Normen: ISO/IEC 250xx
13.7Testdaten in Bewertungsmodellen
13.8Zusammenfassung
Teil IIIPraxis
14Vorgehen zum Verbessern eines Testdatenmanagements
14.1Einsteigen in strukturiertes Testdatenmanagement
14.2Etappe 1: Das Testdatenmanagement organisieren
14.2.1Zentralen Testdatenmanagement-Verantwortlichen benennen und dessen Aufgabe definieren
14.2.2Reife des Testprozesses prüfen & bei Bedarf verbessern
14.2.3Bestandsaufnahme & Anforderungsanalyse durchführen: Testdatenmanagementprozess
14.2.4Business Case für das Testdatenmanagement schreiben & entscheiden
14.2.5Bei Bedarf: Übergang vom Testdatenmanagement-Verantwortlichen zum Testdatenmanager
14.2.6Testdatenmanagement-Richtlinie erstellen (Testdatenmanagementstrategie)
14.2.7Entscheiden: zentrales, dezentrales Testdatenmanagement oder Mischform?
14.2.8Rollen definieren
14.2.9Prozesse und Dokumentation definieren
14.2.10 Die Testdaten organisieren
14.2.11 Werkzeugeinsatz und Hardwareeinsatz prüfen und anpassen
14.2.12 Initiales Testdatenmanagementkonzept verfassen
14.2.13 Umsetzen des Testdatenmanagements in konkreten Testprojekten sowie Prüfen & Verbessern des Testdatenmanagements
14.3Etappe 2: Die Testdaten organisieren – von der Analyse bis zur Archivierung
14.3.1Bestandsaufnahme durchführen: Stand der aktuell in Gebrauch befindlichen Testdaten
14.3.2Analyse: Testdatenanforderungen verstehen
14.3.3Spezifizieren der Testdaten, Testdatenpakete (→ Testdatenspezifikation)
14.3.4Testdaten erstellen & bereitstellen
14.3.5Daten nutzen, anpassen, archivieren
14.4Zusammenfassung
15Checklisten, Mustergliederungen, Fragenkataloge
15.1Mustergliederung TDM-Business-Case
15.2Checkliste zu Anforderungen an den TDM-Business-Case
15.3Checkliste TDM-Richtlinie
15.4Mustergliederung TDM-Konzept
15.5Testdatenspezifikation
15.6Checkliste Testdatenbereitstellungskonzept (nach TestSPICE™)
15.7Checkliste zur Organisation der Testumgebung und der Testdaten
15.8Checkliste Bestandsaufnahme zu Werkzeug- und Hardwareeinsatz
15.9Fragenkatalog zur Bestandsaufnahme Testdatenmanagement
15.10Fragenkatalog zur Bestandsaufnahme: Aktueller Testdatenbestand
15.11Fragenkatalog für das Erheben von Anforderungen an Testdaten (initial)
15.12Fragenkatalog zum Vervollständigen der Testdatenmenge
15.13Empfehlungen zu Methoden und Techniken für das Ermitteln von Anforderungen an Testdaten
15.14Relevante Informationen für die Auswahl der Testdaten
15.15Checkliste zum Spezifizieren der Testdaten
15.16Checkliste: Organisatorische Aspekte der Testdaten managen
15.17Checkliste: Aktivitäten zum Bereitstellen der Testdaten
15.18Empfehlungen zur Testdatengewinnung
15.19Empfehlungen zur Testdatenverwaltung
Anhang
AAbkürzungen
BGlossar
CLiteratur
Index
1Einleitung
Etwa 30 bis 50 % des gesamten Testaufwands entfallen auf das Erzeugen und Pflegen von Testdaten [Chac11].
Testdaten als Automatisierungshindernis
40 % der Befragten im World Quality Report nannten die Verfügbarkeit der Testdaten und der Testumgebung als Hindernis für die Testautomatisierung [WQR17, S. 41]. Damit landeten Testdaten und Testumgebung auf Platz 2 der größten Hindernisse – direkt nach dem Mangel an geeigneten Automatisierungswerkzeugen (wurde von 45 % der Teilnehmer genannt [WQR17, S. 41]).
Echtdaten!
35 % der Befragten erstellen neue Testdaten mithilfe von Automatisierungswerkzeugen, 17 % davon nutzen Eigenentwicklungen. 16 % legen ihre Testdaten anhand von Spreadsheets manuell an. Nur noch 11 % erstellen die Testdaten über grafische Benutzungsoberflächen (GUI). 28 % nutzen Kopien der Produktionsdaten als Testdaten, wobei 13 % diese zuvor nicht weiterbearbeiten (also auch nicht anonymisieren). 18 % setzen ihre Testdaten nach jeder Iteration zurück, um sie erneut verwenden zu können [WQR17, S. 49].
Diese Zahlen zeigen, welche Herausforderung die Testdaten im Softwaretest darstellen. Meine Erfahrungen decken sich in etwa damit.
Ziele und Aufbau des Buches
Ziele des Buches
Im Wesentlichen verfolgt dieses Buch folgende drei Ziele:
Es bereitet bisher verstreutes theoretisches und praktisches Wissen über Testdaten und Testdatenmanagement auf und bringt die einzelnen Arbeiten in einen Zusammenhang.
Zahlreiche Erfahrungsberichte und Praxisbeispiele zeigen Einblicke in die reale Welt des Testdatenmanagements.
Das Buch bietet aufgrund der vorgestellten Methoden, Vorgehensweisen und Checklisten konkrete Unterstützung in der täglichen Arbeit.
Aufbau des Buches
Das Buch gliedert sich in drei Teile.
Teil I (Kapitel 2 bis 6) beginnt mit den Testdaten und beantwortet folgende Fragen: Was versteht man unter Testdaten? Welche Anforderungen werden an Testdaten gestellt? Welche Eigenschaften weisen Testdaten auf? Welche Herausforderungen bergen sie? Wie kann man Testdaten gewinnen, nutzen, archivieren und was muss man in Bezug auf den Datenschutz beachten?
Der erste Teil definiert wesentliche Begriffe und stellt wichtige Methoden vor; er schafft Grundlagen für Teil III. Daher sei allen Lesern zumindest ein Überfliegen des ersten Teils empfohlen.
Teil II (Kapitel 7 bis 13) behandelt die verschiedenen Aspekte des Managens von Testdaten. Auch dieser Teil beginnt mit der Klärung des Begriffs, hier des Testdatenmanagements, und einer Abgrenzung zu Datenmanagement und Konfigurationsmanagement. Überspringen wird nicht empfohlen. Des Weiteren stellt der Teil Modelle und Best Practices vor. Diese dienen der Erweiterung unseres Horizonts und als Anregungen für die eigene Testdatenmanagementpraxis. Im Testdatenmanagement erfahrene Leser können diese querlesen und bei Bedarf (z.B. bei der Lektüre des Kapitels 9 zum konkreten Vorgehen) darauf zurückkommen. Kapitel 10 über Rollenkonzepte für das Testdatenmanagement zeigt, dass es mit dem Erstellen von Testdaten längst nicht getan ist. Ein Kapitel ist den Werkzeugkategorien gewidmet (Kapitel 11), ein weiteres den Metriken für Testdaten und für das Testdatenmanagement (Kapitel 12). Erfahrene, die sich mit Testdatenmanagement-Werkzeugen oder Metriken gut auskennen, können diese Kapitel überfliegen.
Den Schluss dieses zweiten Teils bildet Kapitel 13, das Testdaten und Testdatenmanagement in verschiedenen Kontexten betrachtet. Wer sich auf seine konkrete Berufspraxis konzentrieren möchte, kann einzelne Abschnitte des Kontext-Kapitels überspringen. Sie sind als Blick über den Tellerrand gedacht.
Teil III (Kapitel 14 und 15) baut auf den ersten beiden Teilen auf. Er stellt Ihnen ein Vorgehen zum Verbessern eines Testdatenmanagements vor, denn überall dort, wo getestet wird, findet bereits ein Testdatenmanagement statt. Checklisten, Fragenkataloge und Mustergliederungen bieten Hilfe für die Umsetzung.
Erfahrungsberichte, Beispiele und Lessons Learned runden die Kapitel ab.
Was das Buch bietet – und was nicht
Was das Buch bietet
Dies ist das erste deutschsprachige Buch, das sich direkt dem Thema Testdaten und Testdatenmanagement widmet. Es führt detailliert in dieses Thema ein. Damit unterstützt dieses Werk Softwaretester und Interessierte in einem bisher nur am Rande betrachteten Bereich – nämlich im Umgang mit Testdaten. So ermöglicht es dem Leser1, sich einen Eindruck darüber zu verschaffen, wo das eigene Testprojekt bzgl. Testdaten und Testdatenmanagement steht.
Dieses Buch soll Anregungen bieten. Sie werden an keiner Stelle dieses Buches lesen, dass diese oder jene Vorgehensweise die einzig richtige darstellt. Da jedes Softwareentwicklungsprojekt einzigartig ist und jedes Unternehmen seine eigenen Regeln schreibt, kann es keine Lösung geben, die wirklich auf alle passt. Daher spreche ich bestenfalls Empfehlungen aus.
Was das Buch nicht bietet
Konkrete Testdatenmanagement-Werkzeuge werden in diesem Buch nicht behandelt, denn das Buch beschränkt sich auf methodische Aspekte, und der Markt für Softwaretools ist sehr schnelllebig.
Dieses Buch bietet Ihnen keine maßgeschneiderte Testdatenmanagementlösung für genau Ihr spezifisches Projekt – dafür aber einen Vorschlag für eine Vorgehensweise, die Ihnen und Ihren Vorgesetzten genug Freiraum bieten sollte.
ISTQB® Certified Tester, GTB Certified Tester
Dieses Buch deckt keinen der Lehrpläne des »ISTQB® Certified Tester«-Programms ab. Überschneidungen sind jedoch möglich. Das Buch basiert im Wesentlichen auf den dort gelehrten Inhalten und ist insofern als eine Ergänzung zur vorhandenen Literatur zu verstehen.
Während der Entstehung dieses Buches erstellte eine Arbeitsgruppe des ASQF e.V. einen Zertifizierungslehrplan für das Testdatenmanagement. Dieser ist seit April 2017 auf den Seiten des German Testing Board e.V. veröffentlicht als GTB Certified Tester Foundation Level Test Data Specialist [GTB+17a]. Über den Inhalt des Lehrplans führt das Buch weit hinaus.
Einsteigern in das Thema Softwaretest sei zunächst die Lektüre von »Basiswissen Softwaretest. Aus- und Weiterbildung zum Certified Tester – Foundation Level nach ISTQB-Standard« [SpLi12] und ggf. auch »Praxiswissen Softwaretest – Testmanagement. Aus- und Weiterbildung zum Certified Tester – Advanced Level nach ISTQB-Standard« von Spillner, Roßner, Winter und Linz [SRWL08] empfohlen.
Beispielanwendung: Mein Onlineshop
Um verschiedene Sachverhalte anhand von Beispielen illustrieren zu können, stelle ich Ihnen hier die Beispielanwendung Mein Onlineshop vor. Es handelt sich um einen klassischen Onlineshop, über den verschiedene Artikel zum Kauf angeboten werden.
Ähnlichkeiten mit eventuell existierenden oder gar gleichnamigen Shops sind zufällig und nicht beabsichtigt.
Unsere Beispielanwendung Mein Onlineshop besteht aus folgenden Teilen:
Shop (Website; repräsentiert
Mein Onlineshop
im Internet.)
Artikelverwaltung (System enthält Angaben zu allen im Shop verfügbaren oder ab einem bestimmten Zeitpunkt verfügbaren Artikeln mit
Artikelnummer
, Abbildungen, Artikelname und -beschreibung, Preis, Rabattfähigkeit.)
Kundenverwaltung (Stammdaten der registrierten Kunden:
Kundennummer
, Vor- und Zuname, Geburtsdatum, Post- und Lieferanschrift, gekaufte Produkte)
Bestellungsverwaltung (
Kundennummer
, Bestellungsnummer, zur Bestellung alle Artikel mit Menge und Preis,
Rechnungsnummer
)
Abrechnungsmodul (
Rechnungsnummer, Kundennummer, Bestellnummer
, Rechnungsbetrag, …)
Kundenservice (Webanwendung für den Kundenservice; anrufende Kunden werden in Echtzeit per
Kundennummer
oder
Name und Geburtsdatum
im System identifiziert. Die Anwendung zeigt dem Kundenservicemitarbeiter für diesen Kunden alle abgeschlossenen und laufenden Bestellungen, offene und bezahlte Rechnungen sowie Retouren.)
Data Warehouse
Nicht in allen Fällen lässt sich diese Beispielanwendung sinnvoll einsetzen. Daher finden sich in diesem Buch auch davon abweichende Beispiele.
Teil I
Testdaten
2Testdaten – ein Überblick
Testdaten sind Bestandteil der Testumgebung. Dort dienen sie unterschiedlichen Zwecken. Dieses Kapitel bietet Ihnen einen Überblick über die verschiedenen gebräuchlichen Begriffe für Testdaten und beleuchtet die Bedeutung ihrer Metadaten.
Dieses Kapitel schafft ein Basisverständnis über den Testdaten-Begriff, wie er in diesem Buch verwendet wird, es sollte daher zumindest quergelesen werden.
2.1Begriffe Testdaten, ideale Testmenge, gute Testdaten
Softwaresysteme verarbeiten elektronisch Daten, basierend auf dem sogenannten EVA-Prinzip: Eingabe, Verarbeitung, Ausgabe. Wir geben Daten ein, das (zu testende) System verarbeitet diese und gibt Daten wieder aus. Zum Testen von Software, genauer zum Prüfen des Verhaltens der Software, verwendet man Testdaten.
Eckehard Kruse formuliert treffend: »Testdaten ermöglichen die Durchführung von Tests« [Krus11]. Testdaten werden benötigt, um Testfälle gegen das zu testende System oder Teile davon laufen zu lassen.
Abstrakte Testfälle enthalten zunächst keine Testdaten und können daher nicht ausgeführt werden. Indem man einen abstrakten Testfall um Testdaten ergänzt, entstehen ein oder mehrere ausführbare konkrete Testfälle. Die konkreten Testfälle verwenden Daten als Eingabe, die Eingabedaten, und enthalten Angaben über die erwarteten Ausgaben, die Ausgabedaten. Darüber hinaus benötigt das Durchführen konkreter Testfälle weitere Daten im zu testenden System. Dies können z.B. Stammdaten oder Konfigurationen sein.
Alle Daten in einer Testumgebung sind Testdaten. Darunter fallen Werte für Konfigurationsparameter ebenso wie Ausgabedaten nach Durchführung von Testfällen.
Doch was versteht man im Detail unter Testdaten? Und wann sind Testdaten gute Testdaten? Wie sieht die ideale Testmenge aus?
2.1.1Testdaten
Im Glossar des German Testing Board findet sich folgende Definition von Testdaten:
Definition: Testdaten (nach German Testing Board)
»Daten, die (z.B. in einer Datenbank) vor der Ausführung eines Tests existieren, und die die Ausführung der Komponente bzw. des Systems im Test beeinflussen bzw. dadurch beeinflusst werden.« [GTB+15, S. 66]
Damit umfasst diese Definition ausschließlich vor oder während der Testausführung existierende Testdaten, nicht aber die Daten, die bei der Ausführung eines Testfalls entstehen.
Im Lehrplan zum Certified Test Data Specialist (GTB) heißt es in Ergänzung der vorgenannten Definition: »Testdaten sind konkrete Werte von Datenobjekten, die zur Ausführung eines Testobjekts benötigt werden. Sie können z.B. in Dateiform, in Form von Datenbanktabellen oder in Listenform vorliegen« [GTB+17a, S. 17].
In »Basiswissen Softwaretest« formulieren die Autoren Andreas Spillner und Tilo Linz [SpLi12, S. 263] darüber hinaus folgende Definition zu Testdaten:
Definition: Testdaten (nach Andreas Spillner und Tilo Linz)
»Eingabe- und Zustandswerte für ein Testobjekt und die Sollwerte nach Ausführung des betreffenden Testfalls« und »Daten, die (z.B. in einer Datenbank) vor der Ausführung eines Tests existieren und die Ausführung der Komponente bzw. des Systems im Test beeinflussen bzw. dadurch beeinflusst werden.« [SpLi12, S. 263]
Abb. 2–1Testdaten-Begriffe
Ein sehr ähnliches Begriffsverständnis findet sich in Kruses oben erwähntem White Paper zum Testdatenmanagement [Krus11].
In den vorgestellten Begriffen ist der Zusammenhang zwischen Testdaten und Testumgebung nicht berücksichtigt. ISO 29119 betrachtet die Testdaten als Bestandteil der Testumgebung.
Die folgende Definition, basierend auf den vorgestellten TestdatenBegriffen, formuliert etwas expliziter:
Testdaten-Begriff
Definition: Testdaten
Testdaten bezeichnen alle Daten, die in die Testumgebung eingegeben (Eingabe- und Zustandswerte für ein Testobjekt) oder aus ihr ausgelesen werden (Sollwerte, Istwerte) sowie alle Daten, die in der Testumgebung vorhanden sind bzw. verwendet werden (z.B. in einer Datenbank, aber auch Umgebungsdaten wie Konfigurationsdateien, Ports usw.).
Testdaten beeinflussen die Ausführung der zu testenden Komponente bzw. des zu testenden Systems oder werden dadurch beeinflusst.
Einordnung
Folgt man dem Glossar des ISTQB® [GTB+15], so zählen die Testdaten zu den Testmitteln:
Definition: Testmittel (nach German Testing Board)
»Alle Artefakte, die während des Testprozesses erstellt werden und die erforderlich sind, um die Tests zu planen, zu entwerfen oder auszuführen. Dazu gehören: Dokumente, Skripte, Eingabedaten, erwartete Ergebnisse, Prozeduren zum Aufsetzen und Aufräumen von Testdaten, Dateien, Datenbanken, Umgebungen und weitere zusätzliche Software- und Dienstprogramme, die für das Testen verwendet werden.« [GTB+15]
Die obigen Definitionen beschreiben, wann Testdaten vorhanden sind und worauf sie Einfluss nehmen. Außerdem erfahren wir etwas über die Aufgabe der Testdaten, nämlich ihre Verwendung als Eingabe- und Zustandswerte für ein Testobjekt und als Sollwerte für Testfälle.
Testdaten versus Testdaten(mengen)
Wenn von Testdaten die Rede ist, dann sind entweder eine Menge von Testdaten oder auch Testdaten eines konkreten Testfalls oder gar einzelne Testdaten (Testdatum) gemeint.
Welche Alternative zutrifft, sollte aus dem jeweiligen Kontext hervorgehen. Wo eine explizite Unterscheidung notwendig ist, finden Sie diese im Text dargestellt.
2.1.2Gute Testdaten
Nachdem der Begriff der Testdaten eingeführt ist, betrachten wir einen Qualitätsaspekt: Wann sind Testdaten gute Testdaten?
Gute Testdaten, bezogen auf einen konkreten Testfall, sind diejenigen Testdaten, die das mit dem Testfall verfolgte Ziel unterstützen.
Doch was sind gute Testdaten im Sinne einer Menge von Testdaten?
Bei Redwine [Redw83, S. 192 o.] findet sich eine Definition für qualitativ gute Testdaten; er bezieht sich auf eine Menge. Demnach stellen gute Testdaten eine sinnvoll bemessene Menge von Daten dar, die alle oder fast alle Teile der Software ausführen, sodass die Resultate unterscheiden zwischen korrektem Funktionieren und möglichen Fehlern [Redw83, S. 192 o.].
Um mit dieser Menge an Daten alle bzw. fast alle1 Softwareteile ausführen zu können, müssen Testdaten enthalten sein, die – bezogen auf Anwendungsfälle – sowohl den Normalfall als auch Alternativen sowie Sonderfälle und Fehlerfälle umfassen.
Abb. 2–2Gute Testdaten
Dies geht implizit auch aus der zweiten der von Chace genannten Eigenschaften hervor. Gute Testdaten, im Sinne einer Menge von Testdaten, lassen sich nach Chace [Chac11] mit zwei wesentlichen Eigenschaften beschreiben:
Sie repräsentieren die gesamte Bandbreite der Produktionsdaten oder »Echtweltdaten«.
Sie sind angemessen dimensioniert, sodass sie die Anforderungen des Tests unterstützen.
Testdaten zu Testobjekt
Die oben dargestellten Ausführungen zu guten Testdaten sind nicht nur auf das Gesamtsystem als Testobjekt, sondern auch auf das jeweils betrachtete Testobjekt (auch Systemteile) sowie das verfolgte Testziel zu beziehen. So unterscheiden sich Testdaten für Testfälle im Regressionstest einer bestimmten Komponente von Testdaten für Testfälle in einem ausführlichen funktionalen Test während der Entwicklung dieser Komponente.
Zum einen sprechen wir hier wieder über die Menge an Testdaten, die in letzterem Falle umfangreicher ausfällt. Zum anderen meint Testdaten die Daten für einen einzelnen Testfall, wenn es darum geht, anhand der Resultate zwischen korrektem oder fehlerhaftem Verhalten zu unterscheiden.
Folgende Definition fasst die Aspekte guter Testdaten zusammen:
Definition: Gute Testdaten
Bezogen auf ein bestimmtes Testobjekt und ein bestimmtes Testziel werden Testdaten gute Testdaten genannt, wenn sie folgende Eigenschaften aufweisen:
Sie bestehen aus einer sinnvoll bemessenen Menge von Daten.Sie repräsentieren die gesamte Bandbreite der Produktionsdaten (»Echtweltdaten«) und umfassen – ergänzend zu den Testdaten aus Produktionsdaten – Daten für Normalfälle, Sonder- und Fehlerfälle.Sie bewirken in Testfällen die Ausführung aller oder fast aller Teile des Testobjekts. Die erzielten Testresultate unterscheiden zwischen korrektem Verhalten und möglichen Fehlern.2.1.3Ideale Testmenge
Während der Begriff der guten Testdaten eher auf Eigenschaften fokussiert, steht beim Begriff der idealen Testmenge deren Wirkung im Vordergrund.
Die ideale Testmenge zu einem Programm weist nach Appelrath und Ludewig (Skriptum Informatik, [ApLu99]) folgende zwei Merkmale auf:
»Wenn das Programm korrekt ist, dann liefert es für alle Eingaben aus der Testmenge korrekte Ergebnisse.
Wenn umgekehrt das Programm für alle Eingaben aus der Testmenge korrekt arbeitet, so ist das Programm auch für alle anderen Eingaben korrekt.«
Leider können Appelrath und Ludewig uns nicht sagen, wie wir die ideale Testmenge bestimmen können, denn dafür existiert kein allgemeines Verfahren.
Sie ahnen es sicher: Der Grund dafür liegt darin, dass es die ideale Testmenge nicht gibt. Denn diese Testmenge müsste zeigen, dass die zu testende Anwendung korrekt arbeitet – und zwar korrekt in Bezug auf die Spezifikation, gegen die getestet wird. Die ideale Testmenge müsste also auch dazu führen, dass vergessene, fehlerhafte oder missverstandene Anforderungen durch den Test aufgedeckt werden. Welche Testmenge kann das leisten?
Wozu dann einen Abschnitt über ideale Testmengen schreiben und lesen, wenn es diese gar nicht gibt? Um uns genau das klarzumachen.
Halbwegs ideale Testmenge
Immerhin führen bekannte Vorgehensweisen zu einer »halbwegs idealen« Testmenge. Die halbwegs ideale Testmenge ist so beschaffen, dass »man, wenn das Programm sie ohne Fehler verarbeitet, auf seine Korrektheit hoffen kann« [ApLu99].
Mehr als Hoffnung bleibt auch nicht, denn erstens warnt der 7. Grundsatz des Softwaretestens vor dem Trugschluss, keine Fehler bedeute ein brauchbares System [SpLi12, S. 38], und zweitens ist vollständiges Testen nicht möglich.
»Darum bleibt der Kern des Tests, die Wahl der Testdaten, eine sehr kreative Tätigkeit, die viel Erfahrung voraussetzt und ausgesprochen zeitaufwendig ist« [ApLu99].
Zur Auswahl von Testfällen (inklusive der Testdaten) und dem Aufbau einer halbwegs idealen Testmenge siehe Anregungen in Abschnitt 5.1.3.
Abb. 2–3Ideale Testmenge
Welche Daten wir zu den Testdaten zählen und welche weiteren Unterscheidungen möglich sind, wird nachfolgend erläutert.
2.2Kategorien von Testdaten
Es gibt unterschiedliche Kategorien von Testdaten. Eine Unterscheidung ist in mehreren Hinsichten nützlich. Sie ermöglicht zum Beispiel eine strukturierte Anforderungsermittlung zu Testdaten und erlaubt es, sich einen Überblick über benötigte Testdaten zu verschaffen. Darüber hinaus gehen aus der Kategorie der Einsatzort und der Verwendungszweck der Testdaten hervor. Wie wir später sehen werden, lässt die Kategorie auch Rückschlüsse auf den spätesten Zeitraum der Bereitstellung dieser Testdaten zu.
Die folgenden beiden Definitionen von Testdaten fokussieren auf die Art der Testdaten. Hier geht es u.a. darum, was die Testdaten »beinhalten«.
2.2.1Kategorien nach Reimann
Reimann [Reim13] unterscheidet folgende drei Kategorien von Testdaten:
Testfalldaten
,
Bestandsdaten/Historiendaten
und
Umgebungsdaten
.
Eingabedaten, Zustandsdaten, Ergebnisdaten und erwartete Ergebnisdaten (Sollwerte) nennt er als Beispiele für Testfalldaten.
Als Bestandsdaten/Historiendaten definiert er z.B. Stammdaten, Tarifdaten, Ergebnisdaten, historische Daten.
Abb. 2–4Kategorien von Testdaten (nach Reimann)
Zu den Umgebungsdaten zählt er Systemdaten und PLZ-Verzeichnisse, aber auch Benutzerkennungen sowie die damit im System verbundenen Rechte.
2.2.2Kategorien nach Chace
Chace [Chac11] formuliert eine sehr ähnliche, aber detailliertere Klassifizierung der Testdaten:
Umgebungsdaten
(»Environmental Data«)
Basisdaten
(»Baseline Data«)
Eingabedaten
(»Input Data«)
Demnach stellen die Umgebungsdaten nach [Chac11] den Ausführungskontext der Testfälle dar. Sie umfassen:
Systemkonfiguration: Betriebssystem, Datenbanken, Applikationsserver, Hardwarekonfigurationen usw.
Benutzerautorisierung, -authentifizierung, Berechtigungsnachweise: Benutzerkennungen, Passwörter, Systemzugriffslevel für generische, rollenbasierte oder testspezifische Benutzer
Konfigurationsmöglichkeiten: Port-Einstellungen der Firewall, Einstellungen der Applikationsserver, Speicherverwaltung (»machineresource allocation«)
Abb. 2–5Kategorien von Testdaten (nach Chace)
Den Ausgangspunkt für die Testausführung und Grundlage für die erwarteten Ergebnisdaten bilden nach [Chac11] die Basisdaten. Aus Vorbedingungen von Testfällen, Datenmerkmalen und Testart ergibt sich demnach eine initiale Menge an Basisdaten.
Als Eingabedaten bezeichnet [Chac11] die Daten, die Tester als Bestandteil eines Testfalls in das zu testende System eingeben, um dessen Reaktion zu prüfen.
In den vorangegangenen Abschnitten wurden die Testdaten in Gruppen unterteilt, die als Kategorien bezeichnet wurden. Im folgenden Abschnitt tragen die Testdatengruppen den Namen Testdatentyp. Bei Lichte betrachtet läuft es auf dasselbe hinaus.
2.2.3Testdatentypen nach Jagers und Kollegen
Jagers und Kollegen unterteilen in [JPH+09] die Testdaten ebenfalls in drei Gruppen: Konfigurationsdaten (»configuration data«), Operationsdaten (»operational data«), Eingabe- und Ausgabedaten (»input and output data«).
Mithilfe der
Konfigurationsdaten
wird die Testumgebung so eingestellt, dass Tests durchgeführt werden können.
Als
Operationsdaten
bezeichnen [
JPH+09
] eine ausgewählte Menge an Daten, die einen definierten Startpunkt darstellen. Dieser bildet die Ausführungsbasis für einen bestimmten Testfall oder ein bestimmtes Testszenario.
Testdaten, die im Zuge der Testfallausführung erzeugt, bearbeitet oder gelöscht werden, werden als
Eingabe- und Ausgabedaten
bezeichnet.
Abb. 2–6Testdatentypen (nach [JPH+09])
Gemeinsamkeiten
Die drei vorgestellten Unterscheidungen von Testdaten ähneln sich. Sie unterteilen die Daten aus der Sicht des Testfalls in Daten, die eingegeben oder ausgegeben werden (Testfalldaten; Eingabedaten; Eingabe- und Ausgabedaten), und Daten, die im System vorhanden sein müssen, damit der Testfall ausgeführt werden kann (Bestandsdaten/Historiendaten; Basisdaten; Operationsdaten und Umgebungsdaten; Konfigurationsdaten).
2.2.4Definition Testdatenkategorien
In diesem Buch sind Kategorien von Testdaten unter Verwendung der oben vorgestellten Unterscheidungen wie folgt definiert:
Definition: Testdatenkategorien
Testdatenkategorien unterscheiden Testdaten nach ihrer Rolle, die sie in Bezug auf den Testfall einnehmen.
Folgende Testdatenkategorien werden unterschieden:
Testfalldaten
Bezeichnen die mit der Ausführung des Testfalls eingegebenen, bearbeiteten, gelöschten oder ausgegebenen Daten. Testfalldaten gibt der Tester im Zuge des Testfalls ein bzw. liest diese aus. Sie umfassen die Eingabedaten, die tatsächlichen Ausgabedaten sowie die erwarteten Ausgabedaten. Ebenfalls zu den Testfalldaten zählt das Testresultat, das angibt, ob das Testobjekt den Testfall bestanden hat oder nicht (passed/failed).
Operationsdaten/Basisdaten
Operationsdaten/Basisdaten bezeichnen diejenigen Daten, auf denen der Testfall arbeitet. Sie stellen den Ausgangspunkt der Testdurchführung dar und bilden die Grundlage der erwarteten Ergebnisse (Ausgabedaten, Testresultat).
Sie umfassen z.B. Stammdaten, Tarifdaten und historische Daten.
Umgebungsdaten/Konfigurationsdaten
Umgebungsdaten/Konfigurationsdaten dienen der Einstellung der Testumgebung und bilden eine Voraussetzung für die Testdurchführung. Sie definieren den Ausführungskontext der Testfälle.
Umgebungsdaten/Konfigurationsdaten lassen sich unterscheiden in:
Systemkonfiguration (Betriebssystem, Datenbanken, Applikationsserver, Hardwarekonfigurationen usw.)Benutzerautorisierung, -authentifizierung, Berechtigungsnachweise (Benutzerkennungen, Passwörter, Systemzugriffslevel für generische, rollenbasierte oder testspezifische BenutzerKonfigurationsmöglichkeiten (Port-Einstellungen der Firewall, Einstellungen der Applikationsserver, Speicherverwaltung usw.)Für die Praxis
In der Praxis wird es nicht immer möglich sein, Testdaten eindeutig und global gültig einer Kategorie zuzuordnen. Dies ergibt sich aus der Sichtweise der Kategorien: Sie beziehen sich (auch) auf den konkreten Testfall. So können die Ausgabedaten des einen Testfalls als Eingabedaten eines anderen Testfalls fungieren.
Beispiel: Ergebnisdaten und Eingabedaten
Testfall 1 prüft das Anlegen einer Benutzerkennung: Anmelden mit der Administratorkennung (Benutzer admin, Passwort; Eingabedaten) und Erstellen eines Benutzers für Johann aus der Buchhaltung. Ergebnisdaten dieses Testfalls sind die konkrete Benutzerkennung mit Benutzername »johann« und Passwort »MP=8!5rt« sowie den damit verbundenen Berechtigungen im zu testenden System.
Testfall 2 prüft einen Anwendungsfall aus der Buchhaltung: Anmelden mit der Benutzerkennung des Buchhalters »johann« und dessen Passwort, danach Aufrufen eines Monatsberichts.
Die Benutzerkennung »johann« fällt in Testfall 2 in die Kategorie Eingabedaten bzw. Testfalldaten, während sie in Testfall 1 zu den Ergebnisdaten des Testfalls einzuordnen ist.
Darüber hinaus zählen Benutzerkennungen nach beiden oben zitierten Begriffen zu den Umgebungsdaten.
Für die Praxis des Testdatenmanagements bedeutet das Folgendes:
Ob Daten zu dieser oder jener Kategorie gehören, interessiert beim Aufbau und bei der Pflege des Testdatenbestands (Unterstützung der Anforderungsermittlung im Sinne einer Checkliste) sowie beim Aufbau und der Versorgung der Testumgebung mit den zuvor definierten und bestellten Testdaten. Ein Testdatenkonzept stützt sich beim Definieren der Testdaten ggf. auf diese Kategorien.
2.3Testdatenbestandstypen
Eine andere Sichtweise auf die Testdaten eröffnet die Unterscheidung in Testdatenbestandstypen. Während der Fokus der Testdatenkategorien eher auf der Bedeutung der Testdaten liegt, steht bei der Unterscheidung in Testdatenbestandstypen der Anwendungskontext im Vordergrund (Testobjekt, Testprojekt).
Bei Hettwer [HettoJ] unterscheidet man die Testdaten in drei Testdatenbestandstypen: projektübergreifende Steuerungsdaten, testobjektübergreifende Daten und testobjektspezifische Daten (Primär- und Sekundärdaten).
Definition: Testdatenbestandstypen
Testdaten lassen sich hinsichtlich ihres Anwendungskontextes unterscheiden in Testdatenbestandstypen. Diese verdeutlichen den Bezug der Testdaten zum Testprojekt und zum Testobjekt.
Folgende Testdatenbestandstypen werden unterschieden: projektübergreifende Steuerungsdaten, testobjektübergreifende Daten und testobjektspezifische Daten (Primär- und Sekundärdaten) (vgl. [HettoJ]).
Die projektübergreifenden Steuerungsdaten weisen folgende Eigenschaften auf:
Enthalten niemals kundenspezifische Daten
Können identisch sein zu Produktionsdaten
Anwendung greift nur lesend darauf zu (kein Editieren)
Bleiben i.d.R. über den Lebenszyklus der Anwendung gleich
Testobjektübergreifende Daten »stellen einen repräsentativen Umfang an Bestandsdaten dar, die jede Funktionalität der Anwendung als Ausgangszustand benötigt« [HettoJ]. Aus den verfügbaren Datensätzen sind zur Verwendung in den Testobjekten geeignete Datensätze auszuwählen. Die testobjektübergreifenden Daten dienen als Kopiervorlage für einzelne Testobjekte.
Bei den testobjektspezifischen Daten handelt es sich um Primär- und Sekundärdaten (mehr zu Primär- und Sekundärdaten siehe Abschnitt 2.4).
Abb. 2–7Testdatenbestandstypen (nach Hettwer)
2.4Unterscheidung in Primär- und Sekundärdaten
Neben den oben vorgestellten Kategorien und Typen von Testdaten finden sich weitere Gruppierungsmöglichkeiten.
Im 1997 erschienenen Artikel der Computerwoche [Anon97] werden Primärdaten und Sekundärdaten zunächst wie folgt unterschieden:
Primärdaten
sind Eingabedaten.
Sekundärdaten
sind »Testdaten, die in Datenbanken, Parameterdateien etc. vorliegen müssen« [
Anon97
].
Eine detailliertere Beschreibung findet sich auf der Seite der Hettwer Unternehmensberatung [HettoJ]. Sie differenzieren testobjektspezifische Daten in Primär- und Sekundärdaten.
Demnach führen Primärdaten in Schnittstellen (auch GUI) zur Verarbeitung. Sie werden für jedes Testobjekt explizit erstellt.
Als Sekundärdaten bezeichnet Hettwer »Daten, die benötigt werden, damit die Verarbeitung laufen kann« (Bestandsdaten) [HettoJ]. Sie werden für jedes Testobjekt in der Regel aus der Kopierbasis erzeugt. Findet sich in der Kopierbasis kein passender Datensatz, dann erstellt und verwaltet man zum konkreten Testobjekt den/die fehlenden Datensätze. Beim Erstellen folgt man idealerweise dem Kopieren- und-Editieren-Ansatz, indem man einen ähnlichen Satz sucht, kopiert und »über eine Anwendung (funktionsgetestet!!) oder über ein entsprechendes Testdaten-Tool« [HettoJ] anpasst.
Auch [DaGl16] unterscheiden zwischen primären Testdaten und sekundären Testdaten.
Die »Daten, die während des Testablaufs die Eingaben bestimmen und meist in der Testfallspezifikation« zu finden sind, bezeichnen sie als primäre Testdaten. Sekundäre Testdaten dagegen bilden die Grundlage für den Testablauf und können sehr umfangreich sein (z.B. Konfigurationen oder Datenbankinhalte) (vgl. [DaGl16, S. 106]).
Abb. 2–8Primärdaten und Sekundärdaten
Unter Rückgriff auf die vorgestellten Begriffe werden Testdaten als Primärdaten oder Sekundärdaten wie folgt definiert:
Definition: Primärdaten/Primäre Testdaten
Primärdaten bezeichnen die Eingabedaten eines Testfalls. Sie werden für jedes Testobjekt explizit erstellt. In Schnittstellen führen sie zur Verarbeitung. Primärdaten können in der Testfallspezifikation enthalten sein.
Primärdaten stellen demnach eine Teilmenge der Testdatenkategorie Testfalldaten dar (siehe Abschnitt 2.2).
Definition: Sekundärdaten/Sekundäre Testdaten
Sekundärdaten bezeichnen Testdaten, die in der Testumgebung vorliegen müssen. Sie umfassen Datenbanken, Parameterdateien, Konfigurationen. Sekundärdaten ermöglichen die Testdurchführung.
Die Sekundärdaten lassen sich daher den Testdatenkategorien Operationsdaten und Umgebungsdaten zuordnen.
2.5Unterscheidung nach Testobjekt in Testdatentypen
Testdaten lassen sich hinsichtlich des Testobjekts unterscheiden, für das sie verwendet werden. So geschehen in »Der Systemtest« [SBS12]. Die Autoren betrachten für die Teststufe Systemtest folgende Testobjekte: Benutzeroberflächen, Systemschnittstellen, Datenbanktabellen, Dateien. »Jedes dieser Testobjekte weist eine andere Art von Testdaten auf, die auf eine andere Art und Weise erzeugt werden« [SBS12, S. 135]. In Abhängigkeit von diesen Testobjekten unterscheiden sie verschiedene Testdatentypen:
Testdaten für das Testobjekt »Datenbanken«
Testdaten für Testobjekt »Systemschnittstellen«
Testdaten für Testobjekt »Benutzeroberflächen«
Sie erachten die Unterscheidung der Testdatentypen als notwendige Voraussetzung für das Erstellen von Testdaten2.
Analog zur obigen Verfahrensweise lassen sich für andere Teststufen ähnliche Unterscheidungen in Testdatentypen treffen, z.B. Testdaten für das Testobjekt Komponente (Modul, Unit, Klasse) im Komponententest.
Ergänzend zu den Testdatentypen finden sich die zugehörigen Überdeckungsmaße [SBS12, S. 136ff.], Datenüberdeckungsgrade genannt.
Diese Unterscheidung ist hier nur der Vollständigkeit halber genannt.
2.6Ergebnisse eines Testlaufs: Soll, Ist, Testergebnis
Ein Testdatenbegriff findet sich auch in der Norm ISO 29119. So unterscheidet die ISO 29119-2 bzgl. der Ergebnisse eines Testlaufs folgende drei Begriffe (vgl. [DaGl16, S. 82]):
Sollergebnis (Sollwert, Soll): »Der Wert, die Werte, der Zustand … – den das Testobjekt laut Testbasis hoffentlich liefern wird.«
Istergebnis (Istwert, Ist): »Der Wert, die Werte, der Zustand … – den man während der Testdurchführung beobachtet und der anders sein kann als geplant.«
Testergebnis: »Die Antwort auf die Frage, ob bestanden oder nicht (»passed« oder »failed«), je nachdem, ob Sollergebnis und Istergebnis übereinstimmen oder nicht.«
Nach meinem bisherigen Verständnis stellen Sollergebnis und Istergebnis Testdaten, genauer Testfalldaten, dar (nach [Reim13]); sie fallen in die Gruppe der Ausgabedaten.
Bisher konzentrierten wir uns auf die Testdaten selbst. Doch es existieren weitere Daten, die im Zusammenhang mit Testdaten relevant sind: die Metadaten der Testdaten.
2.7Metadaten für Testdaten
Metadaten, Metadatenmanagement
Grundsätzlich versteht man unter Metadaten Daten über Daten. Metadaten für Testdaten beschreiben demzufolge die eigentlichen Testdaten.
Eicker definiert Metadaten wie folgt:
Definition: Metadaten (nach Eicker)
»Daten über Objekte der Informationsverarbeitung beispielsweise über Daten, Funktionen, Prozesse, Anwendungssysteme, Komponenten der IT-Infrastruktur etc.« [Eick14]
Demnach umfasst das Metadatenmanagement analog zum Datenmanagement »alle Aufgaben, die für die adäquate Bereitstellung der Metadaten auf strategischer, taktischer und operativer Ebene wahrzunehmen sind« [Eick14].
Datenadministration
Einen Anwendungsbereich für Metadaten stellt die Datenadministration dar. Nach Eicker behandelt diese z.B. die Fragen, welche Daten in welcher Struktur wo gespeichert werden, wie die Zusammenhänge zwischen den Daten gestaltet sind und wo insbesondere Redundanzen bestehen.
Wozu man Metadaten im Testdatenmanagement benötigt
Weshalb soll man den Aufwand betreiben, neben den Testdaten auch noch Metadaten für selbige zu pflegen? Nun, unter anderem deshalb, weil fehlende oder unsauber gepflegte Metadaten zu den häufigen Problemen mit Testdaten gehören (siehe Kap. 4).
Betrachten wir ein paar konkrete Verwendungszwecke:
Zur Eigentumsregelung
Mithilfe von Metadaten soll z.B. vermieden werden, dass sich verschiedene Testteams, die sich eine Testumgebung oder eine Datenbasis teilen, beim Testen dadurch stören, dass sie sich gegenseitig die Daten »wegnehmen« oder »zerschießen«.
Als Auswahlkriterium
Metadaten dienen u.a. als Kriterium zur Auswahl von geeigneten Testdaten für einen bestimmten Testfall, Testlauf oder ein Testszenario.
»Auch die Zusammenstellung von Daten für einen übergreifenden Integrationstest ist ohne Metadaten erheblich aufwändiger« [Ende12].
Als Entscheidungshilfe
Unser Testdatenbestand soll einerseits nicht zu umfangreich sein, andererseits aber alle geplanten Tests unterstützen. Metadaten, die fachliche Informationen über Testdaten enthalten, helfen bei der Entscheidung darüber, ob vorhandene Testdatensätze angepasst werden können oder ob es fachlich sinnvoller ist, einen oder mehrere Testdatensätze neu anzulegen.
Die Informationen über den fachlichen Kontext helfen bei der Auswahl der Testdaten für Tests zu fachliche Szenarien. Sie werden benötigt, um festzustellen, ob ein bestimmtes fachliches Szenario in den Testdaten bereits abgebildet ist oder ob hierfür ein oder mehrere neue Datensätze angelegt werden sollten.
Erfolgt zum Testen neuer Funktionalitäten eine Anpassung der vorhandenen Testdaten, dann kann es passieren, dass aufgrund fehlender oder ungeeigneter Metadaten die »falschen« Testdaten ergänzt bzw. geändert werden. So können sich Testdatenkonstellationen ergeben, die aus fachlicher Sicht nicht sinnvoll oder sogar falsch sind.
Als Steuerinformation
Darüber hinaus dienen Metadaten Testern und Testwerkzeugen für Auswertungen oder als Steuerinformationen (vgl. [Ende12]).
Zur Unterstützung von Automatisierung
»Ein sauberes Metadaten-Management von Anfang an fördert die vollständige Automatisierung von Prozessen und verringert damit den manuellen Aufwand« [Ende12].
Metadaten unterstützen auch die Testautomatisierung. Zum Beispiel wenn aus den Metadaten hervorgeht, dass diese ausschließlich für bestimmte Testläufe (Smoke-Test, Health Check) verwendet werden dürfen.
Mit diesem Einblick in die Begriffe und den Verwendungszweck von Metadaten wollen wir das Thema Metadaten hier abschließen.
2.8Testdaten, Testfälle, Testentwurfsverfahren und Testabdeckung
Bevor wir in den nächsten Kapiteln intensiver in die Aspekte rund um Testdaten einsteigen, machen wir uns zunächst die Zusammenhänge zwischen Testdaten, Testfällen, Testentwurfsverfahren und Testabdeckung (Überdeckungsgrad) klar.
Diese Zusammenhänge sind wichtig für das Verständnis der folgenden Kapitel.
Testdaten und Testfall
Beginnen wir mit den Testfällen und den Testdaten: Abstrakte Testfälle enthalten noch keine Testdaten, weshalb sich die Testfälle nicht ausführen lassen. Erst dadurch, dass man einen abstrakten Testfall um Testdaten ergänzt, erhält man einen ausführbaren konkreten Testfall.
Testentwurfsverfahren
Testfälle lassen sich mittels Testentwurfsverfahren ableiten oder ermitteln. Testentwurfsverfahren werden unterschieden in spezifikationsbasierte, strukturbasierte und erfahrungsbasierte Verfahren (vgl. [SpLi12, S. 263]). Darüber hinaus unterscheidet man Blackbox-Verfahren und Whitebox-Verfahren.
Einige Testentwurfsverfahren wie z.B. die beiden Blackbox-Verfahren Äquivalenzklassenbildung und Grenzwertanalyse basieren auf der Analyse der Eingabewerte. Mithilfe dieser Methoden ermitteln wir also nicht nur Testfälle, sondern auch Testdaten! Denn als Eingabedaten zu den konkreten Testfällen fungieren die ermittelten Repräsentanten der Äquivalenzklassen und die Grenzwerte. Die Testfälle werden ergänzt um die erwarteten Sollwerte (Ausgabedaten). Eingabedaten und erwartete Sollwerte gehören zur Kategorie Testfalldaten.
Überdeckungsgrad
Der Überdeckungsgrad ist nach [GTB+15] definiert als der in einem Prozentsatz ausgedrückte Grad, zu dem ein spezifiziertes Überdeckungselement durch eine Testsuite ausgeführt wurde.
Daher müssen folgende Voraussetzungen erfüllt sein, um einen Überdeckungsgrad größer null berechnen zu können:
Alle gemäß vorgegebenem Testentwurfsverfahren erforderlichen konkreten Testfälle müssen identifiziert sein – sie verkörpern die 100 % Überdeckung.
Eine Menge an Testfällen muss ausgeführt sein – für die leere Menge an Testfällen beträgt die Überdeckung null Prozent.
Die Testumgebung enthält alle nötigen Testdaten, um die Testfälle durchführen zu können (Operationsdaten, Umgebungsdaten).
Überdeckung durch Testdaten
Im Abschnitt 8.2 lernen Sie ein Vorgehen kennen, anhand dessen Sie mittels verschiedener Überdeckungen Testdaten ermitteln können. Samuel T. Redwine formuliert es so, als überdeckten die erarbeiteten Eingabe- und Ausgabedaten das Überdeckungselement. Letztlich identifiziert er mit den Testdaten jedoch konkrete Testfälle.
Da ein Testfall ohne Testdaten nicht ausgeführt werden kann, sind die Testdaten als untrennbarer Bestandteil des jeweiligen Testfalls zu betrachten. Insofern erscheint es nicht sinnvoll, neben dem Überdeckungsgrad (nach [SpLi12]) einen eigenständigen Überdeckungsgrad für Testdaten zu betrachten.
2.9Zusammenfassung
Dieses Kapitel vermittelte einen Überblick über verschiedene Begriffe im Themenbereich Testdaten. Der Begriff der Testdaten selbst sowie die Unterscheidungen der Testdaten hinsichtlich der verschiedenen Kriterien bilden die Grundlage für ein umfassendes Verständnis der Testdaten.
So versetzt Sie dieses Kapitel in die Lage, die in Ihrem Testprojekt benötigten Testdaten zu analysieren und die Ergebnisse z.B. in einem Testdatenrahmenwerk festzuhalten (siehe Abschnitt 9.1).
Daneben sollten Sie aus diesem Kapitel mitnehmen, dass die Metadaten der Testdaten von großer Bedeutung sind für deren Lebenszyklus und Verwendung in Tests. Sie wissen nun, dass es sich lohnt, Metadaten zu erheben und zu pflegen, um den Testdatenbestand möglichst lange in guter Qualität zu erhalten.
Zum Weiterlesen
Weitere lesenswerte Ausführungen zu Testdaten in verschiedenen Teststufen finden sich in [Held16, S. 27ff.].
3Eigenschaften von und Anforderungen an Testdaten
Bevor wir die Anforderungen an Testdaten betrachten, machen wir uns zunächst bewusst, durch welche Eigenschaften Testdaten gekennzeichnet sind.
Welche Anforderungen müssen Testdaten erfüllen, damit sie gute Testdaten sein können und die Testaktivitäten sinnvoll unterstützen? Die Anforderungen an Testdaten sind vielfältiger Art und zum Teil widersprüchlich. Dieses Kapitel beleuchtet einige von ihnen.
Dass die Testdaten alle wesentlichen an sie gestellten Anforderungen erfüllen, soll das Testdatenmanagement sicherstellen.
3.1Eigenschaften von Testdaten
Im vorangegangenen Kapitel befassten wir uns mit verschiedenen Unterscheidungsmöglichkeiten von Testdaten. Doch welche Eigenschaften kennzeichnen Testdaten?
Testdaten sind Bestandteil der Testumgebung
Sie dienen dort unterschiedlichen Zwecken.
Während Umgebungsdaten bereits vor der Testdurchführung für das Einrichten der Testumgebung benötigt werden, dienen Basisdaten der eigentlichen Testdurchführung; daher können sie notfalls vor Beginn des Testlaufs eingepflegt werden. Die Eingabedaten gelangen während der Testdurchführung in das zu testende System und erreichen somit die Testumgebung. Die Ausgabedaten liegen erst nach der Testdurchführung in der Testumgebung vor.
Testdaten werden für alle Teststufen und Testarten benötigt
Kruse formuliert [Krus11, S. 5] unter Eigenschaften von Testdaten u.a., dass sie »für alle Teststufen und Testarten benötigt« werden. Damit ist ihr Einsatzzweck beschrieben.
Testdaten sind abhängig von der Domäne
Testdaten sind sehr stark abhängig von der Domäne, für die die zu testende Software implementiert wird.
Denken Sie an Ihren letzten Einkauf im Internet. Stellen Sie sich diesen als Testfall vor: Sie haben aus Artikeln gewählt (Basisdaten), sind zum Warenkorb gewechselt (Ausgabedaten: Warenkorb mit Artikeln, Preisen, Steuer usw.) und haben später Ihre Adressdaten eingegeben (Eingabedaten). Die vergessene Postleitzahl wurde mit einer Fehlermeldung quittiert (Ausgabedaten: Fehlermeldung). Als Schnittstelle zwischen dem System und dem Benutzer dient eine GUI.
Sogar innerhalb des Bereichs Testen eingebetteter Systeme unterscheiden sich die Testdaten. Denn sie kommen aus der Domäne des zu testenden Gerätes: Für das Testen von Videogeräten verwenden die Tester spezielle Videos (wie das Fernsehtestbild von früher), für Audiogeräte spezielle Audiodateien. Die Testbilder und Audiodateien erhalten sie als Testdaten vom Fachspezialisten der Domäne (auch deshalb empfiehlt es sich, Fachspezialisten, wie z.B. Elektroingenieure, in die Testaktivitäten einzubeziehen, z.B. für Reviews oder zur Unterstützung beim Testdesign).
Verfügt Ihr Auto über einen Einparkassistenten? Sensoren an Vorder- und Hinterseite des Fahrzeugs (Eingabeschnittstelle) liefern Eingabewerte für das System. Ein Monitor (Schnittstelle zum Benutzer) gibt mit farbigen Markierungen den verbleibenden Abstand zum nächsten Fahrzeug oder einem anderen Hindernis an. Ein zunehmender PiepTon (Ausgabedatum) aus dem Lautsprecher (Schnittstelle zum Benutzer) geht in einen Dauerton über, wenn das Hindernis touchiert wurde.
Testdaten können komplex und/oder umfangreich sein
Wie wir später noch sehen werden, treffen diesen Eigenschaften z.B. auf die Testdaten für den Test eingebetteter Systeme zu.
Aber auch Integrationstests und Performance-Tests können komplexe Testdaten aufweisen. Die durchzuführenden Testfälle greifen auf Daten zu, die in verschiedenen (Teil-)Systemen abgelegt sind, sodass sich Teile »zusammengehörender« Datensätze auf mehrere (Teil-)Systeme erstrecken. Die Testdaten eines bestimmten Testdatensatzes müssen dann über all diese Systeme hinweg konsistent sein.
Testdaten können altern – zeitliche Relevanz
Testdaten können »zeitlich relevant sein«, ein Verfallsdatum haben »bzw. müssen zu einem bestimmten Zeitpunkt vorhanden oder erzeugbar sein« [Krus11, S. 5].
Beispiel: Zeitlich relevante Testdaten (1)
Ein Onlineshop gewährt jedem Kunden einen zeitlich begrenzten Rabattgutschein auf Gesellschaftsspiele. Dieser Rabattgutschein soll den Kunden in den zehn Tagen vor und während seiner Gültigkeitsdauer angezeigt werden. Der Rabattgutschein soll nur während der Gültigkeitsdauer angeklickt werden können, um den Kunden auf die Seite mit den Gesellschaftsspielen weiterzuleiten. Zu allen anderen Zeiten soll der Gutschein nicht angezeigt werden.
Wann kann der Tester folgende Testfälle durchführen (ohne an Datumseinstellungen zu manipulieren)?1
(1) Gutschein angezeigt, aber nicht klickbar.(2) Gutschein angezeigt, klickbar, leitet den Kunden weiter.(3) Gutschein nicht angezeigt.Beispiel: Zeitlich relevante Testdaten (2)
Registrierte Kunden von Mein Onlineshop können sich anzeigen lassen, welche Artikel sie in den letzten vier Wochen oder sechs Monaten gekauft haben.
Liegen für den gewählten Zeitraum und diesen Kunden keine Umsätze vor, so soll das System dem Kunden den Hinweis anzeigen »Im gewählten Zeitraum wurde nichts gekauft«. Außerdem soll das System eine Schaltfläche »Ich will shoppen« enthalten und den Kunden auf eine Seite mit besonderen Angeboten weiterleiten.
Testdaten können altern – Fragmentierung
Einen anderen Aspekt des Alterns von Testdaten stellt das Fragmentieren dar. Dieses beeinträchtigt die Zugriffszeiten auf die Daten.
Das Fragmentieren bewirkt, dass logisch zusammengehörende Daten auf dem Speichermedium physisch nicht an einer Stelle, sondern auf mehrere Stellen verteilt gespeichert sind. Zusammengehörende Daten sind durch Verweise miteinander verbunden. Beim Auslesen der gespeicherten Daten greift das System nun nicht auf nur einen Ort auf dem Datenträger zu, sondern beginnt bei der ersten Datenposition und folgt den Verweisen von einem Speicherort zum nächsten – bis die Datei vollständig gelesen ist. Der Zeitaufwand für das Lesen derart verteilter Daten erhöht sich, der Benutzer spürt dies an länger werdenden Wartezeiten.
Dieser Nachteil der Fragmentierung lässt sich durch ein Defragmentieren beheben. Einige Systeme führen dies automatisch in regelmäßigen Abständen durch. Datenbankadministratoren planen ggf. Defragmentierungen im Wartungsplan des Datenbanksystems.
Testdaten können sich verbrauchen
Manche Testdaten leben sozusagen ewig. Dies gilt z.B. für Bestandsdaten wie Postleitzahlenverzeichnisse oder andere unveränderliche Daten in der Testumgebung.
Die Lebensdauer anderer Daten dagegen kann äußerst kurz ausfallen.
Beispiel: Mein Onlineshop – erstes Anzeigen eines neu registrierten Kunden
Ein neuer Kunde entdeckt Mein Onlineshop. Er wird fündig, füllt seinen Warenkorb, führt den Registrierungsprozess aus und schließt den Kauf ab. Das System bestätigt den erfolgreichen Abschluss mit einer Willkommensmeldung. Anschließend ruft der Kunde »Mein Konto« auf. Diese Seite wird nun zum ersten Mal für diesen Kunden angezeigt. Alle weiteren Aufrufe stellen kein »erstes Mal anzeigen« mehr dar.
Da die Testdaten also »verbraucht werden« [Krus11, S. 5], müssen fortlaufend »neue« Testdaten erstellt oder der Testdatenbestand »zurückgesetzt« werden.
Beispiel: Bankkonto – erste Kontobewegung
Auch die erste Kontobewegung auf neu angelegtem Bankkonto kann man nur einmal testen. Der Kontostand zuvor war 0,00 und ist nun um den Betrag des gebuchten Umsatzes höher/niedriger. Die Vorbedingungen aller weiteren Kontobewegungen weichen von der ersten insofern ab, als dass sie alle eine »Vorgängerin« aufweisen.
Daher muss man erneut ein Konto anlegen, um ein Konto ohne Kontobewegungen zu haben.
Beispiel: Testfall »Erste Umsatzbuchung«
Vorbedingung:
Neu angelegtes Bankkonto ohne Umsatzbuchungen für Kunde Leo Mayer. System zeigt in der Oberfläche der Anwendung den Namen des Kontoinhabers, die IBAN, den aktuellen Kontostand von 0,00 Euro an und den Hinweis »Für dieses Konto liegen keine Buchungen vor«.
Testschritt:
Buche Geldeingang erster Umsatz: Leo erhält 50,00 Euro Taschengeld.
Nachbedingung:
System zeigt in der Oberfläche der Anwendung den Namen des Kontoinhabers, die IBAN, die Umsatzbuchung Gutschrift 50,00 Euro und den neuen Kontostand von 50,00 Euro an. (Der Hinweis »Für dieses Konto liegen keine Buchungen vor« wird nicht mehr ausgegeben.)
Der Datensatz, der das »jungfräuliche« Bankkonto von Leo Mayer darstellt, ist damit verbraucht.
Testdaten unterliegen einem Lebenszyklus
Ähnlich wie die im zu testenden System verarbeiteten Daten unterliegen die Testdaten einem Lebenszyklus (Data Life Cycle, Test Data Life Cycle). Während das Datenlebenszyklusmanagement (engl. Data Life Cycle Management) die verschiedenen Aspekte im Leben der Daten behandelt, fokussiert das Testdatenlebenszyklusmanagement (engl. Test Data Life Cycle Management) auf die Testdaten.
Raghuraman [Ragh13] beschreibt auf seinem Blog über Testdatenmanagement einen Testdatenlebenszyklus. Dieser ähnelt dem Datenlebenszyklus und besteht aus folgenden Phasen, welche die Testdaten durchlaufen:
Anforderungsermittlung
(Requirement Gathering & Analysis)
Planung und Entwurf
(Planning and Design)
Testdatenerzeugung
(Test Data Creation)
Testdatenvalidierung
(Test Data Validation)
Testdatenwartung
(Test Data Maintenance)
Ein ähnlicher Lebenszyklus lässt sich aus dem von Eckehard Kruse [Krus11] beschriebenen Testdatenmanagementprozess herauslesen:
TD definieren
TD erzeugen
TD bereitstellen
TD vergleichen
TD dokumentieren
TD archivieren
Dieser Prozess stellt eine Verbindung zwischen Testmanagement und Datenmanagement in Form des Testdatenmanagements dar.
Was für den Schutz der Daten während des Datenlebenszyklus gilt, ist analog auf die Testdaten anzuwenden. Dies gilt insbesondere für die Regelungen zum Datenschutz.
Testdaten können echt oder synthetisch sein
Testdatenbestände können Echtdaten enthalten. Das sind z.B. Kopien von Produktionsdatenbeständen. Diese decken nicht alle möglichen Datenkonstellationen ab, weshalb sie durch synthetische Daten ergänzt werden.
Da echte Daten in Testumgebungen ein datenschutzrelevantes Risiko darstellen, wären aus Sicht des Datenschutzes vollständig synthetische Datenbestände vorzuziehen.
In Kapitel 5 werden wir die verschiedenen Wege zum Gewinnen von Testdaten sowie deren Vor- und Nachteile näher betrachten.
Testdaten können Datensammlungen sein (z.B. bei [
Held16
])
Testdatenbestände können aus Datenmengen verschiedener Datenquellen zusammengestellt sein. Held griff z.B. für seine Arbeit über Metriken für Testdaten [Held16] auf Datensammlungen zurück. Diese enthielten z.B. Daten aus Studien und Echtdaten.
Datensammlungen bieten sich in Domänen an, deren Testdaten hochkomplex und daher schwer künstlich herzustellen sind (bei [Held16] z.B. Patientenakten mit Bildern).
Testdaten können Risiken darstellen
Echtdaten in Testumgebungen stellen ein Datenschutzrisiko dar, wenn sie sensible Daten im Sinne der Datenschutzgesetze oder Unternehmensgeheimnisse enthalten.
Testdaten können ein Testprojektrisiko sein: Gehen Testdaten verloren oder stehen sie aus irgendwelchen Gründen nicht rechtzeitig für die Testdurchführung zur Verfügung, dann führt das zu Verzögerungen im Testzyklus. Wenn der Testzyklus wegen eines unverrückbaren Auslieferungstermins nicht verlängert werden kann, bedeutet das, dass das Testteam nicht alle geplanten Testfälle durchführen wird.
Die Software muss ggf. mit ungetesteten oder nicht ausreichend getesteten Funktionalitäten ausgeliefert werden. Fehler, die mit den nicht gelaufenen Testfällen entdeckt worden wären, findet dann eventuell der Kunde oder der Endbenutzer. Insofern können Testdaten auch ein Produktrisiko darstellen. Das trifft genauso auch auf ungeeignete Testdaten zu.
Weitere Eigenschaften
Danach betrachtet, was die Testdaten darstellen, kann man folgende weitere Eigenschaften feststellen. So können Testdaten (vgl. [Krus11, S. 5])
fachliche Logik enthalten,
»Vergleichsdaten sein«,
»ungültige Systemzustände darstellen«,
»auch fiktive, unrealistische, historische oder zukünftige Inhalte enthalten«,
»dynamisch sein«.
In den Testdaten ist das Abbilden ungültiger Systemzustände z.B. gewünscht, um zu testen, wie das System mit Fehlern dieser Art umgeht. Im Rahmen von Funktions- oder Robustheitstests lässt sich mithilfe dieser Daten prüfen, ob das System robust reagiert. Ob es z.B. eine Fehlermeldung ausgibt oder einfach abstürzt.
Unrealistische Testdaten?
Alle synthetisch generierten Testdaten sind fiktive Daten, die daher in gewisser Weise auch als unrealistisch bezeichnet werden könnten.
Andererseits werden Testdaten als unrealistisch betrachtet, wenn sie Fehlerfälle und Sonderfälle abbilden, die nach Meinung manches Entwicklers »so in der Realität nie vorkommen« können.
Die Aufgabe des Testers liegt darin, abzuwägen, wie viel Testaufwand er worauf verwenden und welche Testdaten er nutzen will. Das gilt insbesondere für die sogenannten unrealistischen Testszenarien. Gerade im agilen Bereich ist Software häufigen Änderungen unterworfen, sei es durch geänderte Anforderungen, Refactorings oder auch Optimierungen der GUI. Außerdem dürfen wir den Einfallsreichtum der späteren Nutzer nicht unterschätzen, die manche Eingabefelder oder Prozessabläufe ganz anders nutzen, als die Spezifikation vorsieht. So gesehen wäre es hilfreich, des Öfteren einen Blick in die Produktionsdaten werfen zu können, um sich ein Bild über die tatsächlich im System gespeicherten Daten zu verschaffen – oder auch über die Daten, die es nicht hineinschafften. So ausführlich wird jedoch kein Fehlerprotokoll sein.
3.2Anforderungen an Testdaten – ein Überblick
Widersprüchlichkeit
An Testdaten werden zahlreiche Anforderungen gestellt, die sich zum Teil widersprechen. Die Testdaten sollen zwar möglichst realistisch sein, aber auch Daten enthalten, die das Testen von Fehler- und Sonderfällen ermöglichen.
Unterscheidung
In ihrem Test Data Management Framework (siehe Abschnitt 8.3) unterscheiden Borghers und Demey [BoDe13] vier Gruppen von Anforderungen an Testdaten (»Test Data Requirements«): Da sind zum einen generelle Anforderungen an Testdaten und zum anderen Anforderungen an die Datensicherheit, Datenqualität und Taxonomie.
In diesem Buch werden die Anforderungen wie folgt unterschieden:
inhaltliche Anforderungen,
technische und organisatorische sowie
wirtschaftliche und rechtliche Anforderungen.
Testdatenmanagement
Es ist Gegenstand des Testdatenmanagements (TDM), dafür zu sorgen, dass die Testdaten alle an sie gestellten Anforderungen erfüllen und widersprüchliche Anforderungen gegeneinander gewichtet werden.
3.3Inhaltliche Anforderungen
Welche Anforderungen an Testdaten ergeben sich aus den Erfordernissen des Testens von Software?
Testdaten sollen als solche erkennbar sein
»Testdaten sollen als Testdaten erkennbar sein« [Krus11, S. 5]. Diese Anforderung kann im Widerspruch zur ebenfalls geforderten Realitätsnähe stehen. Jedoch sollten die Daten so gestaltet sein, dass sie für die zu testenden Funktionalitäten geeignet sind und im Falle eines fehlgeschlagenen Testfalles eine Analyse unterstützen.
Beispiel: Integrationstest für Mein Onlineshop, Kundenservicemodul
Im Integrationstest für den Onlineshop wird als Testdatenbestand eine anonymisierte und ergänzte Kopie der Produktionsdaten verwendet. Während des Anonymisierens wurden die Vor- und Nachnamen sowie Postanschriften und weitere Daten ersetzt.
Ein Beispiel: Die Wohnorte und Straßen wurden ersetzt durch Anschriften in Entenhausen, Springfield, Gotham City und ähnliche.
Testdaten bzw. Testumgebungen sind verschiedenen Risiken ausgesetzt, z.B. bewussten Angriffen Außenstehender. Sollte der Datenbestand durch einen Angreifer abgezogen werden, so kann die Behauptung des Angreifers, Echtdaten zu besitzen, schnell widerlegt werden, da anhand der Datensätze sichtbar ist, dass es sich um Testdaten handelt.
Doch auch versehentliche Fehlkonfigurationen können zu Problemen führen. Werden unabsichtlich Briefe oder Zahlungen aus einem Testsystem tatsächlich in die »echte Welt« versandt, so wird ein Schreiben oder eine Zahlung an Daisy Duck in Entenhausen wahrscheinlich keinen echten Kunden erreichen.
Andererseits kann es manchmal notwendig sein, Testumgebung und Echtumgebung zu verbinden. Dies wird praktiziert, wenn im Test Infrastruktur benötigt wird, die nur in der Echtumgebung zur Verfügung steht, wie z.B. eine Druckstraße. Dann können aus der Testumgebung Druckaufträge (z.B. Anschreiben) an die produktiv verwendete Druckstraße gesendet werden. Diese Schreiben dürfen dann natürlich nicht tatsächlich versandt werden. Falls doch, siehe Daisy Duck in Entenhausen … (Um bei solchen Testläufen derartige Fehler zu vermeiden, werden diese Testläufe bei den Betreibern der Druckstraße avisiert und der Druck erfolgt auf andersfarbiges Papier.)
Testdaten sollen das Testziel unterstützen
