Mit Testautomatisierung auf das Wichtigste fokussieren Software-Tests nach dem Pareto-Prinzip

Autor / Redakteur: Wolfgang Platz * / Stephan Augsten

Tests bilden der Flaschenhals der Software-Bereitstellung. Meist testen Unternehmen entweder zu viel, zu wenig oder nicht das Richtige – mit entsprechend teuren Folgen. Ziel sollte das Pareto-Prinzip sein: mit 20 Prozent des Aufwands 80 Prozent der Geschäftsrisiken abdecken.

Firmen zum Thema

Beim Software Testing gibt es noch viel Optimierungspotenzial, mit 20 Prozent des Aufwands lassen sich 80 Prozent des Risikos abdecken.
Beim Software Testing gibt es noch viel Optimierungspotenzial, mit 20 Prozent des Aufwands lassen sich 80 Prozent des Risikos abdecken.
(Bild: Austin Distel / Unsplash)

Effiziente Softwaretests sind heute entscheidend für den Geschäftserfolg. Unternehmen müssen in der Lage sein, neue Services schnell auf den Markt zu bringen. Gleichzeitig dürfen sie sich keine Fehler erlauben, denn niemand kann sich verärgerte Kunden leisten.

Bei der Anwendungsentwicklung herrscht daher oft der Hang zur Übervorsicht: Lieber testet man zu viel, als dass man einen Fehler übersieht. Um interne Mitarbeiter zu entlasten, haben viele Unternehmen das Testen an einen externen Dienstleister ausgelagert. Das Problem dabei ist: Meist wird der Lieferant danach bezahlt, wie viele Tests er definiert und automatisiert.

Häufig erhalten Unternehmen dadurch mehr Tests, als sie eigentlich benötigen, und zahlen für etwas, das nur begrenzten geschäftlichen Nutzen bringt. Denn viel hilft nicht viel, wenn die Tests immer wieder dasselbe prüfen.

Zu wenig ist auch keine Lösung

Das umgekehrte Problem herrscht in der Regel vor, wenn es beispielsweise um SAP- oder Salesforce-Updates geht. Hier testen Unternehmen meist zu wenig, bevor sie neue Releases in die Produktion einspielen. Denn Änderungen in Anwendungspaketen zu prüfen, verursacht hohen manuellen Aufwand.

Häufig erfolgt daher zunächst eine Testphase mit den Hauptanwendern. Doch diese haben ohnehin schon wenig Zeit und empfinden das Testen als lästig. Viele prüfen nach eigenen Aussagen daher nur Fälle, die aller Voraussicht nach bestehen werden.

SAP-Betriebsteams nehmen dies bewusst in Kauf und führen deshalb nach dem Go-Live eines Updates routinemäßig eine sogenannte Hypercare-Phase durch. Das heißt, die Entwickler und Projektmitarbeiter stehen bereit, um dringende Probleme sofort zu beheben, sobald sie in der Produktion auftauchen.

Das aber bindet wertvolle Ressourcen und ist darüber hinaus langwierig und teuer, denn eine Hypercare-Phase kann bis zu drei Monate in Anspruch nehmen. Trotzdem verfolgen mehr als 90 Prozent der SAP-Unternehmenskunden diese Einführungsstrategie. Künftig wird das noch kostspieliger, denn SAP hat angekündigt, Updates viel häufiger als je zuvor auszuliefern.

Das Pareto-Prinzip

Sowohl zu viel als auch zu wenig zu testen, ist am Ende teuer und deckt nicht den tatsächlichen Bedarf ab. Ziel sollte vielmehr sein, zur richtigen Zeit genau auf das Richtige zu fokussieren. So lassen sich Aufwände insgesamt reduzieren und gleichzeitig Risiken minimieren. Hier greift das Pareto-Prinzip, die sogenannte 80/20-Regel.

Im Allgemeinen versteht man darunter, dass 20 Prozent des Aufwands 80 Prozent des Wertes schaffen. Übertragen auf die Software-Entwicklung machen 20 Prozent der Transaktionen somit 80 Prozent des Geschäftswerts aus. Folglich können Tests für 20 Prozent der Anforderungen 80 Prozent des Geschäftsrisikos abdecken,

Tests auf die Risiken abstimmen

Für die Anwendungsentwicklung bedeutet das: Statt möglichst viel und immer wieder dasselbe zu testen, sollten die Tester auf die wichtigsten Geschäftsrisiken fokussieren. In der Praxis gelingt dies nur selten. Da die meisten Teams intuitiv arbeiten, erreichen sie nur eine Risikoabdeckung von 40 Prozent und sammeln am Ende eine aufgeblähte Testsuite an, die einen hohen Grad an Redundanz aufweist.

