Antwort.

Manuelles Regressionstest ist der Prozess der erneuten Überprüfung bereits getesteter Funktionen des Systems nach Änderungen am Code, um sicherzustellen, dass diese Änderungen keine neuen Fehler in stabilen Teilen des Produkts verursacht haben.

Hintergrund der Frage: Zu Beginn des Softwarelebenszyklus konzentrieren sich Tester normalerweise auf die Überprüfung neuer Funktionen. Im Laufe der Zeit erfährt das System Änderungen, was das Risiko von unbeabsichtigten Regressionen erhöht. Viele Fehler in der Softwaregeschichte traten genau nach einem Fix auf, der etwas, das vorher funktionierte, "kaputt gemacht" hat, weshalb Regressionstests nach und nach zur obligatorischen Praxis wurden.

Problem: Die Hauptdilemma besteht darin, wie man bei ständigen Änderungen effizient und in kurzer Zeit die maximale Anzahl von Funktionen überprüfen kann. Wenn man die Aufgabe chaotisch oder inkonsequent angeht, kann man kritische Defekte übersehen, Fristen nicht einhalten, das Team überlasten, und manchmal werden die Überprüfungen zur Formalität.

Lösung: Für eine effektive Organisation von Regressionstests sollte man:

Ein Set stabiler, unterstützter Testfälle oder Checklisten für die Schlüsselfunktionen haben;
Diese Sets regelmäßig bei Überarbeitungen aktualisieren;
Routineaufgaben nach Möglichkeit automatisieren und für manuelle Tests kritische oder unkonventionelle Szenarien auswählen;
Die Prioritäten der Funktionen für die Überprüfung anhand von Geschäftsriskien und Häufigkeit der Änderungen abstimmen.

Wichtige Merkmale:

Regression erkennt nicht nur offensichtliche Bugs, sondern auch versteckte Fehlerketten, die mit dem Modulinteraktionen zusammenhängen.
Es ist wichtig, die Testfall-Sets regelmäßig zu überprüfen und zu priorisieren.
Die optimale Strategie besteht darin, manuelle Überprüfungen mit automatisierten dort zu kombinieren, wo dies möglich ist.

Trickfragen.

In welcher Phase ist es am besten, mit Regressionstests zu beginnen – nach allen Änderungen oder parallel zu deren Implementierung?

Viele glauben fälschlicherweise, dass Regressionstests nur nach Abschluss aller Änderungen durchgeführt werden. In der Realität ist es sinnvoller, sie zu planen und teilweise durchzuführen, während Änderungen vorgenommen werden, um schneller auf kritische Ausfälle zu reagieren.

Reicht es aus, einen Regressionstestfall einmal zu schreiben und ihn nicht mehr zu aktualisieren?

Nein, Testfälle für Regressionen erfordern eine ständige Aktualisierung: Mit Änderungen in der Geschäftslogik oder im Interface sollte das Testsystem dem Produkt folgen.

Ist Smoke-Testing ein Teil der Regression?

Nein, Smoke-Test ist eine schnelle Überprüfung offensichtlicher Ausfälle nach dem Build, während Regressionstests einen breiteren Funktionsumfang abdecken und nach Ausfällen "tiefergehend" suchen.

Typische Fehler und Anti-Patterns

Veraltete Testfälle – dadurch wird das Testen zur nutzlosen Formalität.
Ignorierung kaum wahrnehmbarer, aber wichtiger Szenarien.
Fehlende klare Priorisierung – gleichwertige Aufmerksamkeit sowohl für Schlüssel- als auch für weniger wichtige Funktionen.

Beispiel aus dem Leben

Negativer Fall

Das Team führt ein Release durch, der Tester überprüft die Funktionen formell anhand einer veralteten Liste von Testfällen und ist sich der letzten API-Änderung nicht bewusst. Ein alter Bug wird behoben, aber in einem anderen Teil des Systems tritt ein kritischer Defekt auf, den niemand vor dem Start bemerkt hat.

Vorteile:

Zeitersparnis bei der Bearbeitung von Testfällen.

Nachteile:

Hohe Wahrscheinlichkeit, wichtige Regressionen zu übersehen.
Das Vertrauen in die Qualität des Testens sinkt.

Positiver Fall

Vor dem Release haben die Tester die Regression-Checklisten aktualisiert, mit Analytikern die aktuellen Risikobereiche besprochen, die Tests auf Basis realer Szenarien priorisiert und eine manuelle Regression bei den Schlüsselabläufen durchgeführt.