Regressionstests ohne QA-Team

Die meiste Software wird von Teams ohne QA-Funktion gebaut. Es gibt keine Testingenieurin, keinen Testplan und keine Suite — nur eine Gruppe von Menschen, die ausliefert, und ein leises Bewusstsein, dass etwas kaputtgehen könnte, ohne dass es jemand merkt.

Der übliche Rat für diese Lage lautet, jemanden einzustellen oder eine Plattform einzuführen. Beides steht den meisten Teams, die die Frage stellen, nicht zur Verfügung. Auf dieser Seite geht es darum, was man stattdessen tut.

Beginnen Sie bei den Kosten, nicht bei der Abdeckung

Der Reflex ist, alles testen zu wollen, festzustellen, dass das unmöglich ist, und dann nichts zu tun. Der bessere Reflex ist, eine engere Frage zu stellen:

Wenn das still kaputtginge und eine Woche kaputt bliebe, was würde es uns kosten?

Sortieren Sie Ihre Abläufe nach der Antwort. Fast immer ragt eine kleine Zahl weit über den Rest hinaus — jene, bei denen es um Geld, Zugang oder Daten geht, die das Haus verlassen.

• Registrierung und Login. Wenn niemand hineinkommt, zählt der Rest nicht.
• Bezahlung und Kaufabschluss.
• Was auch immer den zentralen Datensatz in Ihrem Produkt anlegt — eine Bestellung, eine Buchung, ein Projekt, ein Ticket.
• Alles, was etwas an eine Kundin verschickt.
• Berechtigungen, besonders überall dort, wo ein Kunde die Daten eines anderen sehen könnte.

Diese Liste hat meist fünf bis acht Punkte. Das ist Ihre Regressionssuite. Nicht eine erste Rate davon — vorerst das Ganze.

Warum hier kleine Suiten große schlagen

Hundert Tests, die niemand pflegt, erzeugen einen dauerhaft roten Build, den innerhalb von zwei Wochen alle zu ignorieren lernen. An diesem Punkt haben Sie negativen Wert: die Pflegekosten plus das falsche Vertrauen, „eine Testsuite“ zu haben.

Acht Tests, die zuverlässig bestehen und deren Fehlschlag etwas bedeutet, werden angesehen. Das ist das ganze Spiel, wenn niemand dafür zuständig ist.

Ergänzen Sie Tests anhand von Belegen statt von Vorstellungskraft. Wenn in der Produktion etwas bricht, schreiben Sie den Test, der es abgefangen hätte. Nach einem halben Jahr haben Sie eine Suite, die von Ihren tatsächlichen Fehlerbildern geformt ist statt von Mutmaßungen.

Taktung

Ohne CI-Pipeline decken zwei Läufe den Großteil des Risikos ab:

• Ein geplanter Lauf gegen Staging, täglich. Fängt Drift ab, Änderungen bei Dritten, abgelaufene Zugangsdaten und Datenprobleme, die auftauchen, ohne dass jemand etwas ausgerollt hat.
• Ein Lauf vor jedem Release. Das Tor, auf das es ankommt.

Wenn Sie eine Pipeline haben, ist ein Lauf bei jedem Pull Request besser, und Werkzeuge, die dafür gebaut sind — mabl, Momentic, QA.tech —, werden ihren Preis wert. Ohne Pipeline ist ein Zeitplan ein völlig vernünftiger Ersatz und erheblich besser als nichts.

Zuständigkeit

Hier sterben diese Bemühungen am häufigsten. Eine Suite, für die „das Team“ zuständig ist, gehört niemandem: Ein Fehlschlag erscheint in einem geteilten Kanal, alle nehmen an, eine Kollegin schaue hin, und binnen eines Monats sind die Benachrichtigungen stummgeschaltet.

Benennen Sie eine Person. Ihre Aufgabe ist nicht, alles zu reparieren — sie ist, jeden fehlgeschlagenen Lauf anzusehen und zu entscheiden, ob es ein Bug ist, ein kaputter Test oder ein Umgebungsproblem. Eine Viertelstunde pro Woche, verlässlich erledigt, macht den Unterschied.

Wenn Tests in normaler Sprache statt in Code geschrieben sind, muss diese Person keine Entwicklerin sein, was den Kreis deutlich erweitert. Ein Product Owner oder eine Betriebsleiterin, die das Produkt versteht, kann das gut.

Ein Werkzeug für diese Lage auswählen

Die Beschränkung, auf die es ankommt, sind nicht die Funktionen. Es ist das, was das Werkzeug von Ihnen braucht, bevor es helfen kann.

Alles, was eine CI-Pipeline, ein Repository oder eine QA-Praxis voraussetzt, fällt weg — nicht weil es schlecht wäre, sondern weil Sie die Voraussetzung nicht liefern können. Das streicht sofort den größten Teil des Marktes, darunter mehrere der besten Produkte darin.

Übrig bleiben Werkzeuge, die nur eine laufende Anwendung und eine URL brauchen: Testmode, testRigor, Rainforest QA, Functionize und Autify. Die vollständige Aufschlüsselung nach Beschränkung steht in der Übersicht der KI-Testwerkzeuge.

Die andere ehrliche Option ist Playwright. Es ist kostenlos und ausgezeichnet, und wenn eine Ihrer Entwicklerinnen wirklich eine Testsuite betreuen möchte, ist das ein gutes Ergebnis. Seien Sie realistisch, ob diese Person existiert und die Zeit hat — eine verwaiste Playwright-Suite ist das häufigste Artefakt dieser ganzen Kategorie.

Ein vernünftiger erster Monat

• Woche 1. Schreiben Sie Ihre fünf teuersten Ausfälle auf. Noch keine Tests — nur die Liste.
• Woche 2. Automatisieren Sie drei davon. Drei, die laufen, schlagen acht, die halbfertig sind.
• Woche 3. Bringen Sie sie auf einen Zeitplan und richten Sie sie auf ein echtes Postfach oder einen echten Kanal. Ergänzen Sie die übrigen zwei.
• Woche 4. Benennen Sie die zuständige Person. Einigen Sie sich darauf, was passiert, wenn ein Lauf fehlschlägt — konkret genug, dass es nicht im Moment entschieden werden muss.

Das ist eine funktionierende Regressionspraxis, und dafür muss niemand eingestellt werden.