Zum Hauptinhalt springen
Fugen Services logo

Softwareentwicklung

Tests, die Regressionen aufdecken – nicht Tests, die eine Kennzahl aufblähen

Eine Testsuite lohnt sich nur, wenn sie Sie dazu bringt, auch freitags zu deployen. Die meisten tun das nicht – aus einem von zwei Gründen: Sie testen den Code statt das Verhalten, brechen daher bei jeder Refaktorisierung und bestehen, während der Checkout defekt ist – oder sie sind so unzuverlässig, dass das Team sie immer wieder neu ausführt, bis sie grün werden.

Richtwert

Ab £4.500

Fester Preis schriftlich vereinbart, bevor mit der Entwicklung begonnen wird.

Kostenangebot anfordern+44 7488 265083

Das Problem, das damit gelöst wird

Die Kennzahl dahinter ist die Abdeckung. Wer 80 % anstrebt, produziert Hunderte Tests für triviale Funktionen und keine für die vier Pfade, die Ihr Umsatz generieren. Eine unzuverlässige Suite ist zudem aktiv schädlich: Sie trainiert das Team darauf, rote Ergebnisse zu ignorieren – schlimmer als gar keine Tests.

Was Sie erhalten

Die Pfade testen, die Geld einbringen

Registrierung, Anmeldung, Suche, Warenkorb hinzufügen, Checkout, Bezahlung, Admin-Bearbeitung. Zuerst volle End-to-End-Abdeckung dieser Pfade, bevor etwas anderes getestet wird.

Der richtige Test auf der richtigen Ebene

Unittests für Logik, Integrationstests für die Datenschicht, End-to-End nur für echte Nutzerpfade. End-to-End-Tests sind langsam und fragil; wer sie für alles einsetzt, warum Testsuites oft aufgegeben werden.

Keine Toleranz für Unzuverlässigkeit

Ein unzuverlässiger Test ist ein Fehler und wird behoben oder entfernt – nie durch erneutes Ausführen zum Erfolg gezwungen. Deterministische Wartezeiten und vordefinierte Daten statt willkürlicher Pausen.

Integration in die CI als Gate

Läuft bei jedem Pull Request und blockiert den Merge bei Fehlern. Die Laufzeit wird kurz genug gehalten, damit niemand versucht, sie zu überspringen.

Barrierefreiheit und Cross-Browser-Checks

Automatisierte axe-Prüfungen auf Schlüsselseiten sowie Tests in Chrome, Safari und Firefox. Safari-spezifische Layoutfehler sind häufig und bleiben unsichtbar, wenn nur in Chrome getestet wird.

Fehler, die sich diagnostizieren lassen

Screenshots, Videos und Traces werden bei Fehlern erfasst, sodass ein roter Build in zwei Minuten diagnostiziert werden kann – statt eines halben Nachmittags mit lokaler Reproduktion.

Wie wir arbeiten

  1. Die kritischen Pfade identifizieren

    Welche Abläufe würden Ihnen innerhalb einer Stunde Geld oder Kunden kosten, wenn sie ausfallen? Diese Liste ist der Testplan.

  2. Bestehendes bewerten

    Aktuelle Tests werden daraufhin überprüft, was sie tatsächlich überprüfen. Einige werden beibehalten, andere gelöscht – ein Test, der nicht sinnvoll fehlschlagen kann, ist schlimmer als keiner.

  3. Testumgebung aufbauen

    Testdaten-Integration, Testdaten und eine Umgebung, gegen die Tests wiederholbar laufen können.

  4. Kritische Pfade automatisieren

    Zuerst vollständige Abdeckung der priorisierten Abläufe.

  5. Pipeline absichern

    Integration in die CI mit erforderlichen Prüfungen, wobei die Testsuite schnell bleibt.

  6. Übergabe

    Ihre Entwickler schreiben Tests nach denselben Mustern, denn eine Testsuite, die nur ein Auftragnehmer wartet, stirbt, wenn dieser geht.

Was Sie erwarten sollten

  • Regressionen in umsatzkritischen Abläufen werden vor dem Release erkannt
  • Eine Testsuite, der das Team vertraut, sodass Rot bedeutet: Stopp
  • Bereitstellungen, die nicht mehr manuell durchgeklickt werden müssen
  • Fehler, die sich direkt aus der CI diagnostizieren lassen, ohne lokale Reproduktion

Erstellt mit

  • Playwright
  • Cypress
  • Vitest
  • Jest
  • PHPUnit
  • Pest
  • Testing Library
  • axe-core
  • GitHub Actions
  • Lighthouse CI
  • k6

Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.

QA & Software-Tests — your questions

Einschließlich der Fragen zu den Kosten, die die meisten Agenturen auf der Seite auslassen.

Die Automatisierung der kritischen Nutzerpfade einer typischen Webanwendung kostet £4.500 bis £12.000, abhängig von der Anzahl und davon, wie testbar die Anwendung aktuell ist. Wenn die Anwendung keine Testschnittstellen bietet, ist zunächst eine gewisse Überarbeitung nötig, die wir separat kalkulieren, statt sie zu verstecken.

Wir orientieren uns nicht an einer Prozentzahl, denn das ist der falsche Maßstab – 90 % Abdeckung ohne einen Test für den Checkout ist schlechter als 40 % mit einem solchen. Unser Ziel ist, dass jeder umsatzkritische Pfad vollständig abgedeckt ist und jeder behobene Fehler mit einem Test einhergeht, der ihn hätte erkennen können.

Playwright für neue Projekte: echte Cross-Browser-Unterstützung inklusive Safari, bessere Parallelisierung und der Trace-Viewer beschleunigen die Fehlerdiagnose deutlich. Cypress ist ein gutes Tool, und wir pflegen bestehende Cypress-Suiten weiter, statt auf eine Neuschreibung zu bestehen.

Ja. Manchmal sind kleine Änderungen nötig, um die Anwendung testbar zu machen – stabile Selektoren, eine Möglichkeit zur Datensaat oder ein Hook zur Zeitsteuerung. Diese Änderungen lohnen sich ohnehin, denn Code, der schwer zu testen ist, ist meist auch schwer zu ändern.

Ja, für explorative Tests vor einem größeren Release – ein Mensch findet Usability-Probleme, die keine Assertion erkennt. Für Regressionstests jedoch nein: dieselben manuellen Checks in jedem Release zu wiederholen, ist teuer, unzuverlässig und genau der Grund, warum wir Automatisierung einsetzen.

Sprechen Sie mit jemandem, der dies bereits entwickelt hat

A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.