Herbert Stauffer Beat Honegger Hanspeter Gisin

Transkript

1

2 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.

3 Herbert Stauffer Beat Honegger Hanspeter Gisin Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte Edition TDWI

4 Herbert Stauffer Beat Honegger Hanspeter Gisin Fachlektorat: Marcus Pilz, pilmar.com Lektorat: Christa Preisendanz Copy Editing: Ulla Zimpfer, Herrenberg Herstellung: Frank Heidt Satz: Reemers Publishing Services, Krefeld Umschlaggestaltung: Anna Diechtierow, Heidelberg Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition TDWI: Marcus Pilz Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN: Buch PDF epub Auflage 2013 Copyright 2013 dpunkt.verlag GmbH Wieblinger Weg 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 v 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 gelesen 1. 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. 1. 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.

6 vi Vorwort 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

7 Vorwort vii 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.

8 viii Vorwort 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. 2 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. 2. 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.

9 ix Inhaltsverzeichnis 1 Einführung Ungenügendes Testen ist leider Praxis Wirtschaftlichkeit des Testens Vollständiges Testen ist nicht möglich Gegenüberstellung von BI- mit klassischen Projekten Einfluss von Daten aufs Testen Die 7 Prinzipien des Testens Validieren und Verifizieren Was Testen nicht kann Referenzmodell für das Testen Drei Phasen des Testprozesses Organisation Ebene Testmanagement Ebene Testoperation Elemente Aktivitäten Menschen und Rollen Werkzeuge (Tools und Daten) und Hilfsmittel Im Dreiklang: Organisation, Elemente und Phasen »Würfel«in der Phase Planung »Würfel«in der Phase Durchführung »Würfel«in der Phase Abschluss

10 x Inhaltsverzeichnis 3 Methoden und Standards V-Modell IEEE IEEE 829 Software Test Documentation IEEE 1008 Unit Testing IEEE 1012 Software Verification and Validation Rational Unified Process (RUP) ISO ISO/IEC 9126 Qualitätsmerkmale ISO/IEC Cabinet Office ITIL 2011 Validation and Testing PRINCE ISACA COBIT CONCT Definition von geeigneten Testfällen und Fehlerkategorien Bestimmung von zu testenden Komponenten Schritt 1: Aufzeichnen des gesamten Systems Schritt 2: Kennzeichnen der Komponenten Schritt 3: Ableiten der Testfälle Zu prüfende Qualitätsmerkmale (nach ISO 9126) Funktionalität (engl. Functionality) Benutzbarkeit (engl. Usability) Zuverlässigkeit (engl. Reliability) Effizienz (engl. Efficiency) Wartbarkeit (engl. Maintainability) Übertragbarkeit (engl. Portability) Testmethoden und Testarten Statische Testverfahren Dynamische Testverfahren Gliederung der Testverfahren nach verschiedenen Kriterien Teststufen Definition und Beschreibung von Testfällen Vereinfachte Testfälle mithilfe von Checklisten Fehlerkategorien

11 Inhaltsverzeichnis xi 5 Einfluss der Daten aufs Testen Datengetriebene Testfälle als Schwerpunkt in Business Intelligence Datenqualität Validieren Datenqualität Verifizieren Funktionale Softwarequalität in Bezug zu den Daten Nicht funktionale Softwarequalität in Bezug zu den Daten Bedeutung von datengetriebenen Testfällen Datenqualität und Testen ein fließender Übergang Berücksichtigung der Data Governance Daten als Werte Daten als Eigentum (organisatorische Rollen) Hilfsmittel (Einsatz von Tools) Testorganisation, -infrastruktur und -betrieb Berücksichtigen der verschiedenen Systemumgebungen System-Landschaft Systeme-Landschaft Systeme-Landschaft Systeme-Landschaft Systeme-Landschaft Testdatenmanagement Definition von geeigneten Sets Anonymisieren und Verändern Berechtigungen Generieren von Testdaten Testen in Szenarios Vorbereiten des Testbetriebs Systeme bereitstellen Schulung der Tester (Test der Schulung) Minimales Kommunikationskonzept Testbetrieb Aufgaben des Testmanagements Iterativer Prozess auf der Ebene Testoperation Rolle des Dispatchers Auswirkung von neuen Versionen auf Testfälle

12 xii Inhaltsverzeichnis 6.6 Logs Testlog Fehlerlog Auswertungen und Reports Abschluss Schlussbericht Systeme bereinigen Lessons Learned Transfer Die menschliche Seite beim Testen Rollen im Testprozess Rollenkonflikt zwischen Softwareentwickler und Tester Rollenkonflikt zwischen Projektleiter und Testmanager Zwei Risikotypen des Auftraggebers in der Testphase Nachlassende Aufmerksamkeit bei Testern Wirtschaftlichkeit versus Ethik und Moral Testen nach Projektmodellen Phasenmodelle Iteratives Projektvorgehen Prototyping Agile Projektmethoden Sonderthemen Bewertung der verschiedenen Methoden und Standards Checkliste von vermeidbaren Fehlern im Testmanagement Einsatz von Softwaretools Kategorien Testautomatisierung Debugger Fehlernachverfolgung RACI-Matrix im Testprozess Session Based Testing Testen im Umfeld neuer Technologietrends Einsatz von spezialisierten Testteams

13 Inhaltsverzeichnis xiii 9.8 Zwei besonders zu beachtende Situationen Situation 1: Wenn das Testsystem zur Produktion light mutiert Situation 2: Korrekte Aufwandschätzung bei 1:1-Ablösung Die Aus- und Weiterbildung zum Certified Tester Bibliothek von Standardtestfällen Architekturmodell und Komponenten Standardtestfälle Generelle Testfälle Datenintegration und Schnittstellen zu den Datenquellen Datenspeicherung Informationsbereitstellung Plattform und Infrastruktur Externe Systeme und Prozesse Datengetriebene Testfälle Spezielle Projektsituationen Kontrollpunkte im Auditprozess Datenquellen und Schnittstellen Datenintegration Persistente Datenhaltung Informationsbereitstellung und Informationsempfänger Plattform Dokumentenvorlagen Testkonzept Testkonzept (Master Plan) Inhalt Einleitung Werkzeuge, Techniken, Methoden und Metriken Detailtestplanung Logs und Dokumente Testdurchführung Abschluss Anhang

14 xiv Inhaltsverzeichnis 11.2 Testfallspezifikation Testlog Fehlerlog Anhang Literaturliste Weblinks Begriffsübersetzung Englisch-Deutsch Glossar Nachweis der verwendeten Grafiken Index 251

15 1 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 und Koautor 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.

16 2 1 Einführung 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.

17 1.1 Ungenügendes Testen ist leider Praxis 3 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.

18 4 1 Einführung 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.

19 1.2 Wirtschaftlichkeit des Testens 5 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. Kosten Testkosten Fehlerkosten Gesamtkosten Zeit Gesamtkosten = Testkosten + Fehlerkosten 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.

20 6 1 Einführung 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. 1. Alle sieben Prinzipien des Testens sind in Abschnitt 1.6 beschrieben.