Was ist Regressionstesten? Prüfen, ob die Korrektur nicht etwas anderes kaputt gemacht hat

Regressionstesten heißt zu prüfen, dass nach einer Änderung noch funktioniert, was vorher funktioniert hat. Nicht die Änderung selbst - die wird geprüft, während man sie schreibt - sondern alles ringsherum, was niemand angefasst hat und von dem niemand eine Auswirkung erwartet hat.

Der Name sagt, worum es geht. Eine Regression ist ein Schritt zurück: eine Funktion, die im letzten Release lief und in diesem nicht mehr. Diese Tests gibt es, weil Software auf Wegen zusammenhängt, die niemand im Kopf behält, und der Rabattcode, den jemand am Dienstag repariert hat, teilt sich eine Funktion mit der Steuerberechnung, die seit März niemand angesehen hat.

Warum das jemandes Aufgabe ist

Jede Änderung hat einen größeren Wirkungsradius als ihren Diff. Eine gemeinsam genutzte Funktion, eine Datenbankspalte, die an sechs Stellen gelesen wird, eine CSS-Regel, die sich für eine Seite als tragend herausstellt, die der Autor nie geöffnet hat.

Der Fehler, den das verhindert, ist konkret und teuer: ein Release, das einen gemeldeten Fehler behebt und zwei ungemeldete einführt. Die kosten weit mehr als der ursprüngliche, weil niemand nach ihnen sucht. Auf den gemeldeten Fehler hat jemand gewartet; die neuen entdecken Kunden Tage später, ohne jede Ahnung, was sich geändert hat.

Was tatsächlich erneut zu prüfen ist

Sie können nicht bei jeder Änderung alles erneut prüfen, und Teams, die es versuchen, landen bei einer Suite, die so langsam ist, dass sie übersprungen wird. Regressionstesten ist ein Auswahlproblem, und die Auswahl richtet sich nach dem Risiko.

Bei fast jeder Änderung erneut zu prüfen:

• Die Wege, die Geld bringen. Registrierung, Anmeldung, Kasse, Zahlung. Alles andere kann bis Montag warten; diese nicht.
• Was die Änderung tatsächlich berührt, dazu alles, was sich mit ihr eine Funktion, eine Tabelle oder ein Template teilt.
• Alles, was schon einmal kaputt war. Ein Defekt, der einmal zurückkam, kommt wieder, und ein Fehler mit Rückfall ist das beste Argument für einen dauerhaften Test.
• Die Integrationen, die Ihnen nicht gehören. Alles, was einen anderen Dienst erreicht, fällt aus Gründen aus, die mit Ihrem Release nichts zu tun haben.

Nicht jedes Mal lohnend: selten benutzte Einstellungsseiten, Verwaltungswerkzeuge mit zwei Nutzern, alles, dessen Ausfall jemand ohne Schaden bemerken und melden würde.

Wo der Smoke Test endet und das hier beginnt

Sie werden zu verschiedenen Zeitpunkten gestellt und beantworten verschiedene Fragen.

Smoke Test

Ist dieser Build überhaupt das Testen wert? Fünf Prüfungen, Minuten, zuerst ausgeführt, bei jedem Build

Regressionstest

Hat etwas aufgehört zu funktionieren, das vorher funktionierte? Hunderte Prüfungen, länger, ausgeführt sobald der Build sich bewährt hat

Eine Regressionssuite gegen einen Build laufen zu lassen, der keinen Benutzer anmelden kann, verschwendet eine Stunde damit, genau das auf vierhundert Arten zu beweisen. Der Smoke Test kommt genau deshalb zuerst.

Von Hand oder automatisiert

Automatisierung ist die naheliegende Antwort und die unvollständige.

Automatisieren Sie, was stabil, wertvoll und stumpfsinnig ist: die Geldwege, die API-Verträge, die Berechnungen mit bekannten Eingaben und bekannten Ergebnissen. Die lohnt es einmal zu schreiben und für immer laufen zu lassen, und das sind die Tests, die eine Regression um drei Uhr morgens fangen, ohne dass jemand zusieht.

Behalten Sie einen Menschen für das, was ein Skript nicht beurteilen kann. Ob das Layout falsch ist und nicht bloß anders. Ob eine Fehlermeldung Sinn ergibt. Ob sich der Ablauf noch anfühlt, als funktioniere er. Ein Screenshot-Vergleich sagt Ihnen, dass sich elf Pixel bewegt haben; er sagt Ihnen nicht, dass der Button auf dem häufigsten Laptop Ihrer Nutzerschaft jetzt unterhalb des sichtbaren Bereichs liegt.

Die meisten Teams landen bei einer automatisierten Suite für die Wege, die nicht brechen dürfen, und einem kurzen manuellen Durchgang für die Bereiche, die das Release berührt hat.

Wie eine Suite verkommt

Auf drei Arten, alle drei häufig, und jede endet damit, dass die Suite ignoriert wird.

Sie wird langsam. Eine Suite, die neunzig Minuten braucht, läuft nachts statt bei jeder Änderung, und auf einer Regression, die am nächsten Morgen gefunden wird, ist schon weitergebaut worden.

Sie wird unzuverlässig. Ein Test, der in einem von zehn Läufen fehlschlägt, bringt allen bei, ihn neu zu starten, und die Gewohnheit des Neustarts ist nicht davon zu unterscheiden, den Test nicht zu haben. Eine wirklich kaputte Sache versteckt sich im Rauschen der bloß unzuverlässigen.

Sie wächst nur. Für jeden Defekt kommen Tests dazu und für nichts kommen welche weg, bis die Hälfte der Suite Verhalten abdeckt, das das Produkt nicht mehr hat. Tests zu löschen gehört zu ihrer Pflege.

Wenn eine Regression auftaucht

Ein fehlgeschlagener Regressionstest ist ein Fehlerbericht, der noch geschrieben werden muss, und er beginnt mit mehr Informationen, als die meisten Berichte je bekommen: Sie wissen, dass es vorher funktioniert hat, und oft genau, in welchem Release es aufgehört hat.

Sagen Sie das. “Lief in 4.2.0, fällt in 4.3.0 aus” macht aus einer Untersuchung einen Diff. Es ist der nützlichste Satz in einem Regressionsbericht und der, der am häufigsten fehlt, weil die schreibende Person annimmt, das wüssten alle.

Bei einer Regression, auf die jemand von Hand stößt, statt einer, die die Suite gefangen hat, ist der Kontext das, was meistens fehlt.

Was ein guter Bericht sonst noch braucht, steht im Leitfaden für Fehlerberichte, und seine Vorlage hat eine Zeile für die Version, die funktioniert hat.

Die kurze Fassung

Regressionstesten fragt, ob die Änderung, die Sie gemacht haben, etwas kaputt gemacht hat, das Sie nicht gemacht haben. Wählen Sie nach Risiko statt nach Ehrgeiz, was erneut zu prüfen ist, stellen Sie die Geldwege unter Automatisierung, behalten Sie einen Menschen für die Urteile, die ein Skript nicht fällen kann, und löschen Sie Tests so bereitwillig, wie Sie welche hinzufügen. Wenn Sie eine finden, nennen Sie das Release, in dem sie zuletzt funktioniert hat.