Testen von Data-Warehouse- und Business-Intelligence-Systemen E-Book

Herbert Stauffer

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Serie: Edition TDWI
• Sprache: Deutsch
• Veröffentlichungsjahr: 2013

Seitenzahl: 343

Beschreibung

Business-Intelligence- und Data-Warehouse-Projekte sind anders. Entsprechend andersartig sind auch die in diesem Bereich eingesetzten Testverfahren und -methoden. Praxisorientiert und systematisch beschreibt dieses Buch das Testen von analytischen Systemen und stellt die besonderen Anforderungen hierbei heraus. Es erörtert, welche Tests in den verschiedenen Szenarien sinnvoll sind und wie eine realistische Planung und Vorbereitung eines Testprozesses aussieht. Ausgehend von einem Referenzmodell für das Testen werden Elemente gängiger Testkonzepte sowie Normen und Standards übertragen. Des Weiteren behandeln die Autoren spezifische Methoden wie datengetriebene Tests und gehen auch auf Wirtschaftlichkeitsaspekte und die menschliche Seite beim Testen ein. Dabei verdeutlichen mehrere Praxisbeispiele die Theorie. Direkt anwendbare Checklisten ermöglichen einen schnellen Transfer in die eigene berufliche Praxis. Aus dem Inhalt: • Testen von analytischen Systemen • Testfälle und Definition von Fehlerkategorien • Einfluss der Daten aufs Testen • Testorganisation, -infrastruktur und -betrieb • Testen nach Projektmodellen • Bibliothek von Standardtestfällen • Dokumentenvorlagen Im Anhang befindet sich u.a. ein ausführliches Glossar. In der Edition TDWI erscheinen Titel, die vom dpunkt.verlag gemeinsam mit dem TDWI Germany e.V. ausgewählt und konzipiert werden. Inhaltliche Schwerpunkte dieser Reihe sind Business Intelligence und Data Warehousing.

Leseprobe

Herbert Stauffer ist seit über 20 Jahren Projektleiter, Systemarchitekt und Dozent für Business Intelligence und Data Warehousing. Er ist seit 2008 Co-Leiter des TDWI-Roundtable in Zürich. Seine Arbeitsschwerpunkte sind Systemarchitektur und multidimensionale Datenmodelle sowie qualitative Themen wie Datenqualität und Testen.

Beat Honegger ist Senior BI-Consultant und Partner bei der plus-IT AG in Winterthur. In allen seinen Tätigkeiten als Softwareentwickler, Testing-Consultant, CRM-Berater und seit 10 Jahren als BI-Consultant, Dozent und Instructor war und ist das Testen für ihn eine wichtige Grundlage für erfolgreiche Projekte.

Hanspeter Gisin ist Projektleiter, Data-Warehouse-Designer und SAP BO Instructor und auch als Dozent tätig. Er entwickelt seit mehr als 20 Jahren maßgeschneiderte Business-Intelligence-Lösungen für diverse Kunden. Seine Tätigkeiten umfassen die gesamte Palette von der Aufnahme der Requirements über das Data-Warehouse-Design bis hin zur Reporterstellung.

Testen von Data-Warehouse- undBusiness-Intelligence-Systemen

Vorgehen, Methoden und Konzepte

Edition TDWI

Herbert StaufferBeat HoneggerHanspeter Gisin

Herbert [email protected]

Beat [email protected]

Hanspeter [email protected]

Fachlektorat: Marcus Pilz, pilmar.comLektorat: Christa PreisendanzCopy Editing: Ulla Zimpfer, HerrenbergHerstellung: Frank HeidtSatz: Reemers Publishing Services, KrefeldUmschlaggestaltung: Anna Diechtierow, HeidelbergDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition TDWI: Marcus Pilz · [email protected]

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:Buch 978-3-86490-072-3PDF 978-3-86491-407-2ePub 978-3-86491-408-9

1. Auflage 2013Copyright © 2013 dpunkt.verlag GmbHWieblinger Weg 1769115 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 0

Vorwort

Business Intelligence (BI) ist anders. – Sowohl in den Projekten, der Systemarchitektur wie auch im Betrieb gibt es markante Unterschiede von analytischen Systemen gegenüber der Welt der klassischen Informatiklösungen. In BI-Systemen wird selten programmiert. Dafür wird parametrisiert und Datenbankabfragen werden visuell modelliert. Transaktionsorientierte Datenerfassungen sollten nie stattfinden, sondern es werden teils riesige Datasets aus den Quellsystemen gelesen1. Referenzielle Integrität wird von BI-Entwicklern nicht angewendet. Mit guten Grund: Durch die unterschiedlichen Ladezeiten aus mehreren Systemen hat sich der Verzicht bewährt, da sonst einige Daten nicht geladen werden könnten.

Wegen dieser Verschiedenartigkeit hat Gartner in einer Studie bereits vor einigen Jahren empfohlen, die verschiedenen Fähigkeiten, die für den Aufbau und Betrieb dieser Systeme notwendig sind, zusammenzufassen [Strange/Hostmann 2003]. Daraus sind die heute üblichen Business Intelligence Competence Center, kurz BICC, entstanden.

Wenn es schon überall Unterschiede gibt, muss dies auch einen Einfluss auf die Testverfahren haben. So war unsere Annahme. Auch sind wir bei unseren Recherchen verschiedener Untersuchungen und der Auswertung unserer Praxiserfahrungen auf Unterschiede und Gemeinsamkeiten gestoßen. Es war das Ziel des Autorenteams, ein Buch zu schreiben, das Theorie und Praxis vereint. Dabei sind viele Erfahrungen und Beispiele aus unserer bisherigen Praxis eingeflossen.

Zum Aufbau des Buches: Im ersten Kapitel (Einführung) werden ausführlich die Eigenheiten von BI-Systemen und des Testens von analytischen Systemen erklärt. Ergänzt wird dieses erste Kapitel durch Beispiele aus der Praxis, die auch die Problemfelder und Fallstricke aufzeigen. Außerdem wird erklärt, wieso vollständiges Testen nicht möglich ist und wie viele Prüfungen sinnvoll sind, gemessen an der Kritikalität des Systems. Darin enthalten sind Überlegungen zur Wirtschaftlichkeit des Testens.

In Kapitel 2 wird ein Referenzmodell vorgestellt, das den roten Faden durch alle weiteren Kapitel bildet. Verschiedene Normen, Standards und Projektmodelle werden auf Vollständigkeit überprüft und mit dem Referenzmodell verglichen. Das Referenzmodell kann umgekehrt auch als Vorgehensmodell angewandt werden. Verschiedene Verweise auf die folgenden Kapitel präzisieren das Modell. Somit ist es auch eine Art Dach über mehrere Normen und Vorgehensweisen, die nur einen Teilaspekt abbilden.

In Kapitel 3 werden verschiedene gängige Normen und Standards erklärt und auf ihre Eignung für das Testen von Business-Intelligence-Systemen überprüft. Das Kapitel bietet Hilfestellung, wenn in einer Unternehmung bereits ein oder mehrere dieser Normen eingesetzt werden, um diese in den richtigen Bezug zu Business-Intelligence-Projekten zu setzen und anzuwenden.

In Kapitel 4 liegt der Schwerpunkt auf der Definition von geeigneten Testfällen (engl. Test Cases) und der Klassifizierung von Fehlern. Dieses Kapitel konzentriert sich fast ausschließlich auf die operative Testvorbereitung. Zum Bestimmen der notwendigen Testfälle haben wir ein eigenes Drei-Schritte-Vorgehen entwickelt. Anschließend werden die Inhalte der Testfälle definiert. Hier gibt es den ausführlichen Weg nach ISO 9126 oder FURPS (Functionality, Usability, Reliability, Performance und Supportability) oder das vereinfachte Verfahren mit Checklisten.

