Testen, aber richtig
Testen ist das A und O jedes Business Intelligence Projektes. Allerdings ist nicht jeder Test gleich. Es kann ein wichtiges Werkzeug sein, um die Qualität zu steigern und das Projekt rechtzeitig beenden zu können. Oder es kann dazu führen, dass der Fortschritt nur auf dem Papier besteht. Und am Ende des Projekts, nach dem User Acceptance Test, das gesamte Produkt überarbeitet werden muss. In diesem Artikel gebe ich Tipps, wie Sie es richtig anstellen. Dabei gehe ich auch auf Planungsprojekte ein, die in der Regel komplexer als reine Reportingprojekte sind.
Alles fängt mit dem allerersten Test, dem Unit Test, an. Hier sollte man schon die meisten Fehler ausmerzen. Beim SIT, dem System Integration Test, konzentriert man sich nur auf das Zusammenspiel der einzelnen Komponenten. Beim UAT (User Acceptance Test) wird dann ein solider Stand der Applikation vorliegen.
Testprotokoll
Was zeichnet nun einen guten Unit Test aus? Zunächst gehört zu jedem Test ein Testprotokoll. Dieser beinhaltet alle ausgeführten Testschritte. Das Testprotokoll sollte folgende Struktur aufweisen:
- Ausgangssituation
- Ausgeführte Aktion
- erwartetes Ergebnis
- tatsächliche Ergebnis
- Stimmt das erwartete Ergebnis mit dem tatsächlichen Ergebnis überein?
Die einzelnen Schritte werden mit Screenshots und Berechnungen dokumentiert. Das Excel-Format eignet sich gut für Vergleichs- und Berechnungstests. Hier macht es sich bezahlt, dass Sie schon bei der Aufnahme der Anforderungen sämtliche Berechnungen in Excel über Formeln abgebildet haben. Nun können Sie einfach die Werte reinkopieren und für Ihre Tests nutzen.
Development Guidelines
Neben den Kundenanforderungen gehören auch die Development Guidelines zum Test. Prüfen Sie, ob die Guidelines eingehalten wurden. Diese bilden einen der Grundpfeiler einer funktionierenden Applikation.
Berechtigungen
Wenn es um Berechtigungen geht, sollten diese mit einem dedizierten Testbenutzer, der nur die notwendigen Rollen hat, getestet werden. So vermeiden Sie falsch positive Ergebnisse aufgrund sich überschneidender Rollen. Betrachten Sie das folgende Beispiel – es gibt zwei Rollen, eine Admin-Rolle und eine Planer-Rolle. Führen Sie die Tests nie mit dem Benutzer durch, dem beide Rollen zugewiesen sind!
Führen Sie als Entwickler die Tests niemals mit Ihrem eigenen Benutzer durch. Testen Sie stattdessen Admin-Aktivitäten mit einem dedizierten Benutzer, dem nur die Admin-Rolle zugewiesen ist. Testen Sie Planungsaufgaben mit einem dedizierten Benutzer, dem nur die Planer-Rolle zugewiesen ist.
Referenzdaten
Referenzdaten müssen anhand der jeweiligen Quelle (z.B. ADSO) getestet werden. Existiert ein Bericht, der bereits verwendet (und UATed) ist, können die Tests auf Basis dieses Berichts durchgeführt. Wenn ein Bericht Referenzdaten enthält, führen Sie bitte einen Quervergleich für die im Planungslayout angezeigten Referenzdaten durch.
Variablen der Planungsfunktionen
Wenn Variablen innerhalb von Planungsfunktionen verwendet werden, gehen Sie bitte wie folgt vor. Führen Sie den Test aus mit:
- einer Auswahl
- Mehrfachselektionen (mindestens zwei)
- keinen Selektionen (falls zutreffend, z. B. bei optionalen Variablen)
Wenn Sie zum Beispiel zwei Kostenstellen CCA und CCB haben: selektieren Sie die Kostenstelle CCA, führen Sie die Planungsfunktion aus und stellen Sie sicher, dass CCB nicht betroffen ist.
Im Backend gespeicherte Daten
Des Weiteren sollten Sie auch alle Eingaben und Planungsfunktionen gegen die Daten im jeweiligen ADSO testen. Prüfen Sie, wie viele und welche Datensätze erzeugt werden. Speichern Sie dazu die Daten und filtern Sie die Listenausgabe des ADSOs auf den jeweiligen Request. Stimmen die Werte im Backend mit den Werten im Frontend überein? Funktionieren die Ableitungen über Merkmalsbeziehungen korrekt?
Anpassung = Test
Schließlich bleibt noch zu erwähnen, dass jede Anpassung einen Test nach sich ziehen sollte. Erstens ist es gar nicht so offensichtlich, dass das Problem behoben wurde. Zweitens stehen die Chancen gut, neue Fehler durch Anpassungen einzubauen.
Peer Review
Die Testprotokolle werden dem Architekten und dem Peer Reviewer vorgelegt. Ich persönlich habe sehr gute Erfahrungen mit dem Peer Review gemacht. Dabei testet ein anderer Entwickler die Arbeit noch einmal nach dem Vier-Augen-Prinzip.
Der erste Entwickler führt den Wissenstransfer (KT) zum jeweiligen Prüfer durch. Der Prüfer testet die Entwicklung gemäß den Akzeptanzkriterien und stellt sein Testprotokoll zur Verfügung. Dabei sollte er versuchen, die Anwendung kaputt zu machen.
Auf den ersten Blick sieht es nach einem zusätzlichen Aufwand auf. Tatsächlich spart ein Peer Review jedoch viel Zeit, denn die Fehler werden sofort entdeckt und behoben. Der Entwickler muss sich nicht später noch einmal in die jeweilige Fragestellung einarbeiten. Darüber hinaus wird so verhindert, dass der Fehler sich in andere Module verbreitet und später an mehreren Orten gepatcht und getestet werden muss.
Die Qualität steigt also ungemein. Gleichzeitig wird auch das Know How im Projekt auf mehrere Entwickler verteilt und hilft, eventuellen Ausfällen und Krankheiten zu trotzen.
Welche Erfahrungen haben Sie mit dem Testen gemacht? Haben Sie noch mehr hilfreiche Tipps? Ich freue mich auf Ihr Kommentar.
Warum scheitern so viele Projekte?
- In meinem Newsletter lernen Sie, wie Sie Projekte erfolgreich abschließen.
- Zahlreiche Checklisten, Tipps und Tricks bringen Ihr Projekt auf Kurs.
- Vorlagen für Business Case, Projektleitdokumentation und Fachkonzept.
- Lernen Sie wie man Projekte richtig plant, durchführt und kontrolliert.
- Bei der Anmeldung zu meinem Newsletter erhalten Sie das Buch „Projektmanagement in a Nutshell“ als Willkommensgeschenk.
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!