Testen

In diesem Artikel erläutere ich das V-Modell, welches ich für die Gestaltung der Tests empfehle, gebe allgemeine Tipps und gehe kurz auf das Transportwesen in SAP ein.

V-Modell

Das V-Modell ist ein Vorgehensmodell der Softwareentwicklung welches neben den Entwicklungsphasen auch das Vorgehen zur Qualitätssicherung (Testen) definiert. Das V-Modell basiert auf dem Wasserfallmodell und ergänzt dieses durch Testphasen. Dabei stehen den Phasen, welche die Anforderungen immer detaillierter spezifizieren, jeweils testende Phasen gegenüber. Dabei dient die Spezifikation der jeweiligen Entwicklungsstufen (und nicht die Wunschvorstellungen!) als Grundlage für die Tests. Ich hoffe, dass spätestens jetzt klar wird, wie wichtig eine ordentliche Dokumentation der Anforderungen ist.
Dabei bestimmen die Anforderungen der Benutzer, welche im Lastenheft festgehalten sind, die System-Architektur (in der Regel SAP Netweaver Plattform). Auf Basis der System-Architektur erfolgt der Entwurf des Systems. Das System besteht in der Regel aus mehreren Modulen bzw. Komponenten. Alles zusammen resultiert in dem Entwurf der Software, welches im Fachkonzept festgehalten wird. Nach der tatsächlichen Realisierung in der Implementierungsphase werden zunächst die einzelnen Module in Unit-Tests getestet. Im Integrations-Test wird das Zusammenspiel aller Module und deren Schnittstellen geprüft. Danach wird die Funktionsweise innerhalb des Systems auf die Probe gestellt, z.B. die Hardware, Betrieb. Letztendlich erfolgt die Abnahme und Nutzung durch die Benutzer.

V-Modell, basiert auf dem „V-Modell“ von Michael Pätzold, S. Seyfert

Allgemein

Was wäre, wenn 90% der gestarteten Flugzeuge erfolgreich landen würden. Ist es gut genug? Oder wenn 95% des Essens, das wir konsumieren, sicher wäre? Wenn man in 98% der Fälle, in denen man einen Stecker in die Steckdose steckt, keinen Stromschlag bekommt? Das ist die Realität in der wir uns bewegen.
Um die Qualität in IT Projekten sicherzustellen sind ausführliche Tests das A und O. Testen Sie daher alle Arbeitspakete sehr gründlich. Vor den eigentlichen Tests empfiehlt es sich ein Akzeptanz-Workshop mit den Key-Usern durchzuführen. Dabei soll sichergestellt werden, dass die Anforderungen korrekt umgesetzt wurden. Neue Anforderungen sollen als Change Requests behandelt werden. Kommunizieren Sie dies bereits mit der Einladung zum Workshop.
Achten Sie darauf, dass die Anwender, die an den Tests teilnehmen, vor diesem Einsatz eine ausführliche und zeitlich ausreichend geplante technische Schulung erhalten. Darin erlernen Sie die wichtigen Handgriffe für die Nutzung der Lösung. Damit soll verhindert werden, dass es in den Tests zu fehlerhaften Ergebnissen aufgrund von Bedienungsfehlern kommt und somit zur Demotivation der Mitarbeiter, die die Tests durchführen. Außerdem sollte die Schulung auch einen Überblick über die betriebswirtschaftlichen Inhalte und ihren Aufbau innerhalb der Lösung vermitteln, damit der Anwender sich beim Testen auch mit der Lösung zurechtfindet.
Kommunizieren Sie auch die richtige Erwartungshaltung an den Kunden – Fehler sind in IT Projekten unvermeidbar (Beispiel Microsoft) und die Tests sind dazu da um Fehler zu finden, nicht um zu beweisen, dass es keine Fehler gibt.
Alle Tests müssen dokumentiert werden, ob sie nun erfolgreich waren oder mit einer Fehlermeldung abgeschlossen wurden. Bei erfolgreichen Tests ist dies wichtig, um Fehler, die beim Echtbetrieb auffallen, besser nachvollziehen zu können. Bei negativen Testfällen ist dient die Dokumentation als die Grundlage zur Fehlerbehebung für die Entwickler. Je besser der Fehler dokumentiert ist, umso einfacher und schneller lässt er sich beheben. Halten Sie die Testergebnisse in einem Testprotokoll fest, welches auch von der Seite des Auftraggebers unterzeichnet wird.
Bei Änderungen, die mehrere Module betreffen, empfiehlt es sich einen Regressionstest durchzuführen, um sicherzustellen, dass die Modifikationen keine neuen Fehler („Regressionen“) Versursachen.
Es empfiehlt sich, Praktikanten bzw. Werkstudenten zum Testen zu verdonnern :)

Oft treten beim Testen einfache technische Probleme auf, so hat zum Beispiel ein PC nicht das richtige SAP GUI oder es fehlen Berechtigungen. Diese Fehler führen zu erheblicher Demotivation bei den Anwendern und sind im Vorfeld absolut vermeidbar. Die Teilnehmer sollten also im Vorfeld prüfen, ob die benötigten Voraussetzungen erfüllt sind. Eventuell schicken Sie den Teilnehmern vorab eine E-Mail mit der Beschreibung der erforderlichen Schritte.

