Zusammenfassung: Die Accelerated Testing Environment (ATE) ist ein leistungsstarkes Werkzeug für das Testen von Software und ermöglicht eine hohe Effizienz und Kosteneinsparungen. Der Blogbeitrag gibt eine detaillierte Anleitung zur Vorbereitung der ATE, einschließlich der Identifizierung von Testanforderungen, der Konfiguration von Testumgebungen und der Definition von Testskripten. Die ATE kann dazu beitragen, die Qualität von Software zu verbessern und die Time-to-Market zu verkürzen.
Wie bereits in BLOG Beitrag 10 dargestellt, nutzen wir das Accelerated Testing Environment, um auf der Basis unserer Best Practice-Prozesse die Testskripte zu erstellen.
Hier, auf loom, finden Sie dazu unseren Erklärfilm „Content Explanation“!
Das Accelerated Testing Environment besteht aus den folgenden Komponenten:
1. Die Testskript Vorlage, auf deren Basis die Testskripte erstellt werden (Unser Erklärvideo zum Thema „Testscript Creation facilitating the S/4HANA Best Practice Process Steps“ findet sich hier auf YouTube).
Die Testskript Vorlage besteht aus drei Bereichen
a. Dem Kopf-Bereich, in dem allgemeine Informationen über den Testfall und dessen Status enthalten sind:
b. Dem statischen Bereich (gelb), der Informationen über die zu Testenden Schritte, den zugrunde liegenden SAP Best Practice-Prozess, die zu nutzenden Daten, die künftige Businessrolle und ggfs. die Kommunikation mit Drittsystemen enthält:
Dieser Bereich wird in jedem Testdurchlauf ggfs. verfeinert und korrigiert und steht dann automatisch entsprechend angepasst im nächsten Test so zur Verfügung. Wichtig ist auch, dass die Stammdaten für einen Testfall nur einmal identifiziert werden müssen und dann immer wieder verwendet werden können, sofern in demselben System getestet wird. Dies ist insbesondere auch in späterem Produktivbetrieb bei der Durchführung von Regressionstests sehr hilfreich und beschleunigt diese erfahrungsgemäß maßgeblich.
c. Dem dynamischen Bereich (blau), der bei jedem Testdurchlauf gefüllt und im Rahmen des Reset (s. unten) wieder zurückgesetzt wird. Hier werden die erzeugten Dokumentennummern, der Status des Testschrittes, Datum und Tester eingetragen. Bei Fehlern oder Unklarheiten erfolgt ein entsprechender Eintrag in den Remarks, der bei Nutzung eines Incident-Management-Systems mit der Nummer des Incidents beginnen sollte; dies erleichtert die spätere Auswertung (s.u.). Optional sollte bei einem Testdurchlauf (z.B. Integrationstest 2) in der spalte „Position Org.“ die Position in der heutigen Organisation, die diesen Schritt durchführt, eingetragen werden, damit diese später ausgewertet werden kann. Rechts neben dem dynamischen Bereich gibt es eine Hilfsspalte, in der die SAP Rolle eingetragen ist, die der Tester sich in der SU01 zuordnen muss, um auf die entsprechenden FIORI Apps zugreifen zu können.
2. Das „Status-Master“ File, mithilfe dessen zu jedem Zeitpunkt
a. Der aktuelle Stand des Tests ermittelt und dieser pro Team dargestellt werden kann
b. Die Zuordnung von Transaktionen zu den künftigen Business Rollen im Rahmen einer bereits definierten PIVOT-Tabelle dargestellt werden kann und als Grundlage des Aufbaus des Berechtigungskonzeptes genutzt werden kann
c. Die Zuordnung der künftigen Business Rollen zu den heute im Unternehmen bestehenden Funktionen und Rollen im Rahmen einer bereits definierten PIVOT Tabelle dargestellt werden kann und dies als Input für das OCM (Organisational Change Management) sowie eine erste Abschätzung der notwendigen End-User-Trainings genutzt werden kann.
Die Bedienoberfläche des „Status-Master“ sieht wie folgt aus:
Es kann entweder ein default Pfad genutzt werden, oder, falls dies nicht markiert ist, der entsprechende Pfad, in dem die Testskripte liegen, im Dialog ausgewählt werden:
Unseren Erklärfilm „Managing Test Status“ finden Sie hier auf loom!
3. Das „Testfälle Enhancements“ File, mithilfe dessen per Massenverarbeitung
a. Bestehende Testskripte automatisiert in verschiedene Sprachen übersetzt werden können und auch die Dateinamen gemäß Vorgabe übersetzt und in die Skripte übertragen werden können
Unseren Erklärfilm „Testscript Translation“ finden Sie hier auf YouTube!
b. Ein Reset der Testskripte in einem Verzeichnis erfolgen kann, um diese für den nächsten Testdurchlauf vorzubereiten z.B. nach dem Integrationstest zur Vorbereitung des Akzeptanztests
Unseren Erklärfilm „New Testcycle Preparation“ finden Sie hier auf loom
c. Die Team-Bezeichnungen in den Testskripten vereinheitlicht werden können
Unseren Erklärfilm „Role based Team assignment“ finden Sie hier auf loom!
d. Bestehende Testskripte auf Verlinkungen überprüft und diese ggfs. entfernt werden können
Unseren Erklärfilm „ChecknRemove Hidden Links in Testscripts“ finden Sie hier auf loom!
Die Bedienoberfläche des „Testfälle Enhancements“ sieht wie folgt aus:
Wie man hier an der Anmerkung sieht, wird die Übersetzung aufgrund von zwei Quellen vorgenommen, zum einen einer Excel-Datei mit fixen Übersetzungsvorgaben und wenn dort kein Eintrag gefunden wird, wird der Term automatisiert mittels dem Google Translator übersetzt.
Damit kommen wir auch zur letzten Komponente des „Accelerated Testing Environment“.
4. Das „Translation.xlsx“ File, in dem die gemäß fester Vorgabe zu übersetzenden Begriffen enthalten sind, und zwar für:
a. Transaktionsbezeichnungen (gefüllt per Download aus der STCT)
b. Die SAP Business Rollen (gemäß denen in den SAP Best Practice-Prozessen)
c. Die verwendeten Begriffe im Kopfbereich und deren Position
d. Allgemeine wiederkehrende spezielle SAP Begriffe, wie z.B: Buchungskreis, Werk etc.
e. Die Dateinamen pro Test-Case
f. Tasks
g. Fiori App-Bezeichnungen
Diese werden in den entsprechenden einzelnen Registern in den relevanten Sprachen gepflegt (natürlich nur dann, wenn man die Übersetzungsfunktion nutzen möchte):
Grundprinzip ist es, dass, damit das Accelerated Testing Package verwendet werden kann, alle Testskripte eines Tests in einem Verzeichnis abgelegt sind, also pro Test ein Verzeichnis existiert:
In diesen sollte es dann jeweils ein Verzeichnis geben, welches das „Status-Master“ File enthält und eines, in dem die Testskripte abgelegt sind, z.B. so:
Die anderen Files können in einem zentralen Laufwerk verbleiben.
Für mich hat sich folgendes Vorgehen bewährt:
1. Im Rahmen des Prototyping wird die erste Version des Testskripte aufgebaut und wenn dies abgeschlossen ist, in ein Verzeichnis „Master-Testskripte“ übernommen
2. In diesem Verzeichnis werden die Testskripte mittels der „Reset Testfiles“ Funktion zurückgesetzt.
3. Danach werden alle Testskripte in das entsprechende Testing-Verzeichnis des nächsten Tests kopiert und der Test durchgeführt und die Testskripte beim Testen ggfs. erweitert und korrigiert (am besten nur durch das Einfügen oder Löschen ganzer Zeilen, um die Konsistenz zu wahren). Wenn der Test abgeschlossen ist, werden die überarbeiteten Testskripte wieder in das Verzeichnis „Master-Testskripte“ kopiert und die dort befindlichen Skripte dadurch mit der neuesten Version überschrieben.
Dann geht es wieder mit 2. weiter. So ist sichergestellt, dass im Verzeichnis „Master-Testskripte“ immer die aktuellste Version verfügbar ist.
4. Wenn zu einem Zeitpunkt dann mehrsprachig gearbeitet werden soll oder muss, kann man die relevanten Testskripte aus dem Verzeichnis „Master-Testskripte“ in eines für die Sprache bzw. den Test kopieren und dort dann mit der „Start Translation“ Funktion übersetzen. Da dieses Vorgehen ja beliebig oft wiederholbar ist, kann man abhängig von dem über die Standorte angestrebten Standardisierungsgrad entscheiden, ob man immer wieder von den Master-Testskripten derselben Sprache ausgeht oder erlaubt, dass die sprachspezifischen Versionen auseinanderlaufen.
Unseren Erklärfilm „Mass Renaming Testscripts“ finden Sie hier auf YouTube!
Unseren Erklärfilm „Cleansing of messed up testscripts“ finden Sie hier auf YouTube!
Pragmatisch, praktisch, gut.
Mit der skizzierten Vorgehensweise können die Testskripte evolutionär bis zur Produktionsreife verfeinert und vervollständigt werden und danach insgesamt oder nur eine definierte Auswahl für künftige Regressionstests z.B. bei Rollouts, Zukäufen oder Releasewechseln in gleicher Art und Weise verwendet werden.
Außerdem ist jeder durchlaufene Test vollständig in seinen Teilschritten und Ergebnissen dokumentiert und die erfolgreich getesteten Testskripte können auch direkt genutzt werden, um die Fachabteilungen auf diesen die Durchführung der Tests und die Abnahme bestätigen zu lassen.
Nach meinem Dafürhalten ist das der bei weitem pragmatischste und aufwandsminimale Weg, um die Tests in SAP-Einführungen zu planen, zu organisieren und zu monitoren und hat zudem noch eine ganze Reihe von Zusatznutzen (wie z.B. Input für Berechtigungen, OCM und End-User-Schulungen).
Das Accelerated Testing Package zur Erstellung Ihrer Testskripte auf der Basis der Best Practice-Prozesse können Sie über diesen Link bei uns im Shop herunterladen. Die umfassende Liste der „S/4HANA Business Process Steps“ mit 4.580 Einträgen finden Sie hier.
Unsere Kunden, die damit arbeiten, berichten, dass das Paket einfach zu verstehen und anzuwenden ist und die Tests mit geringem Aufwand aufgesetzt werden können, sowie dass insbesondere auch die Möglichkeit des täglichen Real-Time Monitoring des Testfortschritts pro Team die Test-Motivation bei allen Beteiligten massiv steigert.
Aus Projektleitungssicht habe ich die Möglichkeit, gerade in umfangreichen Tests die Incidents herausfiltern zu können (deren Lösung für das effektivste Fortkommen im Test wichtig ist) sehr schätzen gelernt. Denn so können die betroffenen Ressourcen entsprechend fokussiert werden.
Hier finden Sie eine Übersicht unserer Tools, die Sie im Digistore24 erwerben, herunterladen und für Ihr Projekt nutzen können.