Kapitel 5 beschäftigt sich eingehend mit der Bedeutung der Daten, insbesondere der Quelldaten. In diesem Kapitel geht es nochmals um die Definition von Testfällen. Diesmal aus der Sicht der Daten. Ergänzt wird das Kapitel um die Themen Datenqualität und Data Governance, die einen wichtigen Einfluss bei Business-Intelligence-Projekten haben.

Das nachfolgende Kapitel 6 enthält einleitend eine Beschreibung der verschiedenen Arten von Systemlandschaften. Die einfachste Architektur besteht aus einem einzigen Server für Produktion, Entwicklung und Test. Dieses Modell ist zwar sehr übersichtlich und einfach zu verstehen. An die Implementierung von neuen Änderungen und Anforderungen werden jedoch hohe qualitative Anforderungen gestellt. Es gilt in jedem Fall, eine Produktionsstörung zu vermeiden. Demgegenüber steht eine hochkomplexe Architektur mit mehreren Entwicklungs- und Testsystemen, die hohe Anforderungen an das Testmanagement und die Projektleitung stellt. Gilt es doch, hier die Übersicht nicht zu verlieren. Anschließend gibt das Kapitel einen ausführlichen Überblick über die Durchführung der Testfälle und die Fehlerbehandlung in den verschiedenen Testlandschaften. Der Testmanager in diesem iterativen Prozess übernimmt dabei die Rolle eines Dispatchers.

Ein weiterer wichtiger Aspekt des Testens sind die Testdaten. In der Praxis werden häufig bereits die vorhandenen Daten verwendet. Das ist als Leitgedanke ein guter Ansatz, doch es gibt ein paar spezielle Anforderungen an das Testen mit produktiven Daten, wie beispielsweise die Berücksichtigung der Datenschutzanforderungen, die unbedingt beachtet werden müssen.

Neben den organisatorischen Anforderungen an den Testprozess spielt der Mensch eine wichtige Rolle. Unterschiedliche Charaktere reagieren anders. Persönliche Motive beeinflussen das Handeln. In Kapitel 7 behandeln wir die psychologische Seite des Testens.

In Kapitel 8 werden die Projektmodelle auf ihre Anwendbarkeit für Business Intelligence überprüft. Wir unterscheiden die Projektmodelle nach ihren vier Hauptkategorien: Phasenmodelle, iterative Modelle, Prototyping und agile Projektmethoden. Je nach Methode hat Testen eine unterschiedliche Bedeutung. Bei den neueren, nicht linearen Projektmethoden stehen teilweise recht kurze Zeitfenster zum Testen zur Verfügung. Dies macht das Testen nicht einfacher.

In Kapitel 9 sind speziellere Themen zu finden, die in diesem Buch zwar nicht abschließend behandelt werden, aber doch der Vollständigkeit halber aufgegriffen werden sollten und als Denkanstöße für die Praxis zu verstehen sind. Die einzelnen Themen stehen nicht in einem direkten Zusammenhang, vielmehr ergänzen sie die zuvor behandelten Themen. Zu Beginn des Kapitels werden Kategorien von Testtools definiert. Auf eine Bewertung der Tools haben wir bewusst verzichtet, da eine Bewertung nur eine Momentaufnahme der vorhandenen Releases sein kann. Schon in einem halben Jahr nach Veröffentlichung des Buches wäre die Liste nicht mehr aktuell.

Kapitel 10 führt Testfälle auf, die wir den verschiedenen Komponenten einer Referenzarchitektur zugeordnet haben. Diese Sammlung ermöglicht einerseits die schnelle Definition von Testfällen und andererseits bildet sie die Basis für eine eigene Bibliothek von Testfällen.

Kapitel 11 enthält vier Dokumentenvorlagen, die wir für eine minimale Testdokumentation in der Vorbereitung und während des Testbetriebs als notwendig erachten.

Wie in jedem guten Fachbuch gibt es auch hier einen Anhang. Die Literaturund Linkliste gibt Informationen zur weiteren Vertiefung. Das ausführliche Glossar hilft die verschiedenen Begriffe nachzuschlagen. Für uns war es ein wichtiges Hilfsmittel beim Schreiben des Buches, da wir selbst im Alltag die Begriffe teilweise unterschiedlich verwendet haben. Oder wir hatten mehrere Begriffe für denselben Sachverhalt. Ein Stichwortverzeichnis rundet das Buch ab.

Es ist nicht notwendig, das vorliegende Buch von Anfang bis Schluss durchzulesen. Es ist eher als Nachschlagewerk geeignet. Ein guter und wichtiger Einstiegspunkt ist dazu die Darstellung des Referenzmodells in Abbildung 2–1 auf S. 16.

Ein Projektplan ohne Testphase

Ein Industrieunternehmen ist dabei, eine neue Business-Intelligence-Plattform einzuführen. Damit soll eine einheitliche Lösung für Reports und Analysen zur Verfügung stehen. Verschiedene Auswertungen aus anderen Systemen sollen migriert werden. Einige Auswertungen haben strategische Bedeutung und unterstehen rechtlich den Regeln des IKS (internen Kontrollsystems)2.

Der zuständige Projektleiter hatte zwar einen Projektplan. Darin enthalten waren jedoch keine Aufwände für das Testen. Es war einzig ein zweiwöchiger Projektunterbruch geplant. Hier hatte er Tests durch Fachanwender vorgesehen, die am Ende die Ordnungsmäßigkeit der neuen Plattform bestätigen sollten. Der Projektleiter hatte nicht vorgesehen, entsprechende Testfälle zu definieren oder zumindest Rahmenbedingungen für die Tester zu liefern. Genauso wenig waren Aufwände für Fehlerkorrekturen vorgesehen.

Obiges etwas überspitzt formulierte Beispiel zeigt auf, wie teilweise mit Tests in der Projektdurchführung umgegangen wird. Das ausschließliche Verlagern der Verantwortung auf die Endbenutzer zeigt das geringe Verständnis des Projektleiters für vollständiges Testens auf. Der ganze Projektplan benennt keine Tester, enthält keine Abnahmekriterien und keine Aufwände für Fehlerkorrekturen. Welche Tests sinnvoll sind und wie eine realistische Planung und Vorbereitung aussieht, wird in diesem Buch ausführlich beschrieben. Um die Theorie verständlicher zu vermitteln, haben wir grau hinterlegte Praxisbeispiele eingefügt. Die Beispiele wurden auf die wesentlichen Aspekte reduziert und anonymisiert.

Beim Schreiben des Buches war die einheitliche Verwendung der Begriffe eine weitere Herausforderung. Wir selbst haben festgestellt, dass im Alltag einige Begriffe mehrdeutig verwendet werden. Durch das Glossar am Ende des Buches haben wir für uns einige Begriffe vereinheitlicht. Ein weiteres Dilemma war, ob wir englische oder deutsche Bezeichnungen nutzen. Wir haben uns entschieden, die Bezeichnungen in nur einer Sprache zu verwenden, nämlich in Deutsch. Nur englische Fachbegriffe, die auch in der deutschen Sprache üblich sind, haben wir belassen, beispielsweise das Wort »Data Warehouse«. Uns ist bewusst, dass in der beruflichen Praxis teilweise die englischen Begriffe üblicher sind. Eine kurze Übersetzungsliste haben wir dazu im Anhang aufgeführt.

Eine Ausnahme sind Simulations- und Planungssysteme. Hier findet eine Dateneingabe statt. Die erfassten Parameter und die Analysen werden anschließend persistent in der Datenbank gespeichert.