Neben diesen Grundlagen ist ein weiterer wesentlicher Punkt der Terminplan. Da es sich beim Testen um einen dynamischen Prozess handelt, ist hier eine entsprechende zeitliche Flexibilität notwendig. Denn es kann immer aufgrund der nicht vorhersehbaren Testergebnisse zu Verschiebungen in der Reihenfolge kommen. Dabei entsteht das Problem, dass diese zeitliche Flexibilität dem Interesse der Fachabteilung entgegenläuft. Denn diese testet zum einen nicht nur das BI-System (sondern oft auch das Quellsystem) und zum anderen kann sie ihr Tagesgeschäft nicht einfach abstellen. Somit kann sie entsprechend wenig Zeit aufbringen. Sie sollten daher versuchen, die zur Verfügung stehenden Fachabteilungsressourcen immer an den gleichen Tagen zum Testen einzuteilen. Wenn Sie zum Beispiel vier Tester haben, dann teilen Sie zwei für Montag und Dienstag ein und zwei für Mittwoch und Donnerstag. In vielen Unternehmen gilt die Regel „Freitag ab eins ist meins“, Testen erfordert aber eine konsequente Durchführung bis zum Ende – lassen Sie diesen Tag daher besser außen vor.
Mit einer solchen Einteilung erreichen Sie, dass die Fachabteilung ihre Ressourcen optimal planen kann und nicht jede Woche neu erfährt, wann sie einen Testtag hat. Sie haben somit an vier Tagen in der Woche ein Testteam zur Verfügung und können den Freitag zu Fehlerbehebungen nutzen.

Die Kommunikation spielt für den Erfolg eines Projekts eine erhebliche Rolle. Daher starten Sie die Testphase mit einem Workshop, an dem alle an den Tests beteiligten Personen, also auch die Entwickler teilnehmen. Erläutern Sie dabei die wesentlichen Prämissen wie Erwartungshaltung, Dokumentation, Change Request Management und Terminplan. So erreichen Sie ein gemeinsames Verständnis für die Testphase. Ebenso bietet es sich an, mit den Anwendern zum Testabschluss einen Review-Workshop durchzuführen, um die Meinung der Anwender zum Tool und zu noch nicht behobenen Problemen abzufragen.

Transportwesen

Das Transportwesen gewährleistet, dass nicht an laufenden Produktivsystemen Änderungen vorgenommen werden, ohne sie ausreichend in „Vorsystemen“ getestet zu haben. In der Regel vollzieht sich eine BI-Systemimplementierung in drei Stufen:

1. Für einen ersten BI-Prototypen existiert eine einstufige BI-Systemlandschaft, eine so genannte Sandbox.
2. Daneben existiert ein weiteres BI-System, das Entwicklungssystem. Hier erfolgt die eigentliche Implementierung.
3. Für die Tests der Entwicklungen steht ein Qualitätssicherungssystem zur Verfügung.

Es ist empfehlenswert, die BI-Systemarchitektur parallel zu den ERP-Prozesssystemarchitekturen aufzubauen. Daher besteht die empfohlene Architektur aus einem Entwicklungssystem, Integrations- oder Qualitätssicherungssystem und Produktivsystem.
Dabei sollten Test- und Qualitätssicherungssysteme sowie produktive Systeme grundsätzlich das Kennzeichen „nicht änderbar“ aktiviert haben. Die Systemänderbarkeit ist kritisch für die Qualität des Entwicklungsprozesses in einem BI-System.
BI-Komponenten, die in diesen Systemen im normalen Arbeitsalltag geändert werden müssen können in der Transaktion RSA1 → Transportanschluss → Objektänderbarkeit einzeln freigeschaltet werden. So kann es gelegentlich notwendig sein, ein InfoPackage manuell zu starten.
Generell empfiehlt es sich, die Entwicklungen mit einem Transport von Kopien in das Testsystem zu transportieren. Dabei muss der ursprüngliche Transportauftrag nicht freigegeben werden. Dies hat einen verringerten Administrationsaufwand zur Folge. Außerdem empfiehlt sich eine Automatisierung der Importe in das Testsystem. Alternativ können die Entwickler mit den erforderlichen Berechtigungen ausgestattet werden, sodass sie die Transporte ins Testsystem selbstständig durchführen können.

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.

Jetzt anfordern!

Vorname

E-Mail *

* Pflichtfeld

 

Kein SPAM. Ich hasse Spam genau so wie du.

Falls Ihnen dieser Beitrag weitergeholfen hat, wäre es eine sehr nette Anerkennung meiner Arbeit wenn Sie z.B. Ihre Bücher über Amazon bestellen würden. Wenn Sie ein Produkt kaufen, erhalte ich dafür eine Provision. Für Sie ändert sich am Preis des Produktes gar nichts. Ich möchte mich an dieser Stelle jetzt schon für Ihre Unterstützung bedanken.

Bildquelle:
„V-Modell“ von Michael Pätzold, S. Seyfert. Lizenziert unter Creative Commons Attribution-Share Alike 3.0 über Wikimedia Commons – Die SVG Grafik wurde von mir angepasst.