Nach einer Softwarelieferung führen die Tester die automatisierten Testfälle aus. Das sollte doch komplett vollautomatisch laufen und kaum Aufwand generieren. Und dennoch haben Sie den Eindruck, dass auch Tage nach der Ausführung noch an der Testausführung gearbeitet wird. Was machen die Tester eigentlich und sollte das wirklich so lange dauern? Wie kann man diese Zeit reduzieren?

Das Gute daran ist: Die Aufwände sind messbar und erklärbar. Es ist möglich, die Ursachen dieser Aufwände zu reduzieren oder bestenfalls gänzlich zu beseitigen. Weiter unten finden Sie ein Kundenbeispiel das aufzeigt, welche Massnahmen geholfen haben.

Es gibt verschiedene Möglichkeiten, die Stabilität der automatisierten Testfälle zu messen. Wir stellen zwei gängige Metriken vor und wagen eine Einteilung, in welchem Bereich sich Ihre Automatisierung befindet. Bei regelmässiger Anwendung der Metriken können Sie messen, ob Ihre Testautomatisierung durch die eingeleiteten Massnahmen stabiler wird.

Metrik 1: False-Negative-Rate

Sie lassen Ihre automatisierten Systemtests laufen (vorzugsweise über Nacht) und prüfen am nächsten Morgen, wie viele davon erfolgreich durchgelaufen sind. Bei wie vielen Prozent sind Sie? 60% oder doch eher 80% oder sogar 90%?

Warum sind nicht alle Testfälle erfolgreich durchgelaufen? Sie haben sicherlich einige Bugs entdeckt oder sind auf Änderungen in der Software gestossen, die vom Fach in Auftrag gegeben wurden. Dies erklärt einen Teil der fehlgeschlagenen Testfälle. Der andere Teil der fehlgeschlagenen Testfälle, dividiert durch die Gesamtheit der Testfälle, bezeichnen wir als ‹False-Negative-Rate›. Hier ein paar Gründe, warum Testfälle fehlschlagen können, obwohl weder Bug noch fachliche Änderung die Ursache dafür sind:

• Technische Änderungen
• Die technische ID einzelner Felder hat sich verändert.
• Testdaten
• Testdaten wurden nicht korrekt aufbereitet.
• Qualität der automatisierten Testfälle
• Testfälle wurden nicht fertig oder nur unsauber implementiert.
• Es gibt Abhängigkeiten zwischen Testfällen und die Ausführungsreihenfolge war inkorrekt.
• Es wurden Änderungen in Testfall-Templates vorgenommen, die mehr Testfälle beeinflusst haben als beabsichtigt.
• Ein Testfall benutzt statische Waits und die Geschwindigkeit der Testumgebung ist nicht bei jeder Ausführung identisch.
• Störeinflüsse der Testumgebung/Infrastruktur
• Die Testumgebung war bei der Testausführung nicht oder nur teilweise erreichbar.
• Der ausführende Testagent ist ausgefallen oder lieferte falsche Ergebnisse.
• Batch-Prozesse (zum Beispiel Tagesendverarbeitung) liefen während der Testphase.

Wir können diese Störfaktoren reduzieren oder bestenfalls gänzlich beseitigen.

Wie viele dieser Testfälle besitzen Sie anteilsmässig? Der Testreport von Tricentis wagt eine Einteilung :

Link zu Testreport

Diese Zahlen klingen sehr hoch. Wir bezeichen ein automatisiertes Testset erst stabil, wenn wir uns im obersten Quartil aufhalten. Sind Sie bereits da? Gratuliere! Falls nein, können wir Ihnen gerne Hilfe anbieten, dorthin zu gelangen.

Metrik 2: Ausführungsrate

Sie führen das komplette, automatisierte Systemtestset aus. Anschliessend werden die fehlgeschlagenen Testfälle analysiert und Bugs geloggt. Sobald dieser Prozess abgeschlossen ist, stoppen wir die Uhr. Wie viele Arbeitsstunden oder Tage haben Sie aufgewendet? Und wie viele Testfälle besitzen Sie? Die Anzahl Testfälle geteilt durch den manuellen Aufwand, diese auszuführen, bezeichnen wir als Ausführungsrate. Sie ist auch ein Mass dafür, wie viel manuellen Aufwand Sie für die Nachbereitung der Testausführung benötigen.

Sie können diese Metrik anwenden und prüfen, ob Sie sich im Lauf der Zeit verbessern. Die Ausführungsrate ist von vielen Faktoren abhängig und ist nur bedingt zwischen unterschiedlichen Projekten vergleichbar. Sie kann auch angewendet werden, um den Wert der Testautomatisierung aufzuzeigen.

Welche Aussagen lässt die Ausführungsrate zu?

Eine hohe Ausführungsrate bedeutet tendenziell:

• Stabile Testautomatisierung (tiefe False-Negative-Rate)
• Effizientes Testteam
• Hohe Softwarequalität
• Testfälle könnten eine tiefe Testabdeckung aufweisen
• Der Aufwand für die manuelle Nachbereitung ist gering.
• Die Testumgebung ist eher stabil.