Die gesetzlichen Vorschriften für das Vorhandensein eines internen Kontrollsystems (IKS) sind in nationalen Gesetzen unterschiedlich geregelt. Üblicherweise ist die Geschäftsleitung in der Verantwortung, dass ein Kontrollsystem vorhanden ist, das alle Systeme und Prozesse überprüft, die für die finanzielle und strategische Führung der Unternehmung eingesetzt werden.

Inhaltsverzeichnis

1     Einführung

1.1     Ungenügendes Testen ist leider Praxis

1.2     Wirtschaftlichkeit des Testens

1.3     Vollständiges Testen ist nicht möglich

1.4     Gegenüberstellung von BI- mit klassischen Projekten

1.5     Einfluss von Daten aufs Testen

1.6     Die 7 Prinzipien des Testens

1.7     Validieren und Verifizieren

1.8     Was Testen nicht kann

2     Referenzmodell für das Testen

2.1     Drei Phasen des Testprozesses

2.2     Organisation

2.2.1     Ebene Testmanagement

2.2.2     Ebene Testoperation

2.3     Elemente

2.3.1     Aktivitäten

2.3.2     Menschen und Rollen

2.3.3     Werkzeuge (Tools und Daten) und Hilfsmittel

2.4     Im Dreiklang: Organisation, Elemente und Phasen

2.4.1     »Würfel« in der Phase Planung

2.4.2     »Würfel« in der Phase Durchführung

2.4.3     »Würfel« in der Phase Abschluss

3     Methoden und Standards

3.1     V-Modell

3.2     IEEE

3.2.1     IEEE 829 – Software Test Documentation

3.2.2     IEEE 1008 – Unit Testing

3.2.3     IEEE 1012 – Software Verification and Validation

3.3     Rational Unified Process (RUP)

3.4     ISO

3.4.1     ISO/IEC 9126 – Qualitätsmerkmale

3.4.2     ISO/IEC 29119

3.5     Cabinet Office

3.5.1     ITIL 2011 – Validation and Testing

3.5.2     PRINCE2

3.6     ISACA

3.6.1     COBIT

3.6.2     CONCT

4     Definition von geeigneten Testfällen und Fehlerkategorien

4.1     Bestimmung von zu testenden Komponenten

4.1.1     Schritt 1: Aufzeichnen des gesamten Systems

4.1.2     Schritt 2: Kennzeichnen der Komponenten

4.1.3     Schritt 3: Ableiten der Testfälle

4.2     Zu prüfende Qualitätsmerkmale (nach ISO 9126)

4.2.1     Funktionalität (engl. Functionality)

4.2.2     Benutzbarkeit (engl. Usability)

4.2.3     Zuverlässigkeit (engl. Reliability)

4.2.4     Effizienz (engl. Efficiency)

4.2.5     Wartbarkeit (engl. Maintainability)

4.2.6     Übertragbarkeit (engl. Portability)

4.3     Testmethoden und Testarten

4.3.1     Statische Testverfahren

4.3.2     Dynamische Testverfahren

4.3.3     Gliederung der Testverfahren nach verschiedenen Kriterien

4.4     Teststufen

4.5     Definition und Beschreibung von Testfällen

4.6     Vereinfachte Testfälle mithilfe von Checklisten

4.7     Fehlerkategorien

5     Einfluss der Daten aufs Testen

5.1     Datengetriebene Testfälle als Schwerpunkt in Business Intelligence

5.1.1     Datenqualität – Validieren

5.1.2     Datenqualität – Verifizieren

5.1.3     Funktionale Softwarequalität in Bezug zu den Daten

5.1.4     Nicht funktionale Softwarequalität in Bezug zu den Daten

5.1.5     Bedeutung von datengetriebenen Testfällen

5.2     Datenqualität und Testen – ein fließender Übergang

5.3     Berücksichtigung der Data Governance

5.3.1     Daten als Werte

5.3.2     Daten als Eigentum (organisatorische Rollen)

5.3.3     Hilfsmittel (Einsatz von Tools)

6     Testorganisation, -infrastruktur und -betrieb

6.1     Berücksichtigen der verschiedenen Systemumgebungen

6.1.1     1-System-Landschaft

6.1.2     2-Systeme-Landschaft

6.1.3     3-Systeme-Landschaft

6.1.4     4-Systeme-Landschaft

6.1.5     5-Systeme-Landschaft

6.2     Testdatenmanagement

6.2.1     Definition von geeigneten Sets

6.2.2     Anonymisieren und Verändern

6.2.3     Berechtigungen

6.2.4     Generieren von Testdaten

6.3     Testen in Szenarios

6.4     Vorbereiten des Testbetriebs

6.4.1     Systeme bereitstellen

6.4.2     Schulung der Tester (Test der Schulung)

6.4.3     Minimales Kommunikationskonzept

6.5     Testbetrieb

6.5.1     Aufgaben des Testmanagements

6.5.2     Iterativer Prozess auf der Ebene Testoperation

6.5.3     Rolle des Dispatchers

6.5.4     Auswirkung von neuen Versionen auf Testfälle

6.6     Logs

6.6.1     Testlog

6.6.2     Fehlerlog

6.7     Auswertungen und Reports

6.8     Abschluss

6.8.1     Schlussbericht

6.8.2     Systeme bereinigen

6.8.3     Lessons Learned

6.8.4     Transfer

7     Die menschliche Seite beim Testen

7.1     Rollen im Testprozess

7.2     Rollenkonflikt zwischen Softwareentwickler und Tester

7.3     Rollenkonflikt zwischen Projektleiter und Testmanager

7.4     Zwei Risikotypen des Auftraggebers in der Testphase

7.5     Nachlassende Aufmerksamkeit bei Testern

7.6     Wirtschaftlichkeit versus Ethik und Moral

8     Testen nach Projektmodellen

8.1     Phasenmodelle

8.2     Iteratives Projektvorgehen

8.3     Prototyping

8.4     Agile Projektmethoden

9     Sonderthemen

9.1     Bewertung der verschiedenen Methoden und Standards

9.2     Checkliste von vermeidbaren Fehlern im Testmanagement

9.3     Einsatz von Softwaretools

9.3.1     Kategorien

9.3.2     Testautomatisierung

9.3.3     Debugger

9.3.4     Fehlernachverfolgung

9.4     RACI-Matrix im Testprozess

9.5     Session Based Testing

9.6     Testen im Umfeld neuer Technologietrends

9.7     Einsatz von spezialisierten Testteams

9.8     Zwei besonders zu beachtende Situationen

9.8.1     Situation 1: Wenn das Testsystem zur Produktion light mutiert

9.8.2     Situation 2: Korrekte Aufwandschätzung bei 1:1-Ablösung

9.9     Die Aus- und Weiterbildung zum Certified Tester

10   Bibliothek von Standardtestfällen

10.1   Architekturmodell und Komponenten

10.2   Standardtestfälle

10.2.1   Generelle Testfälle

10.2.2   Datenintegration und Schnittstellen zu den Datenquellen

10.2.3   Datenspeicherung

10.2.4   Informationsbereitstellung

10.2.5   Plattform und Infrastruktur

10.2.6   Externe Systeme und Prozesse

10.3   Datengetriebene Testfälle

10.4   Spezielle Projektsituationen

10.5   Kontrollpunkte im Auditprozess

10.5.1   Datenquellen und Schnittstellen

10.5.2   Datenintegration

10.5.3   Persistente Datenhaltung

10.5.4   Informationsbereitstellung und Informationsempfänger

10.5.5   Plattform

11   Dokumentenvorlagen

11.1   Testkonzept

11.1.1   Testkonzept (Master Plan)

11.1.2   Inhalt

11.1.3   Einleitung

11.1.4   Werkzeuge, Techniken, Methoden und Metriken

