Thought Leadership
Ohne sie ist der Geschäftserfolg in Gefahr. Doch auch ein Zuviel kann mehr schaden als nützen. Die Rede ist von Software-Tests. Wie finden Unternehmen zu einer gesunden Balance zwischen Aufwand und Ergebnis?
Besser zu viel als zu wenig – im Zweifel verfolgen Unternehmen dieses Motto beim Testen ihrer Software. Dahinter steckt eine gute Absicht: Schließlich soll eine neue Anwendung schnell, fehler- und somit frustfrei von Kunden genutzt werden können. Doch gerade bei Eigenentwicklungen stehen die Testaufwände nicht immer in einem gesunden Verhältnis zum Ergebnis. Daher ist es wichtig, diese Aufgabe strategisch anzugehen und auf die Geschäftsrisiken abzustimmen. Das eröffnet Potenzial für mehr Geschwindigkeit und Effizienz beim Testen.
Das könnte Sie auch interessieren:
eBook
Software Quality & Testing
Automatisiertes Testen ist heutzutage kein Hexenwerk mehr. Jedes gute Unternehmen entwickelt Software mit automatisierten Unit-Tests und Integrationstests. Es ist klar, dass neue Programmiersprachen und Verfahren die tägliche Arbeit erleichtern. Egal ob DevOps, Low-Code und was auch immer da kommen mag, das Stichwort heißt Evolution.
Deutsch, 52 Seiten, PDF 8 MB, kostenlos
Was eigentlich testen? Ein Blick auf Eigenentwicklungen
In der Regel übernehmen externe Dienstleister das Testen. Das Problem dabei ist: Meist werden diese nach der Menge der Tests bezahlt und haben daher ein intrinsisches Interesse daran, so viel wie möglich zu testen. Das sprengt oft den Rahmen des Benötigten und bringt nur begrenzten geschäftlichen Nutzen – im Durchschnitt sind 3 von 4 Testfällen redundant. Viel hilft also nicht viel, wenn die Tests immer wieder dasselbe prüfen. Zudem führt es zu Verzögerungen, weil all die Tests erstellt, ausgeführt und gepflegt werden müssen. Dies ist einer der Hauptgründe, warum das Testen gemeinhin als Flaschenhals Nr. 1 in der Anwendungsentwicklung gilt.
Für Abhilfe können Unternehmen sorgen, indem sie die Abdeckung des Geschäftsrisikos statt der Anzahl der Testfälle in den Fokus rücken. Die Grundlage dafür bildet das Pareto-Prinzip, auch die 80/20-Regel genannt. Sie besagt, dass 20 % des Aufwands 80 % des Wertes schaffen. Übertragen auf die Software-Entwicklung bedeutet das: 20 % Ihrer Geschäftsprozesse decken 80 % Ihres Business ab – oder im Umkehrschluss: Mit den richtigen 20 % der Testfälle lässt sich 80 % des Geschäftsrisikos Ihrer Anwendungen absichern.
Intuitiv arbeitend erreichen die meisten Teams jedoch nur eine Risikoabdeckung von 40 % und häufen am Ende eine Testsuite an, die ein hohes Maß an Redundanz aufweist (“Bloat”). Im Durchschnitt tragen 67 % der Tests nicht zur Risikoabdeckung bei – aber sie verlangsamen die Testsuite in der Ausführung und erschweren ihre Wartung.
Wenn die Tester hingegen verstehen, wie das Risiko über die Anwendung verteilt ist und wenn sie wissen, welche 20 % der Transaktionen mit den 80 % des Geschäftswerts korrelieren, können sie exorbitante Testinvestitionen vermeiden.
Wie testen?
Sobald klar ist, was wirklich getestet werden muss, besteht der nächste Schritt darin, zu bestimmen, wie man es so effizient wie möglich testen kann. Ein einziger strategisch konzipierter Test kann genauso viele (wenn nicht sogar mehr) Risiken abdecken als zehn andere Tests, die “intuitiv” für dieselbe Anforderung erstellt wurden. Was wir brauchen, ist eine neue „Währung“ im Software Testing. Diese darf nicht länger die Anzahl der Testfälle sein, sondern die erzielte Risikoabdeckung!
Ein anderes Bild: Updates von SAP-Anwendungspaketen
Wenn es um Tests für benutzerdefinierte Anwendungen geht, ist weniger mehr. Ein anderes Bild zeigt sich, wenn es beispielsweise um SAP- oder Salesforce-Updates geht. Hier testen Unternehmen meist zu wenig, bevor sie neue Releases in die Produktion einspielen, da dies mit hohem manuellem Aufwand einhergeht. Mehr als 90 % der SAP-Unternehmenskunden starten zunächst eine Testphase mit den Key-Usern. Doch diese haben ohnehin schon wenig Zeit und bekommen das Testing als zusätzliche Aufgabe aufgebürdet. Viele praktizieren daher „Testing for Green“ – sie prüfen nur Fälle, die aller Voraussicht nach bestehen werden. So schließt sich nach dem Go-Live eines Updates routinemäßig eine sogenannte Hypercare-Phase an. In dieser stehen Entwickler und Projektmitarbeiter bereit, um akute, dringende Probleme zu beheben. Das bindet nicht nur wertvolle Ressourcen, sondern ist langwierig und teuer, denn dieser Zeitraum kann bis zu drei Monate in Anspruch nehmen. Künftig wird es noch kostspieliger, denn SAP hat angekündigt, Updates häufiger auszuliefern.
Die gute Nachricht lautet: Auch auf Tests von SAP-Updates lässt sich das Pareto-Prinzip anwenden: Mit modernen Change-Impact-Analysen identifizieren Unternehmen zunächst automatisiert die betroffenen, also „impacted“ Objects. Dann analysieren sie die Objekt-Referenzen und -Abhängigkeiten – also welche geschäftlichen und technischen Risiken mit den Änderungen einhergehen. Die Tester wissen dann genau, welche Tests sie brauchen. Mithilfe von Usage-Daten aus der Produktion lässt sich der Testbedarf zudem priorisieren Kurzum: Sie testen das Richtige so effizient wie möglich. Das zieht immense Auswirkungen nach sich: Unternehmen, die eine automatisierte Change-Impact-Analyse einsetzen, können ihren Testaufwand um 85 % oder mehr reduzieren und die Test- und Hypercare-Phasen um zwei Drittel verkürzen.
Das Richtige effizient testen
Indem Unternehmen Tests strategisch angehen und auf die Geschäftsrisiken abstimmen, können sie noch viel Optimierungspotenzial ausschöpfen. Eine schnellere Betriebsbereitschaft und eine bessere Qualität der Anwendung sind das Ergebnis. Das gilt sowohl für Eigenentwicklungen als auch für Updates von SAP-Anwendungspaketen. Gelingt es, das Richtige so effizient wie möglich zu testen, kommt das Pareto-Prinzip zum Zug: 20 % des Aufwands decken 80 % des Risikos ab. Spezialisierte Anbieter von Lösungen zur Testautomatisierung können hier wertvolle Hilfestellung leisten.
