Wolfgang Platz: Enterprise Continuous Testing im Handumdrehen durchführen

Wolfgang Platz war kürzlich als Sprecher beim SKILUp Day: Continuous Testing zu Gast – einer der vielen großartigen Veranstaltungen des DevOps Institute, mit dem wir regen freundschaftlichen Kontakt pflegen. In ungezwungener Atmosphäre erläuterte er hier die Schlüsselelemente von Continuous Testing und wie sich die Rolle und Praxis von Continuous Testing weiterentwickelt.

Die Aufzeichnung des Vortrags finden Sie hier:

 
Hinweis: Sie können das Buch “Enterprise Continuous Testing” von Wolfgang Platz jetzt auf der Tricentis-Website oder bei Amazon herunterladen.

Im Folgenden finden Sie einige Kernaussagen aus seinem Vortrag:

Um die Effizienz beim Testen zu steigern, ist es wichtiger, sich auf die „richtigen“ Testfälle zu konzentrieren, als sich um die Optimierung der Automatisierung zu kümmern.

 
Es gibt zwei Hauptgründe für das Testen: 1) um Fehler zu finden 2) um sicherzustellen, dass die Anwendung fehlerfrei ist. Exploratives Testing ist dabei der beste Weg, um Fehler aufzuspüren. Mit spezifikationsbasiertem Testing lässt sich dagegen prüfen, ob die Anwendung intakt ist.

 
Normalerweise gibt es eine Diskrepanz zwischen dem, was zuvor spezifiziert wurde, und dem, was die Entwickler dann tatsächlich implementieren. Exploratives Testing ist hier die einzige Möglichkeit, Probleme bei Funktionalitäten zu entdecken, die zwar implementiert, aber zuvor nicht spezifiziert wurden. Spezifikationsbasiertes Testing ist hingegen die einzige Methode, Fehler in der Funktionalität zu finden, wenn diese zwar spezifiziert, aber schlussendlich nicht implementiert wurde. Ist beides der Fall – wenn die Funktionalität sowohl spezifiziert als auch implementiert wurde, eignet sich exploratives Testing am besten zur Fehleranalyse.

 
Die meisten Testberichte geben Ihnen nicht genug Informationen, um eine fundierte Entscheidung für oder gegen ein Release zu treffen. Sie melden ausschließlich die Anzahl der bestandenen, fehlgeschlagenen oder nicht ausgeführten Tests. Die Information, dass zum Beispiel zehn Prozent der Tests fehlgeschlagen sind, ist jedoch nicht besonders hilfreich. Die betroffenen Tests könnten trivial sein – oder eben auch Showstopper. Hier sind also weitere Untersuchungen erforderlich.

 
Um die Gefahren, die mit einem Release verbundenen sind, schnell und genau einzuschätzen, brauchen wir eine neue „Währung“ für das Testing: Eine Einheit, die angibt, welcher Prozentsatz an Geschäftsrisiken mit den Tests abgedeckt ist. Wenn Sie wissen, wo Ihre Hauptrisiken liegen und Sie für diese strategisch Tests erstellen, können Sie tatsächlich rund 80 Prozent Ihrer Risiken mit rund 20 Prozent des Aufwands abdecken.

 
Wenn sich Software-Tester nur auf ihre Intuition verlassen, erreichen sie meist nicht mehr als rund 50 Prozent Risikoabdeckung. Abhilfe schafft Test Case Design. Es hilft Ihnen dabei, Tests zu erstellen, mit denen Sie das Zielniveau von zum Beispiel 90 bis 95 Prozent Geschäftsrisikoabdeckung Ihrer Organisation erreichen können. Außerdem erfahren Sie durch Change-Impact-Analysen, welche Tests Sie durchführen müssen, um jede Änderung und jedes Release zuverlässig zu überprüfen.

 
Bevor Unternehmen mit der Testautomatisierung beginnen, haben sie in der Regel wenige Unit-Tests, einige Integrations- und Systemintegrationstests sowie viele End-to-End-Tests im Einsatz. Letztere werden in der Regel manuell erledigt und verursachen dadurch extrem hohe Kosten, da sie sehr langsam ausgeführt werden und so Verzögerungen bei der Fehlersuche und -behebung entstehen. Dies gilt es, umzukehren.

 
Die agile Testpyramide ist genau umgekehrt aufgebaut: Sie sollte aus einer soliden Basis an Unit-Tests, einigen Integrations- und Systemintegrationstests und nur einem sehr kleinen Anteil an End-to-End-Tests bestehen. Zudem gilt: Auch wenn Sie hier so viel wie möglich automatisieren wollen, sollten viele End-to-End-Tests sowie einige Systemintegrationstests und ein paar wenige Integrationstests immer noch manuell durchgeführt werden.

 
Über Unit-Testing hinaus sollten Sie zwei Arten der Automatisierung in Betracht ziehen: UI und API. Wenn die Funktionalität, die Sie testen müssen, über eine API zugänglich ist, sollten Sie versuchen, den Großteil Ihrer Tests auf dieser Ebene durchzuführen. API-Tests können früher im Entwicklungsprozess starten, da Sie nicht auf die Implementierung der Benutzeroberfläche warten müssen. Außerdem sind API-Tests grundsätzlich schneller zu erstellen, auszuführen und zu warten/aktualisieren.

 
Die jüngsten Entwicklungen im Bereich KI/ML beseitigen viele Hürden, die die UI-Testautomatisierung schon seit jeher behindern – insbesondere, dass automatisierte UI-Tests zu spät stattfinden und unzuverlässig sind. Mit Technologien wie Tricentis Vision AI können Sie mit der Erstellung der UI-Testautomatisierung beginnen, noch bevor eine Benutzeroberfläche existiert. Es spielt keine Rolle, welche Technologie hinter der Anwendung steckt. Es gilt: Wenn Sie es sehen können, können Sie es auch automatisieren – und zwar mit hochgradig belastbaren Tests. Mit dieser Änderung wird sich die UI-Testautomatisierung weiter durchsetzen und damit auch manuelle Tests und API-Tests immer mehr ablösen. In der Zukunft könnte sie sich sogar als gängige Methode im Bereich Automatisierung etablieren.