11.1.5   Detailtestplanung

11.1.6   Logs und Dokumente

11.1.7   Testdurchführung

11.1.8   Abschluss

11.1.9   Anhang

11.2   Testfallspezifikation

11.3   Testlog

11.4   Fehlerlog

12   Anhang

12.1   Literaturliste

12.2   Weblinks

12.3   Begriffsübersetzung Englisch-Deutsch

12.4   Glossar

12.5   Nachweis der verwendeten Grafiken

Index

1 Einführung

»Debugging is twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition, not smart enough to debug it. «

Brian Wilson Kernighan (kanadischer Informatiker undKoautor der Programmiersprache C)

Das Zitat von Brian Kernighan klingt zwar witzig, doch es war durchaus ernst gemeint. Brian brachte in einem Satz auf den Punkt, dass an einen Tester hohe intellektuelle Anforderungen gestellt werden.

Ein weiteres Zitat aus der Praxis stammt von einem Softwareentwickler in einer Lebensversicherung: »Ich habe noch anderes zu tun, als meinen Code zu testen.« Eines seiner Module hatte gerade eine größere Produktionsstörung verursacht, nachdem er es ohne Abnahmeprozess und ungetestet im Produktionssystem implementiert hatte. Die notwendige Einsicht fehlte bei diesem Entwickler und führte zu seiner recht ungehaltenen Äußerung.

Eine weitere Situation spielte sich einmal in einer Großbank ab. Es sollte ein Workshop mit einem erfahrenen Business-Analysten zur Definition von geeigneten Testfällen geplant werden. Ein großer Releasewechsel stand in den nächsten Monaten an und es waren noch keine Test- und Abnahmeverfahren definiert. Der erfahrene und ansonsten sehr kompetente Analyst lehnte das Meeting telefonisch ab mit den Worten: »Wieso soll ich mir die ganze Mühe für das Testen machen. Das Eröffnen eines Fehlers (engl. Defect) ist billiger.« Gemeint hatte er, dass er bedeutend weniger Zeit für die Eröffnung eines Störungstickets benötigt als für die Definition und die Durchführung von Testfällen (engl. Test Cases). Ob die Behebung eines Fehlers in der Produktion wirklich billiger ist, hat er sich in dieser Situation sicher nicht überlegt.

Diese drei Aussagen zeigen einige Eigenheiten des Testens auf:

1. Testen benötigt Intelligenz und Erfahrung.

2. Testen ist mühsam und unbeliebt.

3. Testen muss wirtschaftlich sein und bleiben.

4. Der Nutzen bzw. die Notwendigkeit ist den meisten nicht bewusst oder bekannt.

1.1 Ungenügendes Testen ist leider Praxis

Ungenügendes oder fehlendes Testen ist leider weit verbreitet. Nicht von ungefähr wird bei Softwarelösungen gerne der Begriff des »Management by banana« verwendet. Gemeint ist »das Produkt beim Kunden reifen lassen«. Die Ursache liegt nicht in der bösen Absicht der Entwickler, sondern häufiger in deren Unwissenheit und Unerfahrenheit. Projektteams sind meistens bestens ausgebildet in den einzusetzenden Technologien, haben ein fachliches Grundwissen und sind geschult in den verschiedensten Projektmodellen. Selten verfügt aber nur ein einziges Mitglied über eine entsprechende Ausbildung im Testen.

In vielen Fachbüchern zum Thema Data Warehousing und Business Intelligence ist zwar beschrieben, wie Systeme gebaut und später betrieben werden müssen. Aber selten enthält eines dieser Bücher ein Kapitel zum Testen. Sofern in einem Abschnitt das Testen erwähnt ist, wird es nur auf ein oder zwei Seiten behandelt. Im Verhältnis zu den mehreren Hundert Seiten einzelner Bücher ist dies auch eine klare Aussage zum Testverständnis der Autoren.

Aufgrund des fehlenden Wissens wird mit dem Testen viel zu spät begonnen. Irgendwo am Ende einer Entwicklungsphase folgt in den meisten Projektplänen die Testphase, die nur als Vorgang definiert ist, der nicht weiter gegliedert ist. Dabei wird übersehen, dass ohne Testplanung leider keine effektive Testdurchführung stattfinden kann. Dies bedeutet, dass Testen schon viel früher in den Projekten zu beginnen hat. Idealerweise schon kurz nach dem Projektstart.

Eine objektbezogene Planung ist heute in den meisten Projektvorgehensmodellen üblich für Analyse, Spezifikation und Realisierung. Das heißt, es wird für jeden Vorgang ein messbares Lieferergebnis als Output definiert. Oder, mit anderen Worten, jede Aktivität liefert am Ende ein bewertbares Resultat. Testen wird nur als Vorgang geplant, was meistens der Testdurchführung entspricht. Wenn die Testplanung fehlt, kann jedoch nichts Vernünftiges durchgeführt werden.

Die Verantwortung für ungenügende Tests darf nicht allein dem Projektteam zugeschoben werden. Der Auftraggeber steht genauso in der Verantwortung, im Projektauftrag messbare Akzeptanzkriterien für die einzelnen Lieferobjekte und für das gesamte System zu definieren.

Durch die fehlende Definition von Testfällen dient die Testphase in vielen Projektplänen nur noch als Puffer, um Zeit- oder Kostenüberschreitungen aus anderen Vorgängen aufzufangen. Durch die Verwendung der Testphase für andere Aufgaben werden der Projektplan, das Budget und der Einführungstermin eingehalten. Echte Tests werden nur wenig durchgeführt.

Ein weiteres Problem besteht darin, dass Tests nur durch den Entwickler durchgeführt werden. Er prüft einzig, ob seine Module durchlaufen, ohne abzustürzen. Es existieren keine klar formulierten Testfälle und seine Prüfungen definiert er selbst. Das bedeutet, es werden nur minimale funktionale Modultests durchgeführt.

Wenn Personen der Fachabteilungen in den Testprozess einbezogen werden, sind diese meistens ungenügend vorbereitet. Manchmal kennen sie nicht mal den Zweck des Systems, sondern erhalten einfach den Auftrag: »Das System steht auf dem Server XY bereit, macht mal in den nächsten zwei Wochen ein paar Tests.« Die Testpersonen sind damit überfordert und es finden im definierten Zeitraum gar keine Testaktivitäten statt. Um erfolgreich testen zu können, ist zuvor eine minimale Benutzerschulung notwendig und es müssen formulierte Testfälle vorhanden sein. Zusätzlich müssen die Tester frühzeitig informiert werden, damit sie die benötigte Zeit auch reservieren können.

Eine Ursache für ungenügende Tests ist der Zeitdruck in Projekten. Das Reduzieren der Entwicklungsbudgets lässt eine Umsetzung manchmal nicht mehr zu oder führt zu mangelhafter Qualität. Daher wird jeder Projektleiter eine Testphase einplanen und das Budget dann anderweitig verwenden. Somit kann er zumindest die Funktionen zur Verfügung stellen. Wenn ungenügend getestet wird, gibt es auch keine zu korrigierenden Fehler. Somit erreicht er sein Ziel: die termingerechte Einführung des Systems. Die Folgen muss dann der Betriebsverantwortliche tragen. Er hat jede Menge Produktionsstörungen und muss sehen, wie er diese im Rahmen des im Service Level Agreement (SLA) vereinbarten Budgets behandeln kann. Der Projektleiter kümmert sich nicht mehr darum. Er hat eine unterzeichnete Projektabnahme und ist bereits an der Planung und Umsetzung seines nächsten Projekts.

