Testfalldesign für SAP Applikationen

[Daniel_Enderli]

Einleitung

"Entwickeln ist kreativ und Testen ist destruktiv" - dass dies nicht der Fall sein muss, möchte ich mit diesem Blogbeitrag zum Thema Testfalldesign genauer beleuchten. Gerade das Testfalldesign ist eine überaus kreative Disziplin und gespickt mit etwas Methodik kann das sehr viel Spass machen.

Die Erstellung von Testfällen für Software Entwicklungsprojekte ist eine zentrale Aktivität in Projekten und auch im Betrieb. Insbesondere auch für Standard Software wie SAP Lösungen hilft es die wichtigsten Eckpunkte aus dem Test Management zu kennen.

Bezogen auf das Testfalldesign ergeben sich folgende Fragestellungen:

• Wann sollen die Testfälle erstellt werden?


• Wie können qualitativ gute Testfälle ermittelt werden?


• Welchen Inhalt und Detaillierungsgrad sollen die Testfälle aufweisen?


• Für welche Teststufe macht es Sinn Testfälle zu schreiben oder zu automatisieren?


• Wann werden die Testfälle idealerweise ausgeführt?


• Wie können Testfälle mit Testdaten verknüpft werden?


• Mit welchen Werkzeugen können Testfälle verwaltet und ausgeführt werden?


• Etc.

 

Der fundamentale Testprozess

Beginnen möchte ich mit dem fundamentalen Testprozess nach ISTQB Standard. Der Testprozess definiert alle Phase und Aktivitäten von der Testplanung bis zum Testabschluss und ist die ideale Grundlage, um ein effektives Test Management zu ermöglichen.

In den Phasen "Test Analyse" und "Test Design" wird die Testbasis festgelegt, die Testobjekte identifiziert und die Testfälle entworfen.



Quelle: Eigene Darstellung, in Anlehnung an ISTQB.org

 

Verfahren zur Testfallermittlung

Für die Erstellung von Testfällen existieren verschiedene Verfahren, die herangezogen werden können. Grundsätzlich können die Verfahren in die beiden Kategorien "Blackbox" und "Whitebox" unterteilt werden. Für SAP Lösungen empfehle ich insbesondere die nachfolgenden drei Verfahren:

• Äquivalenzklassenbasierte Verfahren (z.B. Klassen bilden pro Materialart anstatt jedes einzelne Material zu testen).


• Entscheidungstabellenbasierte Verfahren (z.B. anlegen, ändern, löschen von Geschäftspartnern testen).


• Anwendungsfallbasierte Verfahren (abgeleitet aus der Anforderung, aus Prozessdiagrammen oder User Stories Testfälle erstellen).

Quelle: Eigene Darstellung, in Anlehnung an ISTQB.org

 

Teststufen im Wasserfall Vorgehensmodell

Im Wasserfall Vorgehensmodell existiert pro Spezifikationsstufen eine zugehörige Teststufe. Damit wird sichergestellt, dass jede Spezifikationsstufe mit Testfällen abgedeckt ist und überprüft wird. Im Kontext SAP habe ich mir erlaubt das V-Modell als Basis zu nehmen und leicht auf die SAP Welt anzupassen, indem ich den Funktionstests auf Ebene Prozessschritt/Funktion eingefügt habe. Dies ist dann auch die erste, formelle Teststufe nach der Freigabe einer Entwicklung oder eines Customizings.



Quelle: Eigene Darstellung für den Kontext SAP, in Anlehnung an V-Modell 97/V-Modell XT

 

Teststufen im Agilen Vorgehensmodell

Im agilen Vorgehensmodell kommen die Teststufen während jedem Sprint und jedem Release in kürzeren Zyklen als im Wasserfall Vorgehensmodell zur Anwendung. Eine Automatisierung von Testfällen auf Stufe Unittest ist hier unabdingbar um das entwickelte Product Increment bzw. den Build laufen zu testen. Aus eigener Erfahrung macht es Sinn, während einem Sprint den Fokus auf die neu entwickelten Funktionen zu legen. Gegen Ende des Sprints oder direkt nachgelagert sollte der Fokus dann auf Integrationstests und Regressionstests liegen, welche die neu entwickelten Funktionalitäten im Gesamtkontext des Produkts und des Systems überprüfen.

