Testen von Data-Warehouse- und Business-Intelligence-Systemen
eBook - ePub

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

Vorgehen, Methoden und Konzepte

Herbert Stauffer, Beat Honegger, Hanspeter Gisin

Share book
  1. 268 pages
  2. German
  3. ePUB (mobile friendly)
  4. Available on iOS & Android
eBook - ePub

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

Vorgehen, Methoden und Konzepte

Herbert Stauffer, Beat Honegger, Hanspeter Gisin

Book details
Book preview
Table of contents
Citations

About This Book

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.

Frequently asked questions

How do I cancel my subscription?
Simply head over to the account section in settings and click on “Cancel Subscription” - it’s as simple as that. After you cancel, your membership will stay active for the remainder of the time you’ve paid for. Learn more here.
Can/how do I download books?
At the moment all of our mobile-responsive ePub books are available to download via the app. Most of our PDFs are also available to download and we're working on making the final remaining ones downloadable now. Learn more here.
What is the difference between the pricing plans?
Both plans give you full access to the library and all of Perlego’s features. The only differences are the price and subscription period: With the annual plan you’ll save around 30% compared to 12 months on the monthly plan.
What is Perlego?
We are an online textbook subscription service, where you can get access to an entire online library for less than the price of a single book per month. With over 1 million books across 1000+ topics, we’ve got you covered! Learn more here.
Do you support text-to-speech?
Look out for the read-aloud symbol on your next book to see if you can listen to it. The read-aloud tool reads text aloud for you, highlighting the text as it is being read. You can pause it, speed it up and slow it down. Learn more here.
Is Testen von Data-Warehouse- und Business-Intelligence-Systemen an online PDF/ePUB?
Yes, you can access Testen von Data-Warehouse- und Business-Intelligence-Systemen by Herbert Stauffer, Beat Honegger, Hanspeter Gisin in PDF and/or ePUB format, as well as other popular books in Ciencia de la computaciĂłn & Almacenamiento de datos. We have over one million books available in our catalogue for you to explore.

Information

Publisher
dpunkt
Year
2013
ISBN
9783864914089

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.

Table of contents