Der Umgang mit Fehlern (engl. Defects) ist in der Praxis ebenfalls oft ungenügend. Nicht in allen Projekten existieren Vereinbarungen zu Klassifikation von Fehlern und zur Projektabnahme. Die Fehler werden nicht zentral erfasst und die Lösung wird nicht protokolliert. Somit ist am Ende des Projekts nicht bekannt, welche Fehler mit welcher Gewichtung offen sind. Der Einsatz einer Softwarelösung zur Fehlernachverfolgung (engl. Defect-Tracking) würde hier die Arbeit erleichtern, beispielsweise das Open-Source-Tool Bugzilla. Des Weiteren enthalten einige Projektpläne kein Zeitfenster für das Korrigieren der Fehler und das erneute Testen, als ob Systeme nach den ersten Tests vollständig und perfekt wären.

Eine weitere Unsitte ist das Korrigieren der Fehlerprioritäten. Fehler werden in tiefere Klassen eingeordnet, damit das System abgenommen werden kann. Dieses Herunterstufen (engl. Downgraden) von Fehlern nützt längerfristig niemandem. Man erhält dadurch ein System mit ungenügender Qualität.

Die Liste von möglichen Ursachen für ungenügende Tests könnte beliebig fortgesetzt werden. Zusammenfassend kann gesagt werden, dass es sicher keine böse Absicht ist, ein ungenügendes System abliefern zu wollen. Meistens handelt es sich nur um fehlendes oder ungenügendes Testwissen. Dieses Buch möchte diese Wissenslücke schließen und insbesondere noch auf die Eigenheiten des Testens von analytischen Systemen, wie Business-Intelligence-Anwendungen und Data Warehouses, eingehen.

Ein offener Testfall in einer Großbank

Als Tester war ich verantwortlich für die Verifikation eines geänderten Sourcing-Prozesses einer Shared Dimension. Im Testsystem blieb der geplante Ladeprozess längere Zeit unausgeführt und ein Testen war nicht möglich. An einem Abend, zwei Tage vor Ende der Testphase, rief mich der Chefentwickler an und fragte nach, wieso ich den Test nicht abnehme. Ohne meine Abnahme könne das Release nicht eingeführt werden. Das Release bestand aus mehreren Hundert Änderungen am gesamten Warehouse.

Mein Einwand, dass der Ladeprozess noch nie ausgeführt wurde und ich somit keine Tests durchführen kann, interessierte ihn wenig. Seine Antwort war lapidar: »Dann setz deine Testfälle einfache auf ›passed‹. Wir schauen uns das Ganze dann in der Produktion an. Alle anderen machen dies genauso.« Hier musste ich zuerst einmal leer schlucken und tausend Gedanken gingen mir durch den Kopf. Einerseits wollte ich nicht der Verhinderer eines kommenden Release sein. Dies klingt nach Ärger und der späteren Suche nach Schuldigen. Andererseits wollte ich nicht Testfälle auf ›passed‹ setzen, obwohl es nicht stimmte. Dies käme für mich einer vorsätzlichen Lüge gleich. Außerdem glaubte ich nicht daran, dass mir der Chefentwickler später in der Produktion die notwendige Unterstützung zur Behebung des Fehlers geben würde. Auch war ich über die Aussage entsetzt, dass es üblich sei, einfach Tests auf ›passed‹ zu setzen.

Ich entschied mich, bei meinen Prinzipien zu bleiben, und antwortete: »Ich bin nur verantwortlich für die Testfälle und nicht für das gesamte Release. Solange ich die Tests nicht durchführen kann, werde ich sie offen lassen.« Nun spürte der Chefentwickler den Druck, den er auf mich ausüben wollte. Er kümmerte sich um das Problem der nicht durchgeführten Ladeprozesse und er analysierte die Situation. Schlussendlich wurde festgestellt, dass sämtliche Einträge für das Scheduling der Jobs verloren gegangen waren. Die Ladeprozesse wurden deshalb nie ausgeführt. Noch in derselben Nacht liefen die Jobs erstmalig und fehlerfrei durch. Ein Tag vor Releasefreigabe konnte ich die Testfälle nun mit gutem Gewissen auf ‚passed‘ setzen.

Zusammenfassend bedeutet dies, dass es nicht um ein erfolgreiches Testen ging, sondern nur um die Behauptung, dass getestet wurde. Ob es wirklich Praxis war, die Testfälle einfach auf passed zu setzen, habe ich nie herausgefunden. In diesem Fall hat es sich gelohnt, dem Druck nicht nachzugeben. Dieser Dimensionsladeprozess wäre wahrscheinlich nie korrekt gelaufen.

1.2 Wirtschaftlichkeit des Testens

Testen muss wirtschaftlich sein. Abbildung 1–1 stellt schematisch die Folgekosten von Fehlern in der degressiven Kurve und die Kosten durch das Testen in der progressiven Kurve dar. Dies bedeutet, wenn nicht getestet wird, entstehen hohe Kosten durch Fehler. Einerseits sind dies direkte Kosten, die der Schaden des Fehlers verursacht. Andererseits sind es Kosten, die für die Suche und das Beseitigung des Fehlers notwendig sind. Über ein effektives Testen werden die Fehler und somit die Folgekosten reduziert. Doch auch das Testen verursacht Kosten. Wie die Kurven zeigen, stehen ab einem gewissen Punkt die Kosten des Testens in keinem Verhältnis mehr zum Nutzen.

Effizientes Testen ist somit bis zum Schnittpunkt der beiden Kurven sinnvoll. Das Problem ist, dass nur bekannte Fehler quantifiziert werden können. Es bleibt somit immer ein Restrisiko, dass der eine nicht gefundene Fehler den Millionenschaden verursachen kann.

Abb. 1–1 Wirtschaftlichkeit des Testens

Ariane 5 – ein kleiner Fehler mit einer großen Auswirkung

Ein gutes Beispiel für die Auswirkungen eines einzelnen Fehlers ist die Ariane-5-Rakete, die am 5. Juni 1996 explodierte. Ursache war ein Fehler in einem ADA-Modul, das für die Regulierung der seitlichen Steuerraketen zuständig war. Eine 64-bit-Floatingpoint-Variable wurde dabei mit einer 16-bit-Integer-Variablen verglichen. Dies führte zu einem Overflow-Fehler und die Steuerung der Raketenflugbahn war nicht mehr möglich. Da Ariane 5 die Flugbahn verließ und unkontrolliert abzustürzen drohte, wurde sie automatisch, nach erst 40 Sekunden Flug, über dem Meer gesprengt, inklusive aller Forschungssatelliten. Die Bilder gingen damals um die Welt. Die Herstellungskosten nur für die Rakete und die Satelliten wurden mit 500 Mio. USD beziffert. Die spätere Untersuchung zeigte, dass die Entwicklung dieses ADA-Moduls auf einer fehlerhaften Spezifikation beruhte, die nie verifiziert wurde, und dass das Softwaremodul ungenügend getestet wurde.

1.3 Vollständiges Testen ist nicht möglich

Die Komplexität von heutigen Informatiksystemen lässt kein vollständiges Testen zu. Jede einzelne Funktion bietet mehrere Möglichkeiten. Werden Kombinationsmöglichkeiten aller Funktionen berechnet, indem alle Varianten der einzelnen Funktionen miteinander multipliziert werden, entsteht eine unwahrscheinlich hohe Zahl. Jede dieser Kombinationen zu testen, würde Jahre dauern.

Bereits der zweite der sieben Grundsätze des Testens beschreibt diese Situation.1

Bei der Testplanung ist eine Risikoabwägung notwendig zwischen dem Testaufwand auf der einen Seite und der Wahrscheinlichkeit und Auswirkung von unentdeckten Fehlern auf der anderen Seite.

