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:

smoke tests

Smoke-Tests

Diese Tests stellen sicher, dass die Grundfunktionalität nach einem neuen Build der AUT gegeben ist. Sie überprüfen, ob die Anwendung startet und einfache Funktionen wie Einloggen, Anzeigen des Willkommensbildschirms, Datenaktualisierung usw. korrekt ausführt. Es ist Best Practice, Smoke-Tests zu automatisieren, sodass sie bei jedem neuen Build getriggert werden. So wissen Sie sofort, ob Ihr Build solide ist, bevor Sie weitere Ressourcen in Tests investieren.
smoke tests

Sanity-Tests

Diese Tests unterziehen die kritischsten Funktionen Ihrer Anwendung einer tiefgehenden Überprüfung. Bei einer Webshopanwendung würde ein Sanity-Test bspw. prüfen, ob Kunden sich einloggen, nach einem Artikel suchen, ihn zum Einkaufswagen hinzufügen und zur Kasse gehen können. Richten Sie Ihre Sanity-Tests auf Funktionen mit höchster Priorität, geänderte Funktionen oder Module und die meistgenutzten Workflows aus.

smoke tests

Testfälle, die Fehler aufgedeckt haben

Nehmen Sie Tests in Ihre Regressionstests mit auf, die in früheren Releasezyklen eine große Anzahl an Fehlern aufgedeckt haben. So erhöhen Sie die Chance, dass Sie neue Fehler entdecken, oder alte, die erneut auftreten.

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.

Source control

Source Control

Der Zweck von Source-Control-Systemen wie Git oder Subversion besteht darin, mehreren Entwicklern das Arbeiten an derselben Anwendung zu erlauben, ohne die Änderungen des anderen ungewollt zu überschreiben. Mit Source Control können Sie aber auch die Version Ihrer Regressionssuite an die entsprechende Version der Anwendung binden.

smoke tests

Integration mit CI-Prozessen

Wenn Ihr Entwicklungsteam mit Continuous Integration arbeitet, sollten Sie auch Ihre Regressionstests darin integrieren. Das ermöglicht es, die Regressionstests automatisch bei jedem neuen Build zu triggern.
smoke tests

Integration mit Fehlermanagementtools

Fehlermanagementtools wie Jira oder Bugzilla sind essentiell, um Fehler zu dokumentieren und sie bis zur Behebung zu verfolgen und zu treiben. Am effektivsten ist es, wenn Sie Ihre Regressionstests so konfigurieren, dass Sie Fehler automatisch an das Fehlermanagementtool weitergeben. Auch für manuelle Tests und die dabei entdeckten Fehler sollten Sie solche Tools verwenden. Die Dokumentation dieser „manuellen Fehler“ kann für die Erstellung von zukünftigen Regressionstests herangezogen werden.

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.