Viele Köche verderben den Brei!
Das Sprichwort kann bestätigen, wer Erfahrungen beim Customizing von ERP-Systemen gesammelt hat. Wenn Hersteller, Kunde und Dienstleister auf eine Anwendung einwirken, sollte die QS sicherstellen, dass alle Änderungen zusammenwirken.
Zumindest in der Theorie, in der Praxis stellt die Komplexität der Systeme eine fast unüberwindbare Hürde dar.
Am Beispiel von APplus zeigt der Beitrag, wie ein Test von ERP-Systemen möglich ist.
Qualitätssicherung von ERP-Systemen
Die Qualitätssicherung betriebswirtschaftlicher Standardsoftware wie ERP-Systemen stellt für Hersteller, Dienstleister und Kunden eine besondere Herausforderung dar:
- Die Applikationen stechen durch einen großen Funktionsumfang und eine hohe fachliche Komplexität heraus.
- Anpassungen können von verschiedenen Akteuren ausgehen:
- Hersteller im Rahmen der allgemeinen Wartung und Weiterentwicklung.
- Kunde und externe Dienstleister im Rahmen kundenspezifischen Customizings.
- Hersteller angebundener Drittsysteme wie Dokumentenmanagementsysteme, Kassensoftware oder Applikationen zur Anlagensteuerung.
- Ausfälle oder Fehler können das Kerngeschäft des Kunden empfindlich treffen und bergen entsprechend hohe wirtschaftliche Risiken.
- Der Hersteller sichert bestenfalls die Qualitätssicherung der Standardfunktionalität zu, während der Test des Customizings oft dem Kunden überlassen ist. Dieser verfügt jedoch meist nur über begrenzte IT-Kompetenzen und Ressourcen.
In der Praxis führt diese Gemengelage immer wieder dazu, dass Kunden Updates des Herstellers nicht einspielen, weil sie nicht sicherstellen können, dass ihre Anpassungen und Kernprozesse hinterher noch stabil funktionieren. Mit dieser Never change a running system Haltung begibt sich der Kunde spätestens dann auf sehr dünnes Eis, wenn Updates ausgelassen werden, die wichtige Bugfixes oder sicherheitsrelevante Anpassungen enthalten.
Um dieses Problem zu addressieren, benötigt der Kunde eine Möglichkeit automatisierte Tests erstellen und ausführen zu können, ohne vertieftes Know-How im Bereich der Testautomatisierung zu benötigen oder den enormen initialen Aufwand zum Aufbau einer Testinfrastruktur allein stemmen zu müssen.
Dieser lässt sich bei kluger Herangehensweise jedoch erheblich reduzieren, da einige Eigenschaften von ERP-Systemen der Erstellung automatisierter UI-Tests entgegenkommen:
- Um Wiederverwendbarkeit und einen einheitlichen Look & Feel zu gewährleisten, sind Benutzeroberflächen meist hochgradig standardisiert. Sie bestehen aus einem Baukasten vorgefertigter UI-Controls, die durch einen Testtreiber mit einer standardisierten Logik angesteuert werden können.
- Der Aufbau der Seiten folgt vielmals einem einheitlichen Schema, was das Skripten automatisierter Tests erleichtert.
- Teile des Verhaltens sind ebenfalls für alle oder einen Großteil der Geschäftsobjekte standardisiert, um dem Benutzer einheitliche Workflows für Standardaktionen wie CRUD-Operationen, Suchen oder Filtern zu bieten.
Für die Umsetzung einer Testautomatisierung in einem solchen Umfeld eignet sich ein Ansatz, der auf Behaviour Driven Testing bzw. Behaviour Driven Development basiert.
Beim Behaviour Driven Dvelopment/Testing bilden ausführbare und an natürlicher Sprache angelehnte Beschreibungen die Grundlage der Testaktivitäten. Im Vergleich zu konventionellen Ansätzen, die zu sehr techniklastigen Testartefakten führen, bietet dieses einige Vorteile:
- Testskripte sind für Stakeholder ohne Entwickler Know-How leichter lesbar und verständlich.
- Anforderungen lassen sich klarer aus den Testskripten ableiten, was Aufwände für Dokumentation und Verwaltung von Testfällen minimiert.
- BDT zwingt zu einer konsequenten Wiederverwendung von Testcode, was Redundanz vermeidet, und die Wartung des Testprojektes erleichtert.
- Die Unterstützung verschiedener Versionen und Varianten des Testobjektes lässt sich vergleichsweise einfach umsetzen.
Aufbau einer BDT-Infrastruktur
Bei der Automatisierung eines sehr umfangreichen Testobjektes wie APplus ist es essenziell eine Architektur zu verwenden, die einen hohen Grad an Wiederverwendbarkeit und Skalierbarkeit ermöglicht. Andernfalls wird das Vorhaben früher oder später an den Aufwänden zur Implementierung und Wartung der Automatisierungsskripte scheitern.
Abbildung 1 zeigt den Aufbau einer im Hinblick auf diese Anforderungen bewährten BDT-Infrastruktur schematisch.
Integration und Steuerung des Testframeworks
Die Interaktion mit dem Testobjekt wird über den Browser durchgeführt, welcher durch das verwendete UI-Testframework gesteuert wird. Für diesen Zweck eignet sich jedes gängige UI-Testframework, wie etwa Selenium, WebDriverIO, Cypress oder Playwright. Zudem wird ein BDT-Framework wie zum Beispiel Cucumber benötigt.
Die Integration des BDT-Frameworks, sowie die Interaktion mit dem Testframework wird durch den Testtreiber konfiguriert. Die Testinfrastruktur kann mehrere Testtreiber enthalten, die verschiedene UI-Testframeworks unterstützen, wie etwa Playwright für Web-Apps oder Appium für native Apps. Testtreiber sind spezifisch für das verwendete UI-Testframework, aber unabhängig vom Testobjekt.
Automatisierung der Interaktion mit dem Testobjekt
Die testobjektbezogene Konfiguration wird in den Komponenten, Step-Definitionen und Features vorgenommen.
Komponenten
Komponenten automatisieren ein spezifisches Control in der Benutzeroberfläche des Testobjektes, wie etwa Eingabefelder, Buttons, Listen, Dialoge oder auch komplexere Elemente wie Datepicker oder Autocomplete Felder. Die Auslagerung dieser Funktionalität in Komponenten entsprechend dem DRY Prinzip, sorgt für übersichtliche Step-Definitionen und minimalen Anpassungsaufwand, falls sich das Verhalten von UI-Controls ändert.
Step-Definitionen
Step-Definitionen automatisieren Interaktionen, die für den Anwender einen nachvollziehbaren Nutzen haben. Ihre Implementierung wird mit einem an natürlicher Sprache angelehnten Ausdruck verknüpft, der in Testskripten verwendet werden kann. Listing 1 zeigt dies an einem einfachen Beispiel eines Steps, der den Ausdruck ‚ich setze den Haken in einem Feld {string}‘ mit der Ausführung der Methode WhenIchSetzeDenHakenFuerDasFeld verknüpft. Diese selektiert lediglich eine Checkbox, allerdings sind auch Step-Definitions möglich, die eine komplexe Folge von Benutzerinteraktionen abbilden.
Beispiel einer Step-Definition
| 12345 | async function WhenIchSetzeDenHakenFuerDasFeld(this: ICustomWorld, feld: string) { await this.formular.selectCheckbox(feld, true);}When('ich setze den Haken für das Feld {string}', WhenIchSetzeDenHakenFuerDasFeld); |
Bei der Festlegung des Umfangs der Step-Definitionen muss ein Kompromiss zwischen Nutzen und Wiederverwendbarkeit gefunden werden. Elementare Step-Definitionen wie ‚ich klicke in das Feld mit dem Namen „Auftrag-Nr“‘ lassen sich leicht wiederverwenden, allerdings ist ihr Nutzen nahezu null. Step-Definitionen die ganze Anwendungsfälle abbilden wie ‚ich lege einen Auftrag für den Kunden „Michael Meier“ und den Artikel mit der Nummer „12345678“ an‘, haben einen hohen fachlichen Nutzen, sind aber so spezifisch, dass sie sich kaum wiederverwenden lassen. Gute Kandidaten für Steps sind Standardfunktionalitäten, die an vielen Stellen in der Applikation in ähnlicher Form vorkommen, wie etwa Authentifizierung/Autorisierung, Seitennavigation, Suchen, Filtern oder Sortieren.
Durch die Übergabe von Parametern können Step-Definitionen generisch formuliert werden. So etwa kann ein Step ‚ich gebe in das Feld mit dem Namen {string} Daten ein‘ Daten in ein beliebiges Feld eintragen. Bei der Verwendung des Steps werden der Name des Feldes als String übergeben und die Eingabedaten als sogenanntes Example in tabellarischer Schreibweise.
Step-Definitionen können nicht nur Aktionen eines Benutzers simulieren, sondern auch Assertions abbilden, die das Systemverhalten prüfen und damit sicherstellen, dass die vorangegangenen Aktionen das erwartete Ergebnis liefern.
Zur Implementierung der Interaktion mit dem Testobjekt rufen die Step-Definitionen Funktionen der Komponentenklassen auf. Im obigen Beispiel ist dies die Funktion selectCheckbox der Klasse Formular.
Beispiele für Step-Definitionen:
- Ich melde mich mit dem Benutzer {string} und der Rolle {string} an.
- Ich navigiere zur Seite {string}
- Ich sortiere die Liste {string} aufsteigend nach dem Kriterium {string}
- Ich suche und öffne den {string} Datensatz mit der ID {number}
- Ich gebe den Wert {string} in das Feld mit dem Namen {string} ein
- Ich lege einen neuen {string} Datensatz an
- Ich speichere den aktuellen Datensatz
Beispiele für Assertion Step-Definitionen:
- Ist in der Liste {string} ein Datensatz mit dem Wert {string} in der Spalte {string} vorhanden
- Ist der Datensatz mit der ID {number} gespeichert
- Ist das Feld mit dem Namen {string} mit dem Wert {string} befüllt
Features
Features oder auch Feature-Skripte bilden die im Rahmen eines Testfalls durchzuführenden Schritte durch eine Abfolge von Step-Aufrufen ab. Ausgangspunkt für Features sind Anforderungen oder die daraus abgeleiteten Testfälle. Durch die Adressierung der Steps mittels natürlichsprachlicher Ausdrücke anstelle von technischen Funktionsaufrufen, lassen sich Feature-Skripte auf ähnliche Weise verfassen, lesen und analysieren wie eine Testfallbeschreibung. Verglichen mit natürlichsprachlichen Testfallbeschreibungen sind sie jedoch klarer strukturiert, präziser und knapper. Durch die Beschränkung des Vokabulars auf eine vordefinierte Menge an Bausteinen, gibt es wenig Spielraum für ausschweifende, ungenaue oder mehrdeutige Formulierungen. Autoren von Feature-Skripten benötigen kein umfassendes technisches Knowhow auf Entwicklerniveau, wodurch auch technisch versierte Benutzer des Testobjektes oder Domänenexperten die Skripte erstellen und bearbeiten können.
Ein Feature besteht immer aus den drei Bereichen Angenommen (Given), Wenn (When) und Dann (Then).
- Unter Angenommen werden alle Vorbedingungen aufgeführt, die erfüllt sein müssen, damit der Test erfolgreich ausgeführt werden kann.
- Der Bereich Wenn, aggregiert alle Schritte die notwendig sind, um den zu testenden Anwendungsfall auszuführen. Die Prüfung der Ergebnisse sowie des Systemzustandes nach Abschluss des Tests erfolgt
- im Bereich Dann. Parameter werden direkt in die Step Ausdrücke eingefügt oder in tabellarischer Form als Example definiert. Für komplexe Szenarien ist auch ein Import der Daten über Formate wie CSV möglich.
Beispiel eines Testskriptes
Das nachfolgende Beispiel zeigt ein mittels der Sprache Gherkin geschriebenes Testskript, welches die in der nachfolgenden Abbildung gezeigte APplus Seite zur Auftragsbearbeitung automatisiert.
Testskript Auftrag mit Position anlegen und disponieren
| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 | Funktionalität: Auftrag anlegen, freigeben und disponieren Szenario: Einen Neuen Auftrag hinzufügen und Position hinzufügen#Auftrag erstellen Angenommen Ich navigiere zu Seite "Auftrag bearbeiten" Wenn ich lege einen neuen Datensatz an Wenn ich merke mir den Wert aus Feld "Auftrag" unter "Nummer" Wenn ich öffne eine Pickliste für das Feld "Adresse" Wenn ich klicke in dem Dialog auf "Suchen" Wenn ich suche und wähle einen Datensatz aus einer Pickliste mit folgenden Werten | Firma | Meier% | | Adresse | 108824.01 | Wenn ich merke mir den Wert aus Feld "Adresse" unter "Adresse" Wenn ich gebe den Wert unter "Adresse" in Feld "Lieferadresse" ein Wenn ich gebe den Wert unter "Adresse" in Feld "Rechnungsadresse" ein Wenn ich gebe das Datum 12.10.2022 für das Feld "Datum" ein Wenn ich gebe das Datum 22.10.2022 für das Feld "Wunschtermin" ein#Assertion Dann hat der aktuelle Datensatz die Feldwerte | Datum | 12.10.2022 | | Wunschtermin | 22.10.2022 | | Adresse | 108824.01 | | Lieferadresse | 108824.01 | | Rechnungsadresse | 108824.01 |#Tab Bereiche ausfüllen Wenn ich navigiere zum Tab-Bereich "Info" Wenn ich gebe Daten ein | Zolltarifnr. drucken | ja |#Assertion Dann hat der aktuelle Datensatz die Feldwerte | Zolltarifnr. drucken | ja |#Datensatz speichern Wenn ich speichere den aktuellen Datensatz #neue Auftrag Pos hinzufügen Wenn ich führe die Aufgabe "neue Position" > "Neue Position" aus Wenn ich öffne eine Pickliste für das Feld "Artikel" Wenn ich klicke in dem Dialog auf "Suchen" Wenn ich suche und wähle einen Datensatz aus einer Pickliste mit folgenden Werten | Artikel | 01.100709 | Wenn ich speichere den aktuellen Datensatz Wenn ich wechsle auf die vorherige Seite#Auftrag freigeben Wenn ich führe die Aufgabe "Freigeben" aus Dann hat der aktuelle Datensatz den Status "freigegeben"#Auftrag disponieren Wenn ich führe die Aufgabe "Disponieren" aus Dann hat der aktuelle Datensatz den Status "disponiert" |
Zur besseren Nachvollziehbarkeit sind die wichtigsten Schritte nachfolgend beschrieben.
- Navigation zur Zielseite.
- Neuen Auftrag Datensatz anlegen.
- Die vom System generierte Auftrag ID im Kontext des Testsystems speichern.
- Daten in mehrere Felder eingeben. Dabei werden komplexe UI-Controlls wie Picklisten oder Datepicker verwendet.
- Eingaben prüfen.
- Eingaben im ‚Tab Bereich‘ (Tab Leiste unten) vornehmen und prüfen.
- Auftrag speichern.
- Artikel suchen und als Position zum Auftrag hinzufügen.
- Position speichern und zum Auftrag zurückkehren.
- Den Auftrag mittels der Aufgaben (Liste rechts) freigeben und disponieren. Die Statusänderung nach Abschluss des Aufrufs prüfen.
Der gezeigte BDT-Ansatz ermöglicht es eine einfach anwendbare, flexible, skalierbare und erweiterbare Infrastruktur für den Test von ERP-Systemen zu implementieren. Verglichen mit traditionellen Ansätzen der Testautomatisierung muss vor allem betont werden, dass BDT dem Kunden Werkzeuge in die Hand geben kann, die es ihm ermöglichen, Anpassungen weitgehend ohne externe Unterstützung automatisiert testen zu können.
Fazit
Bei aller Euphorie sollte nicht unerwähnt bleiben, dass der Ansatz des UI-Testings Grenzen hat. Viele Aspekte lassen sich nicht ausschließlich über die Benutzeroberfläche prüfen, wie etwa Schnittstellen zu Drittsystemen, Datenbankzustände oder asnychrone Verarbeitungen wie der Im- und Export von Dokumenten.
Dennoch kann der Ansatz einen wertvollen Beitrag liefern, um die Risiken durch Updates, Konfigurationsänderungen oder Anpassungen von ERP-Systemen wie APplus zuverlässiger bewerten zu können.