1.4 Gegenüberstellung von BI- mit klassischen Projekten

Bill Inmon, einer der Urväter des Data Warehouse, prägte vor Jahren folgenden Satz [Inmon 2005]:

»Traditional projects start with requirements and end with data. Data Warehousing projects start with data and end with requirements.«

Damit wollte er sagen, dass in klassischen Projekten transaktionsbasierte Systeme entstehen, mit denen Informationen erfasst und in Datenbanken gespeichert werden. Ein typisches Beispiel ist ein System zur Pflege von Kundenstammdaten.

Business-Intelligence-Projekte verwenden die existierenden Datenbanken, um Analysen in den verschiedensten Formen zu erstellen, sei es als Listen in Papierform, elektronisch als Führungscockpits, Risikoanalysen mittels Data Mining oder in weiteren Varianten.

Wenn sich die Projekte schon stark unterscheiden, muss dies auch einen Einfluss auf das Testvorgehen haben. In Tabelle 1–1 haben wir die Projekte einander gegenübergestellt und Unterschiede herausgearbeitet. Business-Intelligence-Projekte haben wir noch folgendermaßen unterteilt:

ETL (Extract, Transform and Load)

Dies sind alle Prozeduren, die Daten aus den Quellsystemen lesen und in ein Data Warehouse oder eine andere Form von analytischem Datenspeicher schreiben. ETL-Prozesse sind auch für alle Transformationen und Übertragungen von Daten innerhalb des Data Warehouse zuständig, beispielsweise von der Staging Area ins definitive Modell.

Speicherung

Dies können ein Core Data Warehouse, mehrere separate multidimensionale Datenbanken oder eine sonstige proprietäre Datenspeicherformen sein. Diese multidimensionale Datenbanken sind die Quelle für das Frontend oder die Ausgangslage für die Power User, die selbst Ad-hoc-Abfragen erstellen.

Frontend

Darunter verstehen wir alle Komponenten, die für die Visualisierung der Informationen zuständig sind. Das können Listen, Cockpits etc. sein.

In der Gegenüberstellung haben wir rein technische Projekte nicht berücksichtigt, beispielsweise für den Aufbau der Infrastruktur, die die Installation und Konfiguration eines BI-Servers und das Einrichten des Berechtigungssystems beinhaltet. In der Darstellung haben wir uns nur auf Projekte mit fachlichen Inhalten entlang des Datenflusses orientiert, von der Beschaffung bis zur Präsentation. Die Gliederung ist stark vereinfacht und viele Projekte beinhalten mehrere oder sogar alle Ausprägungen dieser Projekttypen. Unser Weglassen der technischen Infrastrukturprojekte bedeutet nicht, dass diese Projekte von untergeordneter Bedeutung sind.

Klassische IT- Projekte

Business-Intelligence-Projekte

ETL

Speicherung

Frontend

Projektmethodik

Mehrheitlich traditionelle Modelle (Wasserfall, V-Modell, …)

Agile Methoden gewinnen zunehmend an Bedeutung

Mehrheitlich iterativ, Prototyping oder agil, beispielsweise Scrum

Anforderungen

Klar definiert

Unscharf definiert

Code

Statisches SQL in Code

Ausprogrammierte Funktionen

Dynamisches SQL oder MDX

Interaktive Codegenerierung

Dynamisches SQL oder MDX

Datenmodelle

Konsistent mit referenzieller Integrität, relational, 3NF

Heterogene Quellen

Multidimensional, temporär inkonsistent

Datenzugriff

Update einzelner Datensätze

Zeilenweise lesend (alle Attribute einer einzelnen Zeile)

Massen-updates (Bulkload)

Spaltenweise lesend (einzelne Attribute aus allen Zeilen einer Tabelle)

Daten und Testdaten

Nicht vorhanden, diese entstehen durch Erfassung im Testsystem

In den operativen Quellsystemen vorhanden. Wie können diese genutzt werden? (Sicherheit muss geregelt werden.)

Testschwerpunkte

Anwendungsfallgetrieben

Funktionsbasiert

Datengetrieben

Datenqualität

Funktionale Tests

Integrations- und Regressionstests bei Beschaffung oder Releasewechsel

Performance

Datenqualität

Performance

Integrations- und Regressionstests bei Beschaffung oder Releasewechsel

Performance

Tab. 1–1 Gegenüberstellung klassischer IT-Projekte mit Business-Intelligence-Projekten

In den klassischen IT-Projekten wird häufig noch mit Phasenmodellen gearbeitet. Am Anfang werden klar verbindliche Spezifikationen geschrieben, ausgehend von den formulierten Anforderungen (engl. Requirements). Anschließend folgen die Realisierung, die Tests und die Einführung.

In Business-Intelligence-Projekten ist das Definieren von klaren Anforderungen meistens sehr schwierig. Nicht unüblich sind Sätze wie: »Wir möchten ein Set von Auswertungen über unsere Kundendaten haben, um den Verkaufsprozess besser steuern zu können« oder: »Wir vermuten, dass wir unser Potenzial nicht ausnutzen, weil uns die Informationen fehlen«. Daher wurde in Business-Intelligence-Projekten schon früh mit nicht linearen Projektvorgehensmodellen begonnen, wie Prototyping oder iterativen Modellen. Speziell das Rapid Prototyping eignet sich besonders, um schnell ein erstes Set von Ergebnissen zu liefern, um daran die Anforderungen diskutieren und präzisieren zu können.

In beiden Projektwelten hat sich in den letzten Jahren die Methode Scrum durchgesetzt. Dabei wird manchmal vergessen, dass es noch weitere agile Methoden gibt, wie beispielsweise Extreme Programming, die bezüglich Agilität teilweise noch weiter gehen.

Auch bezüglich des Codes gibt es Unterschiede. Klassische Projekte verwenden statisches SQL zum Lesen und Schreiben von Daten. Diese SQL-Anweisungen sind eingebettet im Programmcode, beispielsweise in C++, Visual Basic oder Java. Dieser Code ist kompiliert und ebenso statisch. In BI-Werkzeugen, speziell in den Abfragewerkzeugen im Frontend-Bereich, wird die Abfrage dynamisch generiert. Nur ganz selten schreibt ein Entwickler SQL- oder MDX-Code.

In Business-Intelligence-Systemen sind die Datenspeicher temporär inkonsistent, und zwar aus mehreren Gründen:

Lose Kopplung bei ROLAP-Speicherung. Das heißt, es existiert keine referenzielle Integrität innerhalb eines sternförmigen Modells.

Unterschiedliche Ladezeitpunkte aus den verschiedenen Quellsystemen, was eine Synchronisation erst zu einem späteren Zeitpunkt möglich macht.

Da bereits Quelldaten vorhanden sind, werden diese gerne für Tests genommen. Das bedeutet, dass Tests mit produktiven Daten in Business-Intelligence-Projekten nicht unüblich sind. Wichtig ist hier das Beachten der Sicherheitsanforderungen. Meistens geht es um die Frage der Anonymisierung und um das Verändern von Summen. Trotz des Anonymisierens und Veränderns von Werten bleibt das Testen mit produktiven Daten ein Problem. Wahrscheinlich wird keine Bank einem externen Berater die Kundendaten für Tests zur Verfügung stellen.

Anwendungsfälle (engl. Use Cases) bilden häufig die Grundlage zur Definition von funktionalen Tests. In analytischen Systemen gibt es nur wenige oder nur bedeutungslose Anwendungsfälle. Viel wichtiger sind datengetriebene Testfälle, die noch ausführlich in Abschnitt 5.1 behandelt werden.

1.5 Einfluss von Daten aufs Testen