Ein Kundenbeispiel

Bei einem Kunden haben wir Anfang 2022 diese beiden Metriken angewendet. Der Kunde hat rund 1200 automatisierte Regressionstestfälle und benutzt die Bankensoftware Avaloq mit dem Automatisierungstool Tosca. Ende 2021 haben wir einige Änderungen durchgeführt, namentlich:

• Tosca-Upgrade auf Version 14.2
• Testdatenerstellung via Datenbankeintrag statt über das User Interface (mit unserem Produkt: TAMI ). Zusätzlich: Umstellung auf das neue Testdatensystem TDS (statt TDM).
• Umstellung einiger Tosca Classic-Module auf TBox-Module (mit unserem Modulmigrations-Service).

Zugegeben, das sind viele Änderungen auf einmal. Allerdings waren alle Änderungen notwendig, um technische Schulden abzubauen und die Automatisierung langfristig auf die nächste Stufe zu heben, beispielsweise mit einer schnelleren Testausführung. Anschliessend haben wir für das kommende Release nach Softwareänderungen zwei Testläufe durchgeführt.

Testlauf 1:

False-Negative-Rate: 38%. Ausführungsrate: 80 Testfälle pro Arbeitstag. Ups, das muss sich verbessern! Folgende Änderungen haben wir vorgenommen:

• Testdaten
• Die Testdaten wurden nicht korrekt aufgesetzt. Das Ausstellungsland der Identifikation hat gefehlt. Dies führte zu Fehlern bei der Testausführung und wurde korrigiert.
• Einige Testfälle haben keine synthetischen Testdaten verwendet und die Kundenkonstellation hat sich seit der letzten Ausführung geändert. Diese Testfälle haben wir auf synthetische Testdaten umgestellt.
• Es wurden nicht genügend Testdaten angelegt. Die Anzahl wurde für den nächsten Testlauf erhöht.
• Qualität der automatisierten Testfälle
• Die Testfälle mussten besser auf die neu erstellten Testdaten abgestimmt werden.
• Einige Classic-Module lassen sich nicht via verteilte Ausführung ausführen und müssen zu TBox-Modulen migriert werden (z.B. das Modul ‹TC String Operations›)
• Es gab Abhängigkeiten zwischen Testfällen und die Ausführungsreihenfolge war nicht korrekt. Die Abhängigkeiten wurden reduziert oder aufgelöst.
• Infrastruktur
• Testagenten haben die Testfälle nicht korrekt ausgeführt, weil der Laufwerkzugriff verloren ging. Dieses Laufwerk war neu zu mappen, was neu Teil der Testvorbereitungen ist.
• Es wurden fälschlicherweise nicht alle Testfälle via verteilte Ausführung durchgeführt. Die nicht ausgeführten Testfälle wurden zur relevanten Liste hinzugefügt.
• Die Testumgebung war temporär nicht oder nur teilweise verfügbar.

Testlauf 2:

False-Negative-Rate: 17%. Ausführungsrate: 100 Testfälle pro Arbeitstag. Schon besser, aber da liegt noch mehr drin.

• Testdaten
• Anpassung der Testdatenerstellung. Die Kundenberater des Testkunden wurden nicht immer korrekt hinzugefügt. Der Erstellungsprozess wurde optimiert.
• Qualität der automatisierten Testfälle
• Einige Classic-Module lassen sich nicht via verteilte Ausführung durchführen und müssen zu TBox-Modulen migriert werden (dies ist ein längerer Prozess).
• Wegen der Erstellung neuer Testfälle wurden Testfall-Templates angepasst, was leider den Ablauf bestehender Testfälle fälschlicherweise verändert hat. Dies musste korrigiert werden.
• Infrastruktur
• Die Suitability-Engine lief während der Testausführung nicht korrekt. Nächstes Mal werden wir dies vorgängig kontrollieren.
• Die Testumgebung war temporär nicht oder nur teilweise verfügbar.
• Die Loginmaske zur Applikation war für wenige Sekunden nicht erreichbar. Wir haben Recovery-Szenarien eingebaut, sodass nach kurzer Zeit ein erneuter Loginversuch stattfindet, bevor der Test abgebrochen wird.

Unsere Arbeit ist hier noch nicht abgeschlossen. Wir werden dranbleiben und die Testfälle weiter stabilisieren. Wir möchten eine False-Negative-Rate von unter 5% erreichen.

Und noch etwas:

Die Qualitätssicherung besteht nicht nur aus der Testautomatisierung und sollte in den kompletten Projektprozess einbezogen werden. Wir können Ihnen mit einem Test Assessment gerne aufzeigen, wo Ihre Testorganisation steht.

Mehr über Test Assessment erfahren

Nach einem dreistündigen Workshop schicken wir Ihnen einen individualisierten Report mit Vorschlägen für die nächsten Schritte. Es empfiehlt sich, dieses Assessment anschliessend alle 3–6 Monate zu wiederholen, um den Fortschritt zu messen und auch die Fokusthemen entsprechend anzupassen. Und es wird noch besser: Für Neukunden bietet wir das erste Test Assessment kostenlos an!