Was es wirklich kostet, Ihren Onlineshop nicht zu testen

Es gibt ein Gespräch, das wir bei Kiwee immer wieder mit E-Commerce-Teams führen, und es beginnt fast immer gleich. Der Shop läuft, die Plugins funktionieren, Bestellungen gehen ein. Steht ein Release an, klickt sich jemand aus dem Entwicklungsteam einmal durch den Checkout, alles sieht gut aus, und das Update geht live. Warum also Zeit in automatisierte Tests investieren?

Manuelles Testen hat versteckte Kosten

Die Frage ist berechtigt, aber die meisten Teams betrachten Tests falsch: als zusätzlichen Kostenpunkt. Manuelles Testen ist nicht kostenlos, es fühlt sich nur so an, weil die Kosten später anfallen und auf keiner Rechnung stehen. Wenn Sie ein Plugin oder eine individuelle Schnittstelle ohne automatisierte Tests ausliefern, sparen Sie diese Kosten nicht. Sie bezahlen sie nur auf andere Weise.

Irgendwann ändert sich immer etwas: ein Shopware-Update, eine aktualisierte Abhängigkeit, ein Payment-Provider, der seine API anpasst. Dann muss sich jemand erneut durch dieselben Abläufe klicken, um sicherzugehen, dass nichts kaputtgegangen ist. Das kostet echte Zeit, und Zeit ist in fast jedem Projekt der teuerste Faktor. Da KI inzwischen mehr Code produziert, als ein Team jemals von Hand schreiben könnte, steigen diese Kosten für manuelle Prüfungen weiter.

Releases ohne CI/CD-Pipeline: ein halber Tag Handarbeit

In vielen Onlineshops läuft ein größeres Plattform-Update ungefähr so ab: Sie blocken einen halben Tag, erstellen ein Backup und sichern die alten Dateien an einem separaten Ort, falls ein Rollback nötig wird. Dann spielen Sie das Update ein, arbeiten manuell eine Checkliste ab, deaktivieren den Wartungsmodus, testen noch einmal und hoffen, dass nichts durchgerutscht ist.

Jedes Release ist ein manueller Prozess mit vielen Einzelschritten und einem echten Risiko.

Mit einer sauberen CI/CD-Pipeline fällt dieser manuelle Aufwand weg und mit ihm der größte Teil der Fehlerquellen. Sie setzen einen Git-Tag, das Deployment startet, der Wartungsmodus wird automatisch aktiviert, fertig. Aus einem halben Tag wird etwa eine halbe Stunde, mit vielleicht zehn Minuten tatsächlicher Ausfallzeit für Ihre Kunden. Der größere Gewinn ist aber die Verlässlichkeit: Der Prozess läuft jedes Mal gleich ab. Sie müssen also nicht vor jedem Release rätseln, was diesmal schiefgehen könnte.

Das macht nicht nur dem Entwicklungsteam das Leben leichter. Viel wichtiger ist, dass es die Betriebssicherheit Ihres Unternehmens erhöht. Wenn ein Release vom Stresstermin zur Routine wird, veröffentlichen Teams häufiger und mit mehr Sicherheit.

Die Testpyramide: drei Ebenen automatisierter Tests

Automatisierte Tests werden oft als Pyramide dargestellt, die aus drei Ebenen besteht:

• Unit-Tests prüfen kleine, isolierte Teile der Programmlogik. Sie sind schnell, Hunderte davon laufen in wenigen Sekunden durch, und sie bilden das Fundament einer soliden Testsuite. Wandelt Ihr Shop zum Beispiel Bestelldaten in das Format um, das Ihr ERP-System erwartet, stellen Unit-Tests sicher, dass diese Umwandlung auch dann korrekt funktioniert, wenn sich die Plattform darunter verändert.

• Integrationstests prüfen, ob die verschiedenen Teile des Systems richtig zusammenspielen: ob ein Rabattcode im Checkout den Preis tatsächlich korrekt reduziert, ob eine Zahlungsbestätigung vom Payment-Gateway den Bestellstatus aktualisiert und ob der Lagerbestand nach einem Verkauf zurück in den Shop synchronisiert wird.