Wie schon erwähnt, sind bei den meisten analytischen Systemen die Daten aus den Quellsystemen bereits vorhanden und werden daher gerne fürs Testen verwendet. Dagegen ist nichts einzuwenden, solange die Daten, soweit notwendig, entsprechend geschützt werden. Dies geschieht mit Zugriffsbeschränkungen und durch das Anonymisieren der Daten.

Die Datenqualitätsprobleme der Quellsysteme werden dabei gleich mit importiert. Verschiedene Fehlerlogs aus mehreren Projekten wurden ausgewertet, um die Bedeutung der Daten und deren Qualität zu analysieren. Die Auswertung in Abbildung 1–2 ist nicht absolut zu verstehen, da es sich um keine empirisch relevante Menge von ausgewerteten Projekten handelt.

Die Auswertung zeigt, dass zu Beginn der Testphase noch Implementierungsfehler die größte Gruppe von Fehlern sind. Implementierungsfehler sind falsch gesetzte Filter, unvollständige Umsetzung der Spezifikation oder ungenau umgesetzte Designvorgaben, um einige Beispiele zu nennen. Viele dieser funktionalen Fehler werden mit den ersten Tests erkannt und können schnell behoben werden. Gegen Ende der Testphase spielen diese funktionalen Fehler nur noch eine untergeordnete Rolle. Meistens haben die dann noch existierenden Fehler nur noch geringe Auswirkungen und sind daher von untergeordneter Bedeutung.

Abb. 1–2 Prozentualer Anteil von Fehlern nach Kategorien im Verlauf über die Testphase

Eine größere Gruppe von festgestellten Fehlern hat nicht direkt mit dem neuen oder zu ändernden analytischen System zu tun. Sie werden verursacht durch Qualitätsprobleme in den Quelldaten. Bei analytischen Systemen werden besondere Anforderungen an die Robustheit von Importschnittstellen gestellt. Durch das Testen mit echten Daten werden echte Fehler sofort erkannt und das System kann bereits darauf ausgerichtet werden2.

Eine weitere Gruppe von datenbezogenen Fehlern hat die Ursache im Datenverständnis. Diese Gruppe war die Überraschung bei den Auswertungen, da die Existenz dieser Fehler zu Beginn nicht einmal vermutet wurde. Da die ersten Testfälle noch sehr einfache funktionale Überprüfungen sind, treten datenbezogene Fehler erst mit der Zeit auf. Mit dem Fortschritt des Testens werden immer komplexere Testfälle durchgeführt. Dabei kommt es zu Interpretationsfehlern. Beispielsweise ist eine Kennzahl für den Tester missverständlich und er interpretiert das Ergebnis als fehlerhaft. Funktionale Anpassungen am System sind nicht notwendig, sondern es braucht nur eine Erklärung. Es wäre jetzt einfach, die Fehlermeldung zu schließen mit der Begründung, dass es kein Fehler ist und der Tester ungenügende Kenntnisse hatte. Genau diese Fehlergruppe weist auf Mängel in der Benutzbarkeit (engl. Usability) hin3. Eine Verbesserung ist hier nicht einfach. Möglich wird sie durch den Einsatz einer guten und umfangreichen Benutzeranleitung, eines ausführlichen Hilfesystems oder eines Data Dictionary. Idealerweise werden gleich mehrere dieser Instrumente eingesetzt.

Über die ganze Testphase hinweg machen datenbezogene Fehler die größte Gruppe von Fehlern aus. Die beiden Gruppen Datenqualität und Datenverständnis werden später in diesem Buch noch ausführlich behandelt.

1.6 Die 7 Prinzipien des Testens

Seit vielen Jahren haben sich sieben Grundsätze des Testens etabliert. Die genaue Herkunft und wann diese Prinzipien aufgestellt wurden, lässt sich nicht genau ermitteln. Im Internet existieren dazu verschiedene Versionen. Diese Prinzipien sind in die Lehrpläne zum Certified Tester nach ISTQB4-Standard [URL: ISTQB] eingeflossen.

Die sieben Prinzipien sind die Essenz des Testens. Oder, mit anderen Worten, es sind die sieben Grundwahrheiten des Testens, die nachfolgend beschrieben sind.

1. Prinzip: Testen zeigt die Anwesenheit von Fehlern

Mit Testen wird das Vorhandensein von Fehlern nachgewiesen. Nicht zulässig ist die Schlussfolgerung, dass eine Softwarelösung keine Fehler mehr enthält, nur weil keine Fehler mehr gefunden werden. Fehlerfreiheit lässt sich nie beweisen. Testen reduziert einzig die Wahrscheinlichkeit von unentdeckten gravierenden Fehlern.

2. Prinzip: Vollständiges Testen ist nicht möglich

Die Komplexität von Softwarelösungen ergibt unzählige Testmöglichkeiten. Durch die Vielzahl von Kombinationsmöglichkeiten der unterschiedlichen Funktionen und Eingabewerten, ist es unmöglich, sämtliche Varianten zu testen. Tests sind daher immer nur Stichproben. Der Umfang der Tests wird geprägt von Risiko- und Wirtschaftlichkeitsüberlegungen. Ein Restrisiko bleibt.

3. Prinzip: Mit dem Testen sollte so früh wie möglich begonnen werden

Je später Fehler erkannt werden, desto teurer ist deren Korrektur. Daher sollte mit der Testplanung gleich am Anfang des Projekts und mit dem Testen bereits zu Beginn der Entwicklung begonnen werden. Reviews der Konzepte und Spezifikationen können schon vor dem Schreiben der ersten Codezeile durchgeführt werden.

4. Prinzip: Beachten von Fehlerhäufung

Fehler sind nie gleichmäßig verteilt. Einzelne Testobjekte werden immer eine größere Fehlerdichte aufweisen. Dies hat verschiedene mögliche Ursachen. Die Komplexität der Lösung ist höher als in anderen Modulen. Oder der Entwickler hatte ungenügend Erfahrung.

Fehlerhäufungen (engl. Defect Cluster) sind ein Hinweis, dass es an dieser Stelle noch weitere unentdeckte Fehler gibt. Es sollten unbedingt weitere Tests durchgeführt werden. Wer sich nur auf die ursprünglich vordefinierten Testfälle verlässt und sich mit der Behebung der gefundenen Fehler zufriedengibt, zeigt einen eher fatalistischen Umgang mit dem Testen.

5. Prinzip: Varianz bei den Testfällen

Das Anwenden der immer gleichen Testfälle führt dazu, dass die Software bereits auf diese Tests vorbereitet ist. Das heißt, es werden zwar immer weniger Fehler gefunden. Es wird aber nicht der Nachweis erbracht, dass auch weniger Fehler existieren.

Die vorhandenen Testfälle müssen daher regelmäßig überarbeitet und durch neue Testfälle und andere Methoden ergänzt werden. Ansonsten sinkt die Effektivität des Testens.

Für dieses Verhalten von Software wird der Begriff des »Pesticide paradox« verwendet. Ähnlich wie Schädlinge mit der Zeit eine gewisse Resistenz gegen Gifte entwickeln können, kann auch die Software eine Testresistenz entwickeln.

6. Prinzip: Testen ist abhängig von verschiedenen Einflussfaktoren

Es gibt nicht das universelle Set von Testfällen und -methoden. Tests sind immer abhängig von verschiedenen externen und internen Einflussfaktoren. Interne Faktoren sind die Kritikalität und Komplexität des Systems. Externe Faktoren sind die Projektmethode, die zur Verfügung stehende Zeit und die vorhandenen Testressourcen, wie Software, Personen etc.

7. Prinzip: Keine Fehler bedeutet ein brauchbares System, ist eine falsche Schlussfolgerung

