10 Best Practices: #2 Zuerst die Regressionstests

Im Releasezyklus einer Anwendung werden vom QA-Personal typischerweise folgende Tests durchgeführt:

• Releasespezifische Tests, um neue Features der AUT (Application under test, getestete Anwendung) zu prüfen.
• Fehlerbehebungstests, um sicherzustellen, dass gefundene Fehler behoben worden sind.
• Regressionstests, also Testfälle, die in einem früheren Releasezyklus schon erfolgreich durchlaufen wurden. Regressionstests überprüfen, ob durch Funktionalitätsänderungen neue Fehler eingeführt wurden bzw. alte Fehler wieder auftauchen. Wenn dies der Fall ist, spricht man von Regressionen, genauer z.B. von funktionalen Regressionen, die die vorgesehene Funktion des Programms betreffen, und visuellen Regressionen, die unerwartete Änderungen im Erscheinen der Anwendung betreffen.

Im ersten Blogartikel dieser Serie, Was soll man automatisieren?, haben wir Kriterien herausgearbeitet, anhand derer man erkennen kann, welche Testfälle am rentabelsten zu automatisieren sind. Testfälle, die häufig wiederholt werden, und solche für stabile Features fielen in genau diese Kategorie. Auf Regressionstests trifft beides zu. Entsprechend eignen sie sich gut dafür, als erste automatisiert zu werden. Im Folgenden stellen wir einige der Best Practices bei der Automatisierung von Regressionstests vor.

Höchste Priorität für Regressionstests mit hohem Wert

Nicht alle Regressionstests sind von gleicher Wichtigkeit. Konzentrieren Sie sich auf die folgenden Arten von Regressionstests:

Regressionstests müssen wartbar sein

Es gibt eine Reihe von Prinzipien, die die Wartbarkeit von automatisierten Tests erhöhen. Sie lassen sich auf alle automatisierten Tests anwenden, nicht nur auf Regressionstests. Ein wesentliches Prinzip ist dabei die Testerstellung nach Gesichtspunkten der Modularität und Eigenständigkeit. Lassen Sie sich nicht dazu verleiten, Code von einem Testfall in den anderen zu kopieren. Das erhöht den Wartungsaufwand. Wenn Sie Code wiederverwenden wollen, z.B. für einen Loginprozess, erstellen Sie ein eigenes Modul dafür, das Sie dann wiederverwenden. Wenn sich der Loginprozess später ändert, müssen Sie so nur noch ein Modul aktualisieren, statt den Code in jedem Testfall einzeln zu ändern. Eine weitere Best Practice ist es, die Definition von UI-Elementen von den eigentlichen Aktionen im Testfall getrennt zu halten. Sehen Sie außerdem davon ab, Testdaten direkt in den Code zu schreiben. Verweisen Sie stattdessen auf eine Tabelle oder eine Datenbank, in der Sie Ihre Testdaten verwalten. In einem späteren Artikel dieser Serie werden wir Wartbarkeit noch genauer behandeln.

Ausführen der ganzen Regressionssuite nur wenn nötig

Es ist nicht immer notwendig, die gesamte Anzahl an Regressionstests bei jedem neuen Build auszuführen. Bei einem Minor Release ist es wahrscheinlich sinnvoller, nur die Smoke Tests durchlaufen zu lassen, zuzüglich eventuelle Regressionstests für geänderte Module. Um das zu vereinfachen, sollten Sie Ihre Regressionstestfälle danach ordnen, welches Modul der AUT der Testfall abdeckt. Als Beispiel: Wenn Ihr Release nur eine Änderung am Zahlungsprozess in einem Onlineshop beinhaltet, dann kann es reichen, nur die Regressionstests für dieses Modul auszuführen. Die Regressionstests für andere Features, wie zum Beispiel Artikelsuche oder Hinzufügen von Artikeln zum Einkaufswagen, können dann übersprungen werden. Wenn ein Releasezyklus aber Änderungen in vielen Bereichen der Anwendung umfasst, wie z.B. Lokalisierung in eine andere Sprache, dann ist die Ausführung der gesamten Regressionssuite auf jeden Fall sinnvoll. Mehr zur Priorisierung von Regressionstests für einen bestimmten Releasezyklus können Sie in unserem Regression Testing Guide lesen.

Die Toolchain nutzen

Ein automatisierter Regressionstest ist und bleibt Code, also ist es nur sinnvoll, ihn auch als solchen zu behandeln und Ihre gesamte vorhandene Entwicklungsumgebung dafür zu nutzen.

Die Größe der Regressionssuite beachten

Mit jedem neuen Releasezyklus wächst eine Regressionssuite normalerweise um ein gewisse Anzahl an Testfällen. Mit der Zeit kann die Suite auf diese Weise enorm in der Größe wachsen, was auch den Ressourcenbedarf bei der Ausführung erhöht. Außerdem wird es immer schwieriger, alle Regressionstests mit jeder neuen Änderung an der Anwendung zu warten und aktualisiert zu halten. Um das zu vermeiden, sollten Sie immer die Größe Ihrer Regressionssuite im Auge behalten. Entfernen Sie bei jedem neuen Releasezyklus Testfälle, die keinen Wert für den Testprozess haben. Das sind z.B. Tests für ausgediente Features oder Tests von geringer Priorität, die die AUT konsistent erfolgreich durchläuft. Beim Hinzufügen von neuen Testfällen sollten Sie immer genau evaluieren, ob diese auch wirklich den Testprozess bereichern. Beispiele wären hierfür Testfälle, die in einem früheren Releasezyklus viele Fehler aufgedeckt haben, oder die kritische Funktionen testen.

Regressionstests haben ihre Grenzen

Wie beim Durchqueren eines Minenfelds auf einem ausgetretenen Pfad, kann Ihre Regressionssuite immer wieder erfolgreich durchlaufen, ohne neue Fehler aufzudecken. Denken Sie daran: Der Zweck von Regressionstests ist es, sicherzustellen, dass durch Funktionalitätsänderungen keine alten Fehler wieder aufgetaucht bzw. neue Fehler in vormals funktionierendem Code eingeführt worden sind. Nur weil alle Ihre Regressionstests fehlerfrei waren, heißt das nicht, dass Ihre neuen Funktionalitäten ohne Fehler laufen. Aber genau hier wird der Vorteil von automatisierten Regressionstests augenscheinlich: Sie verschaffen Ihren Testern mehr Zeit für das explorative Testen von neuen Features, um so eine bestmögliche User Experience zu garantieren.