7 Regeln für erfolgreiches Testmanagement in SAP-Projekten

Dein SAP-Projekt wird nicht an mangelnder Qualität scheitern: So implementierst du erfolgreich ein Testmanagement.

testmanagement-sap

Schwerpunkte setzen!

Betrachte das Testmanagement als kleines Projekt in deinem SAP-Projekt. Auch hier musst du zwischen Zeit, Kosten und Qualität jonglieren. Was ist dir wichtig? Was musst du testen, was ist nice-to-have? Bedenke: vollständiges Testen ist unter normalen Umständen nicht möglich.

  • Systeme
  • Komponenten (Programme / Reports, Migrationsprogramme, …)
  • Prozesse (Kernprozesse, Varianten, Storno, …)
  • Schnittstellen / IDocs (Erstelle dir eine Übersicht der IT-Systemlandschaft)
  • Berechtigungen
  • Benutzerfreundlichkeit
  • Performance
  • Sicherheit

Teststufen & Perspektiven nutzen

Unterschiedliche Menschen können unterschiedliche Perspektiven einnehmen. Nutze diese Vielfalt und lasse von unterschiedlichen Personen (Entwickler, SAP-Berater, Key-User, Endanwender, …) und in mehreren Stufen testen: vom Kleinen zum Großen.

  1. Entwicklertests: Test von einzelnen Programmen oder User Exits.
  2. Funktionstests: Test einzelner Komponenten, bspw. Anlage einer Lieferung.
  3. Szenariotests: Test des Zusammenspiels mehrerer Komponenten, bspw. Anlage einer Lieferung und Buchung des Warenausgangs mit Bezug zu der Lieferung.
  4. Integrationstests: Test von systemübergreifenden Komponenten, bspw. Bestellung über Online-Shop und Auftragsanlage im SAP-System über die entsprechende Schnittstelle.

Neben den funktionalen gibt es eine Reihe an “nicht funktionalen” Tests, die du gezielt durchführen kannst:

  • Performancetests (Last- und Stresstests)
  • Akzeptanztests (bspw. Benutzerfreundlichkeit)
  • Sicherheitstests
  • Regressionstests (Was geht kaputt, wenn ich an einer anderen Stelle etwas verändere?)
  • Negativtests (reagiert das System auf eine Falscheingabe korrekt?)

Und ergänzend natürlich die automatisierten Tests.

Testkatalog erstellen

Hast du ggf. schon eine Testmanagement Software im Einsatz? Wenn nicht: es geht auch mit Microsoft Excel. Du kannst bspw. die folgenden Spalten definieren:

  • ID: Eindeutige Nummer zur Identifikation eines Testfalls.
  • Bezeichnung: Kurze und prägnante Bezeichnung des Testfalls. Definiere Namenskonventionen und beschreibe deine Testfälle bspw. immer nach dem Schema [Objekt] [Tätigkeit]. Beispiele: Auftrag anlegen, Ware kommissionieren, Warenausgang buchen, …
  • SAP-Transaktionscode(s)
  • Status: offen, in Arbeit, erledigt, zurückgestellt, Fehler
  • Durchführung: bspw. dein Key-User Fr. Müller
  • Fehler: Verweis auf Ticket-ID(s) aus deinem Ticketsystem
  • Kommentar

Deine Testfälle beschreibst du zunächst auf hoher Flugebene. Testfallvarianten kannst du mittels der Gruppierungsfunktion zusammenfassen.

Testfälle detailliert beschreiben

Einzelne Testfälle aus dem Testkatalog kannst du detailliert beschreiben. Das ist aber nicht immer erforderlich oder du kannst ggf. auf vorhandene Schulungsunterlagen zurückgreifen. Hier musst du selber die Kosten gegenüber dem Nutzen abwägen. Folgende Informationen sollte dein detaillierter Testfall mindestens enthalten. Testfall Beispiel:

Testfall Auftrag anlegen
Datum:

Name, Vorname:
Abteilung:

03.09.2018

Mayer, Mareike
Vertrieb

Testdaten: Verkaufsorganisation: 1000
Kunde: 52324 (Müller)
Material: 23447294
Anweisungen zur Durchführung: – Transaktion VA01 (Auftrag anlegen) aufrufen
– Vkorg eingeben
– Kunde eingeben
– Material 2 ST
– Auftrag speichern<Screenshot vom Kundenauftrag>
Erwartetes Ergebnis: Auftragsnummer: _ _ _ _ _ _ _ _ _
Abweichung / Fehler: Fehler bitte im Ticketsystem erfassen. Beschreiben Sie die Schritte, die zum Fehler geführt haben, und machen Sie einen Screenshot des Fehlers.

Testplan aufstellen

Deinen Test-Zeitplan stimmst du eng mit deinem Projektplan ab. Für ein agiles SAP-Projekt, in welchem Prototypen im Rahmen von Sprints entwickelt werden, planst du bspw. neben den im Sprint enthaltenen Tests eine extra Testphase ein (Abbildung links, blaue Pfeile). Im Gegensatz dazu hast du bei Projekten, die nach dem Wasserfallmodell abgewickelt werden, eher eine lange Testphase gegen Ende des Projekts.

Unabhängig vom Projektvorgehen unterliegt das Testmanagement aber immer einer gewisser Dynamik: testen, Fehler beheben, erneut testen, Fehler beheben, … plane also mehrere Iterationen ein.

Ressourcen bereitstellen

Wer testet? An die Teststufen angelehnt hast du oftmals einen Mix aus Entwicklern, Beratern, Key-Usern & Endanwendern. Im Rahmen des Projekts ist ggf. eine Stakeholderanalyse durchgeführt worden. Diese solltest du dir ansehen und deinen Personenkreis um relevante Stakeholder erweitern. Kannst du deine Tester für einen gewissen Zeitraum vom Tagesgeschäft freistellen? Sind deine Tester geschult oder sind ggf. noch Schulungsmaßnahmen erforderlich?

Womit wird getestet? Auf dem Testsystem mit den Testdaten, die du bereitstellst. Bereite erforderliche Stamm- und Bewegungsdaten vor. Welche Menge ist erforderlich? Ggf. können einige Testdaten automatisiert erstellt werden?

Wo wird getestet? Im Testraum – wenn du einen bekommst 😉

Ticketsystem nutzen & auswerten

Geht das nicht auch mit Excel? Reicht es nicht aus, die Fehler per E-Mail an den zugehörigen Entwickler zu versenden? … eher nicht, denn die Liste der Nachteile ist meiner Meinung nach viel zu groß. Daher empfehle ich dir die Verwendung eines Ticketsystems. Auf ein paar Punkte musst du aber auch hierbei achten:

  • Du brauchst einen einfachen Kommunikationsweg, also bspw. den Versand einer E-Mail direkt an das Ticketsystem.
  • Stelle Regeln auf: Die Fehler werden verständlich beschrieben. Die Schritte, die zum Fehler geführt haben, werden aufgelistet. Es werden Screenshots hinzugefügt.
  • Jemand unterteilt die Fehler nach Kategorien: must-have oder nice-2-have? Neue Anforderung? Anderes Projekt?
  • Regelmäßig werden Berichte aus dem Ticketsystem erstellt, wie bspw. die gesamte Anzahl an Fehlern nach Status (offen, in Arbeit, erledigt) unterteilt.