In der Welt von DevOps dreht sich alles um den Begriff „kontinuierlich“: kontinuierliche Integration, kontinuierliche Auslieferung, kontinuierliche Tests und kontinuierliche Verbesserung. Doch wie passen Regressionstests in dieses Konzept?
Wie wir alle wissen, sind Regressionstests für SAP-Systeme von essenzieller Bedeutung. Die vernetzte Struktur von SAP führt dazu, dass die Änderung eines Geschäftsprozesses auch für andere Prozesse Folgen haben kann. Das Erkennen solcher potenziellen Konflikte ist entscheidend für den Schutz der Produktionssysteme und die Gewissheit, dass der Geschäftsbetrieb durch eine Änderung nicht unterbrochen wird. Auch bei Nutzung eines Wasserfallansatzes mit seltenen, aber umfangreichen Änderungen ist womöglich nur ein sehr kleiner Teil der täglich genutzten Unternehmensprozesse tatsächlich betroffen – wir bei Basis Technologies nennen dies den Eisbergeffekt.
Der kleine, sichtbare Teil des Eisbergs über der Wasseroberfläche steht für die Änderungen an den aktuellen Geschäftsprozessen, die mit dem nächsten Release angestrebt werden. Der überwiegende Teil des Eisbergs ist jedoch unsichtbar unter Wasser – er steht für alle Prozesse, die von der neuen Funktionalität nicht direkt betroffen sind und nach der Implementierung korrekt funktionieren müssen. Die Preisfrage lautet also: „Wird irgendein Teil dieser Änderungen die Art und Weise stören, wie ich heute meine Arbeit erledige? Die Antwort darauf ist nicht einfach zu finden.
Die Durchführung von Regressionstests erfordert erfahrungsgemäß viel Zeit, ist schwierig zu automatisieren (insbesondere bei hoher Abdeckung) und erfordert Arbeitskraft und Ressourcen der Business- und QA-Teams. Und nicht zu vergessen: das beste Ergebnis, das man bei Regressionstests erzielen kann, ist … nichts zu finden. Es ist also keine Überraschung, dass sie nicht direkt als wertschöpfende Tätigkeiten gelten.
Das bringt mich zurück zu meiner Frage zu DevOps – wie können Regressionstests Teil einer kontinuierlichen Auslieferung sein, wenn sie unmöglich jeden Tag durchgeführt werden können?
Sind Regressionstests also in der Welt von DevOps veraltet?
Nein, das sind sie nicht. Wir müssen nur den Blickwinkel auf Regressionstests für SAP-Systeme ändern. Regressionstests sollten ab sofort vom Ende des Auslieferungsprozesses an den Anfang verlagert (Linksverschiebung) und automatisiert werden. Lassen Sie mich das kurz erläutern.
Der Regressionstest stand bisher immer am Ende des Freigabezyklus, da es unter anderem technisch schwierig war, ihn zu einem früheren Zeitpunkt durchzuführen. Tatsächlich werden Regressionstests oft als Benutzerakzeptanztests missverstanden. Denn bei letztgenannten liegt der Fokus auf einem 80/20-Ansatz für die wichtigsten Geschäftsprozesse und die Benutzerfreundlichkeit, anstatt im aktualisierten Release nach neu eingefügten Fehlern im Vergleich zum bestehenden zu suchen. Als Grund wird genannt, dass ein vollständiger Funktionstest erst dann möglich sei, wenn das gesamte Release mit allen Abhängigkeiten in einer „produktionsähnlichen“ Umgebung eingespielt und richtig konfiguriert wurde.
Doch das ist der falsche Ansatz. In der Praxis sollten Regressionstests beginnen können, sobald eine Änderung vorliegt und lange bevor sie sich im System einnistet und am Tag der Freigabe zuvor nicht erkannte Fehler im System verursacht. Doch da umfassende Regressionstests ohne die notwendige Integration nur schwer durchführbar sind, hat sich die gesamte Branche damit abgefunden, darauf zu warten, bis versteckte Fehler auf unangenehme Weise sichtbar werden.
Was wäre, wenn man die Abhängigkeiten zwischen Stapel-Komponenten und der Systemlandschaft entkoppeln könnte? Angenommen, die Erstellung der Testwerkzeuge, der notwendigen Testdaten und die Tests selbst könnten vollständig automatisiert werden – mit einer solchen Lösung könnten vollständige Regressionstest so oft wie gewünscht ablaufen, im Idealfall sogar täglich. Und bei einer täglichen Ausführung würden die Tests alle Änderungen umfassen, die ein Entwickler am Vortag erstellt hat – was außerhalb von SAP schon seit Jahren üblich ist. An jedem Morgen würden die Entwickler die Ergebnisse des nächtlichen Testdurchlaufs sehen und könnten alle festgestellten Probleme beheben. Dies bedeutet, dass eine Änderung erst gar nicht zum Progressionstest (SIT, UAT etc.) gelangt, bevor der Regressionstest nicht bestanden wurde.
Auf diese Weise kann nach Abschluss des Progressionstests die Änderung zum gewünschten Zeitpunkt sicher in die Produktion ausgeliefert werden, ohne dass Fehler in das System gelangen. So einfach! Die Auslieferung in SAP-Systeme bleibt kontinuierlich, ohne dass auf einen erfolgreichen Abschluss der Regressionstests verzichtet wurde!
Voraussetzung ist die vollständige Automatisierung des Regressionstests in SAP-Systemen. Hier kommt Testimony von Basis Technologies ins Spiel. Das revolutionäre neue Konzept der Robotic Test Automation automatisiert Regressionstests, ohne dass Testskripte oder Testdaten manuell erstellt oder gepflegt werden müssen. Testimony lernt, wie Ihr Produktionssystem genutzt wird und wandelt es automatisch in eine Testumgebung um. Außerdem lernt es nicht nur, wie Benutzer mit dem System interagieren, es erkennt auch alle anderen Prozesse, die das System beeinflussen, wie Schnittstellen- und Batch-Jobs, so dass die Regressionstests das gesamte System und nicht nur Teile davon erfassen.
Mit Testimony werden vollautomatische Regressionstests Realität und die Möglichkeit, die Tests an den Anfang des Entwicklungsprozesses zu verlagern, stellt sicher, dass bei kontinuierlicher Auslieferung keine Fehler in die Produktionssysteme gelangen. Wir können nun tatsächlich DevOps-Prozesse in SAP umsetzen, ohne dabei die Stabilität der Produktionssysteme zu gefährden – ich bin sicher, man wird in Ihrem Unternehmen von dieser Idee begeistert sein.
Also, sind Regressionstests wirklich veraltet? Ganz und gar nicht – lang leben Regressionstests!
