QA-Teams haben es heutzutage nicht leicht. Der in vielen Unternehmen erforderliche Umfang an Testings und Validierungen übersteigt deutlich die vorhandenen Kapazitäten. Dafür gibt es zahlreiche und gut dokumentierte Gründe, z. B. die vielen Änderungen im modernen Geschäftsbetrieb, der Konkurrenzdruck, regulatorische Anforderungen und vieles mehr. Das ändert jedoch nichts an der Tatsache, dass niemals so viel getestet werden kann, wie man gern möchte.
Die Branche hat sich mit diesem Umstand mittlerweile abgefunden und investiert in Ressourcen und Methoden, mit denen die Auswirkungen auf den Geschäftsbetrieb durch unzureichend getestete Freigaben reduziert werden können. Man verlegt sich also auf risikobasiertes Testing und bestimmt, was getestet werden muss und was man „wahrscheinlich auslassen kann“, um den gesamten Testaufwand zu reduzieren. Die Tools in diesem Bereich nutzen üblicherweise technische Analysen, um Änderungen zu identifizieren und Testing-Prioritäten zu setzen. Dabei geht jedoch oft der Zusammenhang zwischen der Art des Geschäftsbetriebs und dem entwickelten Code verloren.
In der Praxis sind solche risikobasierten Analysen nur ein kleiner Fortschritt. Es wird davon ausgegangen, dass einige Teile nicht getestet werden müssen, weil die Wahrscheinlichkeit, dass sie Schäden verursachen, gering ist. Diese Annahme setzt fälschlicherweise voraus, dass ein Code, der keine direkten „Änderungen“ enthält, auch keine Auswirkungen auf die Funktionsfähigkeit des Systems haben kann. Risikobasiertes Testing versucht, die QA-Ressourcen zu priorisieren und akzeptiert dafür eine deutlich geringere Testabdeckung und ein höheres Risiko, fehlerhaften Code in der QA zu übersehen. Es nimmt also die Gefahr eines Betriebsausfalls in Kauf. Kurz gesagt, risikobasiertes Testing verteidigt das Auslassen von Tests!
Um das vollständige Risiko bei Nutzung dieses Ansatzes einschätzen zu können, wäre eine detaillierte technische Analyse notwendig. Aber das Problem liegt schon in der grundsätzlichen Vorstellung, Abhängigkeiten und Änderungen könnten vollständig über eine technische Analyse erfasst werden. Zwar funktioniert dies für viele Änderungen, doch zu oft ist eine Identifizierung ganzer Kategorien von Abhängigkeiten und Änderungen mit diesem Ansatz gar nicht möglich. Beispiele dafür sind Auswirkungen von Stammdaten auf die Code-Logik, Objekte mit Runtime-Verknüpfungen, Integrationen in externe Systeme und so weiter.
Tatsächlich weisen selbst Befürworter des risikobasierten Testings auf die Grenzen dieses Ansatzes hin, insbesondere bei Business-Systemen. SAP selbst zeigt den folgenden Haftungsausschluss in der Beschreibung des Scope & Effort Analyzer, ihrer eigenen Lösung für risikobasiertes Testing: „Die Analyse deckt nicht den gesamten projektbezogenen Umfang eines Wartungsprojekts ab. Außerdem beinhalten die Analyseergebnisse ausdrücklich keine Aussagen zu funktionalen Änderungen wie der Aktivierung von betrieblichen Funktionen. Im Ergebnisbericht des Scope & Effort Analyzer sind nicht alle Daten und Angaben enthalten, die bei einem echten, vollumfänglichen Wartungsprojekt anfallen können.“
Was können Sie also tun?
Wir wissen, dass eine Kombination aus begrenzten Ressourcen und manuellem Testing die Arbeit nicht erledigt werden kann – deshalb ist risikobasiertes Testing schließlich auch so attraktiv. Testautomatisierung ist also ein Muss. Doch auch zwischen den erhältlichen Automatisierungs-Tools gibt es riesige Effizienz-Unterschiede. Eine Automatisierungslösung, die voraussetzt, dass eine Person die Ausführung eines Tests (wie ein Babysitter) beaufsichtigt, ist nicht besser als ein manueller Test. Die Arbeit wird lediglich von einem mit der Thematik vertrauten Experten zu einem Benutzer mit Fachkenntnissen verlagert. (Verzichten Sie auf diese Option, sie führt zu nichts.)
Beim Testen von SAP ist es besser, immer alles zu testen und das erfordert einen vielschichtigen Ansatz. Für Regressionstests innerhalb von SAP sollten Sie einen Blick auf Robotic Test Automation (RTA) werfen. RTA-Lösungen eliminieren den Wartungsaufwand für Testbibliotheken und sorgen automatisch für durchgehende komplette Testabdeckung, auch wenn sich die Nutzung der Anwendung verändert. Ohne RTA reicht der Automatisierungsgrad vielen SAP-Nutzern nicht aus, denn Unterhalt und Wartung der Testbibliothek verbrauchen weiter Ressourcen, die besser für eine größere Testabdeckung genutzt werden sollten.
Nutzen Sie regelmäßig RTA für umfassende Regressionstests, sobald der Code fertig entwickelt ist – lange bevor manuelle oder traditionelle automatisierte Tests wegen ihrer Abhängigkeit von einer vollständigen Testumgebung eingesetzt werden können. Das eliminiert die typischerweise ins Unermessliche steigenden Anforderungen für die Regression und reduziert den verzichtbaren QA-Aufwand für das Testing neuer Features. Als Ergebnis erhält das QA-Team mehr Freiraum, um sich auf die funktionellen Änderungen zu konzentrieren, die das Geschäft von Freigabe zu Freigabe benötigt. So können Testzyklen merklich verkürzt werden.
Für Progressions-Tests (neue Funktionen) sollte Ihr Automatisierungsanbieter eine skalierbare Lösung zur Automatisierung der Testausführung und Berichterstellung bereitstellen. Sie sollte vollautomatisch und leistungsstark sein und so oft wie nötig eingesetzt werden können, insbesondere nachts, wenn neue Komponenten meist integriert werden. Tatsächlich wäre, abhängig von Ihrer SAP-Umgebung, eine Mischung aus manuellen Tests neuer Funktionen und Robotic Test Automation für den umfangreichen Rest der Regressions-Testabdeckung die ideale Lösung. Hierbei ist wichtig, wirklich immer alles zu testen, akzeptieren Sie keine Lösung, die sich mit weniger zufrieden gibt!
Mit der richtigen Lösung für SAP-Tests besteht kein Bedarf an einem risikobasierten Ansatz und es gibt keinen Grund, ein zusätzliches Risiko einzugehen. Wenn die Zeit für Tests stark eingeschränkt ist, weil Ressourcen fehlen oder Fristen einzuhalten sind, sollten Sie über Automatisierung nachdenken. Dank der heute verfügbaren Lösungen, inklusive Robotic Test Automation, sind stabile Tests und volles Vertrauen in die Funktionalität aller Freigaben der neue Standard.
Wenn Sie mehr über RTA erfahren wollen und genauer wissen möchten, warum risikobasiertes Testing keine gute Idee ist, nutzen Sie unser Webinar.