Im Durchschnitt tragen 67 Prozent der Tests nicht zur Risikoabdeckung bei, bremsen aber die Performance der Testsuite aus und erschweren ihre Wartung. Um das Testen schneller, effizienter und wirkungsvoller zu machen, müssen Tester die Zusammenhänge zwischen Anwendungsfunktionalität und Geschäftsrisiken kennen. Daraus ergibt sich, was wirklich getestet werden muss.

Anschließend geht es darum, zu definieren, wie man dies möglichst effizient testen kann. Ein einziger strategisch entworfener Test kann mehr erreichen und mehr Risiken abdecken als zehn intuitive, die für dieselbe Anforderung entwickelt wurden. Hier kommt die „Test Case Design“-Methodik ins Spiel.

Mit einer effektiven Strategie wie der linearen Expansion können Tester die risikoreichsten Anforderungen maximal effizient prüfen. Die Strategie führt zur kleinstmöglichen Anzahl an Tests, die nötig sind, um die wichtigsten Risiken abzudecken und sicherzustellen, dass das Team bei einem fehlgeschlagenen Test genau weiß, welche Anwendungsfunktionalität es untersuchen muss.

Auswirkungen von Änderungen analysieren

Auf das Testen von SAP-Updates lässt sich das Pareto-Prinzip ebenfalls anwenden. Wie in der Anwendungsentwicklung gilt: Man muss das Richtige testen – und zwar so effizient wie möglich. Dies gelingt, indem Unternehmen zunächst automatisiert identifizieren, wo sich Code geändert hat, und dann analysieren, welche geschäftlichen und technischen Risiken die Änderungen mit sich bringen.

So können sich die Tester auf die größten Risiken konzentrieren und zielgerichtet vorgehen. Sie wissen genau, welche Tests sie brauchen, und erkennen, welche neuen oder bereits bestehenden Tests häufig wechselnde Hotspots abdecken und daher automatisiert werden sollten. Außerdem wissen sie auch, welchen Code sie nicht zu testen brauchen.

Bei großen Anwendungspaketen kann es allerdings vorkommen, dass sich Änderungen in einer bestimmten, zentralen Komponente auf viele Objekte auswirken. Sie alle werden in der Analyse dann als „betroffen“ angezeigt. Um das Testvolumen zu reduzieren, ist es empfehlenswert, sich auf die am meisten gefährdeten Objekte zu konzentrieren.

In der Praxis hat sich gezeigt, dass Unternehmen, die eine automatisierte Change-Impact-Analyse einsetzen, ihren Testaufwand um 85 Prozent oder mehr reduzieren konnten und sich die Test- und Hypercare-Phasen um zwei Drittel verkürzen ließen.

Daten beim Testen nicht vergessen

Doch es gibt noch eine weitere Baustelle: Unternehmen müssen auch die Daten testen, die den Anwendungen zu Grunde liegen. Denn selbst wenn alle Komponenten eines Systems auf den ersten Blick wie erwartet funktionieren, sind sie ohne die richtigen Daten wertlos. Führt ein Software-Update zum Beispiel eine subtile Änderung der Datenformate ein, sodass einer von 100.000 Datensätzen nicht richtig verarbeitet wird, kann das erhebliche Störungen verursachen.

Moderne Applikationen konsumieren, integrieren und transformieren riesige Datenmengen. Eine Möglichkeit, um die Datenintegrität standardisiert zu testen, sind automatisierte „Quality Gates“. Sie prüfen die Daten kontinuierlich, wenn sie in die Applikation hinein und wieder herausfließen. So können Unternehmen Probleme sofort feststellen und beheben, bevor sie sich auf das Geschäft auswirken und massiven Aufwand an manueller Datenprüfung und -Reparatur verursachen.

Fazit

Niemand hat heute mehr etwas zu verschenken. Gerade in Zeiten des Fachkräftemangels und der Globalisierung ist es entscheidend, gut mit den verfügbaren Ressourcen zu haushalten. Beim Testing gibt es noch viel Optimierungspotenzial. Um weder zu viel noch zu wenig zu testen, ist es wichtig, Tests strategisch anzugehen und genau auf die Geschäftsrisiken abzustimmen. Das gilt sowohl für Eigenentwicklungen als auch für Updates von SAP-Anwendungspaketen.

Wenn es gelingt, das Richtige so effizient wie möglich zu testen, lässt sich das Pareto-Prinzip anwenden: Man erreicht mit 20 Prozent des Aufwands 80 Prozent Risikoabdeckung. Spezialisierte Anbieter von Lösungen zur Testautomatisierung können hier wertvolle Hilfestellung leisten.

* Wolfgang Platz ist Founder und Chief Strategy Officer von Tricentis.

(ID:47078238)