• End-to-End-Tests simulieren eine echte Kundensitzung im Browser: ein Produkt suchen, in den Warenkorb legen, den Checkout durchlaufen, die Bestellung abschließen. Diese Tests sind in der Pflege am aufwendigsten. Konzentrieren Sie sie deshalb auf die kritischen Pfade, also auf die Stellen, an denen ein Fehler direkt Umsatz kostet.

Eine gesunde Testsuite besteht aus vielen Unit-Tests, einer angemessenen Zahl an Integrationstests und einer kleineren, gezielt ausgewählten Gruppe von End-to-End-Tests für die kritischen Abläufe, die auf keinen Fall ausfallen dürfen.

Bestehendes Projekt ohne Tests: Wo fangen Sie an?

Bei einer großen, über Jahre gewachsenen Codebasis mit viel technischer Schuld ist es schwer, den richtigen Einstieg zu finden. Vielleicht denken Sie, Sie müssten erst jede Zeile Code testen, bevor Sie gefahrlos weiterarbeiten können. So funktioniert das in der Praxis aber nicht, und es wäre auch nicht der sinnvollste Einsatz Ihrer Zeit.

Bei bestehenden Projekten fangen Sie am besten oben an: zuerst End-to-End-Tests für Ihre kritischsten Abläufe.

• Können Kunden ein Konto anlegen und sich wieder anmelden?
• Finden Kunden Produkte über Navigation und Suche?
• Können sie Produkte in den Warenkorb legen und den Checkout abschließen?
• Kommen Bestellungen korrekt in Ihrem ERP-System an?

Sichern Sie diese Abläufe zuerst ab. Danach arbeiten Sie sich nach unten vor: Integrationstests für Ihre externen Schnittstellen, Unit-Tests für die Logik, von der diese Schnittstellen abhängen. Sorgen Sie außerdem dafür, dass jeder neue Code von Anfang an getestet wird. So wächst die Testabdeckung mit der Zeit ganz von selbst.

Speziell für neue Features lohnt sich ein Blick auf testgetriebene Entwicklung (Test-Driven Development, TDD). Wer den Test vor dem Code schreibt, muss vorher klar definieren, was der Code eigentlich leisten soll. Die Tests werden so zur Spezifikation, die der Code erfüllen muss. Besonders wertvoll wird dieser Ansatz in Zeiten KI-gestützter Entwicklung. Dazu gleich mehr.

Wie KI das Testen verändert hat

Mit dem Aufkommen von KI-Coding-Agenten haben sich technische Schulden grundlegend verändert. Es geht nicht mehr nur um langsam entstehenden, von Menschen geschriebenen Code, sondern um technische Schulden im Maschinentempo. KI-Agenten entwickeln Features und setzen Änderungen in einem bisher unerreichten Tempo um. Für die Produktivität klingt das nach einem Traum. Allerdings erzeugen diese Agenten auch gern unsichere Muster oder Code, der in sich logisch ist, architektonisch aber nicht trägt.

Wenn Ihre Teststrategie noch auf manueller Prüfung basiert, sind Sie jetzt der Engpass. Ohne eine konsequente, automatisierte Testsuite lassen Sie im Grunde eine Maschine ungeprüften Code in die Produktion schieben, und zwar in einem Tempo, mit dem kein menschliches Team mithalten kann. In einem Workflow, in dem bis zu 100 % des Codes von KI stammen, sind automatisierte Tests die entscheidende Leitplanke. Sie sorgen dafür, dass der Geschwindigkeitsgewinn durch KI-Agenten nicht auf Kosten der Stabilität geht.

Diese Leitplanke hält aber nur, wenn die Tests selbst vertrauenswürdig sind. Das Problem: Oft sind auch die Tests KI-generiert. Und KI-generierte Tests sehen gern nach Testabdeckung aus, ohne tatsächlich welche zu liefern. Bitten Sie ein Modell, Tests für eine Funktion zu schreiben, prüft es häufig den Happy Path, also den Idealfall ohne Fehler, gründlich und betrachtet die Aufgabe damit als erledigt.