Ein fehlerfreies System bedeutet noch lange nicht, dass das System auch von den Benutzern akzeptiert wird. Das frühzeitige Einbeziehen der Benutzer und Rapid Prototyping im Entwicklungsprozess sind vorbeugende Maßnahmen gegen unzufriedene Kunden.

1.7 Validieren und Verifizieren

Die Begriffe Validieren und Verifizieren umschreiben unterschiedliche Arten von Prüfungen. Grundlage ist eine andere Sichtweise des Systems. Die Unterschiede von Validierung und Verifikation sind in Tabelle 1–2 dargestellt.

Tab. 1–2 Gegenüberstellung Validierung und Verifikation

Validierung

Verifikation

Ziel: Bestätigen der Praxistauglichkeit des Systems in Bezug auf Robustheit der Module

Ziel: Bestätigen der Praxistauglichkeit des Systems in Bezug auf Erfüllung des Einsatzzwecks

Überprüft, ob ein Modul oder System die spezifizierten Anforderungen erfüllen kann.

Überprüft die Korrektheit, Vollständigkeit und formale Richtigkeit eines Systems oder Phasenergebnisses.

Tut das System die richtigen Dinge?

Ist es das richtige System?

Vollständigkeit

Korrektheit

Externe Sicht auf einzelne Funktionen oder Module

Interne und externe Sicht auf die Systemanforderungen

Erfüllung von funktionalen und nicht funktionalen Anforderungen

Erfüllung von technischen Anforderungen, Codierungsstandards, rechtlichen und regulatorischen Vorgaben

1.8 Was Testen nicht kann

Testen dient ausschließlich der qualitativen Überprüfung eines Systems und dem Aufzeigen von Fehlern. Wunder sind nicht zu erwarten.

Edsger Wybe Dijkstra (1930-2002) formulierte die Grenzen des Testens in einem Satz: »Testing can only show the presence of bugs, but not their absence.« Auf Deutsch übersetzt bedeutet der Satz, dass Testen nur die Anwesenheit von Fehlern, jedoch nie die Abwesenheit von Fehlern zeigen kann. Edsger Dijkstra hatte Mathematik studiert und sich schon früh für den Weg zum Informatiker entschieden. Er entwickelte verschiedene Algorithmen und war an der Entwicklung eines der ersten multitaskingfähigen Betriebssysteme beteiligt. Später war er Professor für Mathematik. Des Weiteren wurde er bekannt durch seine prägnanten Formulierungen, die gerne zitiert werden.

Sein Satz zum Testen beschreibt in wenigen Worten genau den Inhalt des ersten der sieben Grundprinzipien5. Egal wie aufwendig und intensiv getestet wird, es können nur Fehler entdeckt werden. Es bleibt weiterhin die Vermutung, dass die gefundenen Fehler nur eine Teilmenge aller Fehler sind. Wie groß die Menge der unentdeckten Fehler ist und wie groß die Auswirkungen der unentdeckten Fehler sind, kann nicht beantwortet werden. Das bedeutet, dass das Risiko von unentdeckten Fehlern nicht berechnet werden kann. Es bleibt im Bereich von Vermutungen und Spekulationen.

Ein anderes Zitat, das die Grenzen des Testens aufzeigt, stammt von Dr. Boris Beizer: »Good testing works best on good code and good design. And no testing technique can ever change garbage into gold.« Sinngemäß übersetzt bedeutet dies, dass gute Tests erfolgversprechender für ein System mit einem ausgereiftem Design und einer guten Implementierung (sprich Programmierung) angewandt werden können. Es ist nicht möglich, mit irgendwelchen Tests aus Müll eine perfekte Lösung zu erreichen.

Boris Beizer ist amerikanischer Informatiker und Autor. Seine Publikationen drehen sich alle um das Thema Qualität von Informatiksystemen und speziell um das Testen. Tests können auch konzeptionelle Fehler oder eine qualitativ schlechte Umsetzung aufzeigen. Insbesondere dann, wenn nicht nur funktionale Prüfungen geplant sind, sondern die Qualitätsmerkmale nach ISO 9126 für Testfälle angewandt werden. Es ist üblicherweise nicht mehr möglich, aus einem völlig verkorksten System durch das Korrigieren von Fehlern eine Lösung mit genügender Qualität zu erreichen. Manchmal bleibt nichts anderes übrig, als das System in ungenügender Qualität einzuführen und in einem Folgeprojekt mit Release 2.0 die konzeptionellen Fehler zu korrigieren. Dieses neue System muss als zusätzliche Anforderung noch die Migration des alten Systems erfüllen können. Dies ist nicht selten eines der größten Risiken des Nachfolgerelease. Die logische Schlussfolgerung ist, dass bereits zu Beginn eines Projekts entsprechende qualitative Prüfungen einzubauen sind, um konzeptionelle und Systemdesignfehler zu vermeiden.

In den meisten Business-Intelligence-Projekten wird nicht programmiert. ETL-Prozeduren, Abfragen und Auswertungen werden über grafische Oberflächen parametrisiert. Übertragen auf Business-Intelligence-Systeme bedeutet dies nicht, dass Testen eine untergeordnete Bedeutung hat, weil kein Code geschrieben wird. Genauso sind qualitative Prüfungen von Anfang an in ein Projekt einzubauen. Dabei haben die Datenflüsse und die zu erwartende Datenqualität eine wichtige Bedeutung. Gerade die Datenqualität der Quellsysteme bedeutet häufig eine Limitierung in Business-Intelligence-Projekten. Da die Datenqualität nicht direkt verbessert werden kann, muss zuerst das Bewusstsein dafür geschaffen werden. In den Auswertungen bleibt immer eine gewisse Unschärfe. Einzelne Analysen werden sogar unmöglich sein. Fehler aufgrund der ungenügenden Datenqualität werden jedoch gerne dem Analysewerkzeug zugeordnet. Der Übermittler der schlechten Nachricht wird somit auch hier zum Schuldigen gemacht. Vereinzelt ist es schon vorgekommen, dass Business-Intelligence-Systeme nicht verwendet und später abgestellt wurden, weil man den generierten Informationen nicht traute. Es ist immer wieder interessant zu beobachten, wie eine neue Initiative mit einem anderen Auswertungswerkzeug gestartet wird und wie groß das Erstaunen ist, dass die Datenqualität immer noch nicht besser ist und die Aussagekraft von Auswertungen und Analysen ungenügend bleibt.

Alle sieben Prinzipien des Testens sind in Abschnitt 1.6 beschrieben.

Weitere Hinweise zum Qualitätsmerkmal »Fehlertoleranz« und »Reife« enthält Abschnitt 4.2.3. Informationen zum Testen mit produktiven Daten sind in Abschnitt 6.2 beschrieben.

Verschiedene Aspekte zum Qualitätsmerkmal »Bedienbarkeit« und »Datenverständnis« sind in Abschnitt 4.2.2 beschrieben.

International Software Testing Qualifications Board

Die sieben Grundprinzipien sind im vorherigen Abschnitt 1.6 beschrieben.

2 Referenzmodell für das Testen

Der Einfachheit halber haben wir uns entschlossen, ein eigenes Referenzmodell zu verwenden, das wir entwickelt haben und in der Praxis anwenden, um möglichst unabhängig von den verschiedenen existierenden und manchmal hochkomplexen Modellen zu sein.

Dieses Modell verwenden wir innerhalb dieses Buches immer wieder, um vorhandene Methoden oder Standards zu vergleichen. Dabei zeigen wir Parallelen und Eigenheiten dieser Standards im Vergleich zu diesem Referenzmodell auf. Im Vergleich haben wir festgestellt, dass viele dieser Standards zwar einzelne Aspekte des Testens sehr ausführlich behandeln, jedoch andere Aspekte vollständig weglassen.