Edition TDWI

Vorgehen, Methoden und Konzepte

Herbert Stauffer, Beat Honegger, Hanspeter Gisin

• Verlag: dpunkt
• Jahr: 2013
• ISBN:
  9783864914089
• Auflage: 1
• Thema: Informatik
• Thema: Data-Warehousing

Business-Intelligence- und Data-Warehouse-Projekte sind anders. Entsprechend andersartig sind auch die in diesem Bereich eingesetzten Testverfahrenund -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 Wirtschaftlichkeitsaspekteund 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• DokumentenvorlagenIm 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 Schwerpunktedieser Reihe sind Business Intelligence und Data Warehousing.

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.

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

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Vorwort
• Inhaltsverzeichnis
• 1 Einführung
• 2 Referenzmodell für das Testen
• 3 Methoden und Standards
• 4 Definition von geeigneten Testfällen und Fehlerkategorien
• 5 Einfluss der Daten aufs Testen
• 6 Testorganisation, -infrastruktur und -betrieb
• 7 Die menschliche Seite beim Testen
• 8 Testen nach Projektmodellen
• 9 Sonderthemen
• 10 Bibliothek von Standardtestfällen
• 11 Dokumentenvorlagen
• 12 Anhang
• Index