Schlimmer noch: Es testet unter Umständen, was der Code tut, statt was er tun soll. Enthält der Code einen Bug, kann der Test diesen Fehler sogar festschreiben, indem er das fehlerhafte Ergebnis als korrekt definiert. Eine grüne Testsuite, die so entstanden ist, beweist nur, dass sich das Modell selbst auf die Schulter geklopft hat. Sie zeigt, dass der Code mit sich selbst übereinstimmt, aber nicht, dass er richtig ist.

Testing und Code-Review im KI-Zeitalter

Das heißt nicht, dass Sie auf KI-generierte Tests verzichten sollten. KI ist wirklich gut darin, Testdateien aufzusetzen, Edge Cases zu finden, die Entwickler übersehen könnten, und den Boilerplate-Code zu übernehmen, der viele überhaupt erst vom Testen abhält. Wir müssen nur noch genauer auf saubere Tests und konsequente Code-Reviews achten.

Bei der Menge an KI-generiertem Code und der kognitiven Überlastung, die damit einhergeht, ist es unmöglich, Code so detailliert zu prüfen wie früher. Erschwerend kommt hinzu, dass KI Code schreibt, der richtig aussieht: saubere Formatierung, sinnvolle Variablennamen, eine Struktur, wie man sie von erfahrenen Entwicklern erwartet. Das kann beim Review ein trügerisches Gefühl von Sicherheit erzeugen. Deshalb verdienen beim Review von Änderungen vor allem die Tests Ihre Aufmerksamkeit. Wir sagen gern, dass Tests die beste Dokumentation sind, und das gilt heute mehr denn je. Wer die generierten Tests nicht sorgfältig liest, weiß nicht wirklich, was am Ende ausgeliefert wird.

Deshalb gewinnt auch spec-driven development, also spezifikationsgetriebene Entwicklung, an Bedeutung. Eine konkrete Feature-Spezifikation war schon immer wichtig. Aber wir kennen die Realität: Projekte, in denen Features nie wirklich sauber definiert wurden und Teams sich auf ungeschriebene Regeln verlassen, die „einfach jeder kennt“. Mit KI funktioniert das leider nicht. Anders als Menschen kennt KI weder den geschäftlichen Kontext noch frühere Entscheidungen oder die Gründe hinter einer kundenspezifischen Ausnahme.

Es lohnt sich also, deutlich mehr Aufwand in detaillierte, gut strukturierte Anforderungen zu stecken, auch wenn manche davon selbstverständlich erscheinen. Gelingt Ihnen das, bekommen Sie die E2E-Testszenarien quasi gratis dazu, und die KI kann Ihnen die Arbeit abnehmen, daraus echten Testcode zu machen.

Codequalität bei KI-generiertem Code

Es gibt noch weitere Qualitätsrisiken: ein Codestil, der von Datei zu Datei variiert, unnötig komplizierte Lösungen, Muster aus den Trainingsdaten, die nicht zu Ihrem Projekt passen, oder Abhängigkeiten, die nicht ganz zum Rest des Projekts passen.

Neu ist davon nichts. Es sind dieselben Probleme, die jedes Team mit lockeren Konventionen schon immer hatte. KI lässt sie nur schneller entstehen. Auch die Lösungen sind bekannt:

• Linter und Formatter, die Abweichungen im Codestil automatisch erkennen.
• Statische Codeanalyse und Typprüfung, die genau die Fehler aufdecken, die sich in „korrekt aussehendem“ Code gern verstecken.
• Dependency- und Security-Scans, die bekannte Sicherheitslücken in der Version finden, die die KI gerade vorschlägt.

Dahinter steht die Idee der sogenannten maintainability sensors: Keines dieser Tools ist neu. Neu ist, wie wir sie in unseren Workflow einbinden. Statt sie erst beim Commit, beim Push oder beim Erstellen eines Pull Requests laufen zu lassen, sollten wir sie direkt in die Coding-Session der KI einbauen. So bekommt die KI eine Feedbackschleife, auf die sie noch während der Arbeit reagieren kann.