Ein agiles Vorgehensmodell im Kontext SAP setzt hohe Ansprüche an die Product Owner, Architekten, Entwickler und Test Manager, weil die User Stories so feingranular und unabhängig voneinander definiert werden müssen, dass diese in einem Sprint realisiert und getestet werden können. Sprich es ist ein striktes Umdenken notwendig, um nicht von Anfang an den kompletten Business Blueprint in voller Ausprägung zu realisieren, sondern eben iterativ einzelne Bestandteile (Product increments), die in späteren Sprints dann weiter ausgebaut werden.



Quelle: Eigene Darstellung in Anlehnung an Objektspektrum, s-lab und Scrum

 

Die vier Testquadranten für agiles Testen

Auch in einer agilen Vorgehensweise müssen vielfältige Qualitätsmerkmale beurteilt werden. Nachfolgende Illustration zeigt in vier Quadranten auf, welche Tests sich bezogen auf die Dimensionen "Business und Technologie" und "Team und Produkt" eignen. Ebenfalls veranschaulichen die Quadranten, welche Testfälle eher dem Scrum Team dienen und welche Testfälle sich eher auf das Produkt und dessen Umgebung fokussieren.

Als gute Praxis sollten in einem agilen Vorgehensmodell aus jedem Quadranten 1-2 Testverfahren ausgewählt werden. Ich empfehle hier insbesondere:

• Funktionale Tests


• Explorative Tests


• Benutzer Akzeptanz Tests


• Unittests


• Plus je nach Gegebenheiten noch passende nicht funktionale Tests wie z.B. Load & Perfomancetests

Quelle: Testquadranten nach Crispin/Gregory

 

Testobjekte

Die zu überprüfenden Objekte werden als Testobjekte bezeichnet. Diese haben verschiedenen Beziehungen zu anderen Objekten und Elementen im Software Entwicklungsprozess. Nachfolgende Illustration veranschaulicht diese Beziehungen.



Quelle: Eigene Darstellung

 

Testfalldesign

Nun zum eigentlichen Testfalldesign und wie Testfälle beschrieben werden sollten.

• Der Detaillierungsgrad eines Testfalls sollte so gewählt werden, dass eine fachkundige Person aus dem gleichen Team den Testfall ebenfalls durchführen kann.


• Die Anzahl Schritte pro Testfall sollte auf 15-20 Schritte beschränkt sein. Längere Testfälle sind in weitere Testfälle zu unterteilen. Dadurch kann ein Testfall in absehbarer Zeit ausgeführt und vor allem abgeschlossen werden. Ebenfalls ist es damit einfacher Defects eindeutig zu einem Testfall zu verlinken.


• Empfehlenswert ist die Angabe der fachlichen Rolle, welche für den Testfall oder einzelne Testschritte verantwortlich ist.

Die Testfälle sollten mindestens folgende Elemente haben:



Quelle: Eigene Darstellung

 

Ein erstes Beispiel für einen einfach beschriebenen Testfall:



Quelle: Test Steps Designer des SAP Solution Manager 

 

Ein zweites Beispiel für einen detailliert beschriebenen Testfall:



Quelle: Testfall im SAP Solution Manager

 

Konklusion

Egal ob für das Vorhaben ein Wasserfall- oder agiles Vorgehensmodell eingesetzt wird, ist es wichtig mit dem Testprozess frühzeitig zu starten. Schon während der Spezifikationsphase können Testfälle identifiziert werden. Dabei ist es wichtig die richtigen Testverfahren auszuwählen, welche die zu erreichenden Ziele und Ansprüche an die Qualität sicherstellen.

Speziell in einem agilen Vorgehensmodell können Testfälle sehr gut anhand der Akzeptanzkriterien der User Stories abgeleitet werden.

Die Verfahren zur Testfallermittlung können auf verschiedenen Teststufen angewendet werden.

Es lohnt sich die Testfälle einem Review durch eine zweite Person unterziehen zu lassen. Dadurch können die letzten Unklarheiten entdeckt und korrigiert werden.

Die Testfälle sollten wenn immer möglich unabhängig sein von den konkreten Testdaten. Das Ziel muss sein, die Testfälle für mehrere Testdatensätze verwenden zu können. Die Testdaten können den Testern Beispielsweise in Form eines Anhangs zur Verfügung gestellt werden.

Die Testfälle sollen "leben", das bedeutet, dass die Testfälle laufend unterhalten werden müssen und neue Erkenntnisse in die Testfälle einfliessen. Dazu eignet sich ein ALM oder Test Management Werkzeug wie Beispielsweise der SAP Solution Manager in dem die Testfälle verwaltet und ausgeführt werden können. Ein zentrales Werkzeug ist hier auf jeden Fall zu empfehlen.