Allerdings erkennen Sensoren nicht alles. Für überkomplizierte Lösungen gibt es zum Beispiel keinen Sensor. Hier braucht es ein menschliches Review, das wirklich liest, was implementiert wird, und nicht nur prüft, ob alle Checks bestanden sind. Kein Tool ersetzt Reviewer, die die Codebasis gut genug kennen, um zu erkennen, wenn ein einfaches Problem eine unnötig aufwendige Lösung bekommen hat.

Wenn trotzdem ein Bug auftaucht

Tests machen Software nicht fehlerfrei. Sie verändern aber, wie Sie auf Fehler reagieren und wie viele davon zurückkommen.

Wird ein Bug gefunden, sind zwei Schritte richtig: ihn beheben und einen Test schreiben, der genau diesen Fall abdeckt. Und zwar inklusive des Edge Cases, der den Fehler verursacht hat, nicht nur des Happy Path, in dem alles wie erwartet funktioniert.

Jeder Bug, für den es einen Test gibt, kann nicht Monate später unbemerkt zurückkehren, wenn jemand eine Abhängigkeit aktualisiert. Mit der Zeit summiert sich das. Die Testsuite wächst nicht nur mit neuen Features, sondern mit jedem Problem, das Sie gelöst haben. Die Codebasis wird Schritt für Schritt robuster gegen versehentliche Fehler. Nicht, weil sie perfekt ist, sondern weil ein wachsendes Sicherheitsnetz darunter liegt.

Ist Ihr Release-Prozess der Engpass?

Tests haben einen Vorteil, der in keiner Rechnung zur Zeitersparnis sauber auftaucht, in der Praxis aber wahrscheinlich der wichtigste ist.

Ohne Tests beruhen Releases auf einer Art stiller Hoffnung. Sie deployen den Code und hoffen, dass nichts kaputtgegangen ist. Sie gehen die Checkliste durch und hoffen, nichts übersehen zu haben. Tests ersetzen diese Hoffnung durch Belege: den Nachweis, dass der Code tatsächlich tut, was er tun soll. Sie können die Tests vor einem Release laufen lassen, nach einem Dependency-Update oder nach einem Refactoring, und sehen sofort, ob sich das System so verhält wie erwartet. Diese Gewissheit schafft Vertrauen und erlaubt Ihrem Team, in dem Tempo zu arbeiten, das Ihr Geschäft tatsächlich braucht.

Die meisten Teams, denen diese Gewissheit fehlt, würden nie von sich sagen, dass sie nicht testen. Sie sehen sich als Teams, die dann testen, wenn es darauf ankommt: manuell, vor Releases, mit Sorgfalt. Und das kann eine Weile gut gehen.

Der Moment, in dem es nicht mehr funktioniert, kommt selten mit einem großen Knall, sondern schleichend: Releases dauern immer länger, Updates werden verschoben, weil niemand schuld sein will, wenn der Checkout ausfällt, und alle werden etwas nervöser, sobald es um bestimmte Teile der Codebasis geht. Mit KI-gestützter Entwicklung erreicht ein Team diesen Punkt schneller als je zuvor, weil einfach mehr Code durch die Pipeline läuft.

Wenn Ihnen das bekannt vorkommt, liegt das Problem meist nicht an einem bestimmten Bug oder einer Lücke im Team. Es liegt am Release-Prozess selbst und am fehlenden Sicherheitsnetz darunter.

Genau daran arbeiten wir bei Kiwee zu einem großen Teil: Wir helfen E-Commerce-Teams, stabile und reproduzierbare Deployment-Pipelines aufzubauen, Staging-Umgebungen einzurichten, die das Live-System wirklich abbilden, und automatisierte Tests für die Abläufe einzuführen, auf die es am meisten ankommt. Nicht als einmaliges Projekt, sondern als Grundlage für einen Shop, der sich weiterentwickeln kann, ohne dass sich jede Änderung riskant anfühlt.

Sie planen eine Shopware-Migration, haben Integrationen, die niemand gern anfasst, oder möchten einfach wissen, wo Ihr aktuelles Setup am verwundbarsten ist? Dann schauen wir uns das gern gemeinsam an.