Kleine Teams scheitern beim Testen selten an fehlendem Wissen — sie scheitern daran, dass sie Testing-Strategien von Konzernen kopieren, die für ihre Realität nicht gebaut sind. Mit einem bis fünf Entwicklern brauchst du keine Coverage-Ziele und keine Testpyramiden-Debatten. Du brauchst eine Antwort auf eine Frage: Welche Tests verhindern die Bugs, die dich wirklich Geld oder Wochenenden kosten?
Ich arbeite in genau dieser Teamgröße — eigene Produkte, Kundenprojekte, ein Trading-Game mit echten Nutzern — und habe über die Jahre eine pragmatische Linie gefunden. Hier ist sie, inklusive der Stellen, an denen ich bewusst gegen die reine Lehre verstoße.
Erst das Risiko sortieren, dann die Tests schreiben
Bevor du auch nur einen Test schreibst, lohnt eine Zehn-Minuten-Übung: Schreib die drei Szenarien auf, die dein Projekt ernsthaft beschädigen würden. Bei einem Shop: falsche Preisberechnung, kaputter Checkout, Bestellungen gehen verloren. Bei einem SaaS: Datenverlust, Abrechnungsfehler, Login kaputt. Bei einer Agentur-Website: Kontaktformular sendet nicht.
Das ist deine Test-Prioritätenliste. Alles andere — Coverage-Prozente, ob ein Getter getestet ist, die hundertste Validierungs-Variante — ist nachgelagert. Der Fehler, den ich in kleinen Teams am häufigsten sehe: hunderte triviale Unit-Tests auf unkritischem Code, während der Bezahlprozess ungetestet ist, weil er “schwer zu testen” ist. Genau umgekehrt wird ein Schuh draus: Schwer testbar und geschäftskritisch ist die Kombination, in die du deine Zeit steckst.
Die ehrliche Hierarchie für kleine Teams
Meine Reihenfolge, wenn ich ein Projekt von null aufsetze:
1. Ein Smoke-Test auf dem kritischen Pfad (E2E)
Ein einziger End-to-End-Test, der den wichtigsten Durchlauf abdeckt: Registrieren, einloggen, Kernaktion ausführen, Ergebnis sehen. Mit Playwright ist das heute in ein bis zwei Stunden gebaut. Dieser eine Test fängt eine absurde Menge echter Fehler: kaputte Builds, vergessene Env-Variablen, CORS-Probleme, zerschossene Formulare, fehlgeschlagene Migrationen. Kein Unit-Test der Welt findet diese Klasse von Fehlern, weil sie zwischen den Einheiten entstehen.
2. Unit-Tests für echte Logik
Alles, was rechnet, entscheidet oder transformiert: Preislogik, Provisionsberechnung, Datums-Handling, Parser, Zustandsmaschinen. Hier sind Unit-Tests unschlagbar — schnell, präzise, und sie dokumentieren die Fachlichkeit. Was ich nicht mehr unit-teste: Glue-Code, Controller, die nur durchreichen, triviale Mappings. Der Test, der nur das Framework testet, ist Ballast.
3. Integrationstests gegen die echte Datenbank
Der Bereich, der in der klassischen Pyramide zu kurz kommt und in der Praxis Gold wert ist: Repository- und Query-Tests gegen eine echte Postgres-Instanz (Docker oder Testcontainers). ORM-Mocks lügen — sie testen deine Annahmen über die Query, nicht die Query. Gerade bei komplexeren Abfragen, Constraints und Transaktionen findet ein Test gegen die echte DB die Fehler, die sonst erst in Produktion auftauchen.
Auf dieser Basis wächst der Rest organisch: Jeder Bug, der es in Produktion schafft, bekommt einen Regressionstest. Das ist die effizienteste Test-Investition überhaupt, weil sie bewiesenermaßen relevante Fälle abdeckt.
E2E vs. Unit: Der Streit ist für kleine Teams entschieden
Die klassische Testpyramide — viele Unit-Tests unten, wenige E2E oben — stammt aus einer Zeit, in der E2E-Tests langsam, teuer und flaky waren. Playwright und moderne Tooling-Ketten haben das Kostenverhältnis verschoben. Für ein kleines Team mit einer Web-App liefert eine Handvoll stabiler E2E-Tests mehr Vertrauen pro investierter Stunde als hundert Unit-Tests.
Aber — und diese Grenze ist real: E2E-Tests skalieren schlecht. Ab einer gewissen Anzahl werden sie langsam, und ein Flaky-Test, dem niemand mehr traut, ist schlimmer als kein Test, weil er das Signal “rot = Problem” entwertet. Meine Grenze liegt bei grob zehn bis fünfzehn E2E-Szenarien; alles Feinere wandert eine Ebene runter. Und: E2E-Tests sagen dir, dass etwas kaputt ist, aber schlecht wo. Für schnelles Debugging brauchst du darunter die präziseren Tests.
KI-generierte Tests: Nützlich, aber nicht da, wo du denkst
Claude, Copilot und Co. schreiben inzwischen brauchbare Tests — aber die Einordnung ist wichtig, weil hier gerade viel Unsinn erzählt wird.
Was gut funktioniert: Boilerplate wegnehmen. Test-Setup, Mock-Konstruktion, Tabellen von Edge-Cases für eine bestehende Funktion — das erledigt KI schneller und gründlicher als du, und sie vergisst den Randfall mit dem leeren Array nicht. Auch stark: Charakterisierungs-Tests für Legacy-Code, also Tests, die das Ist-Verhalten einfrieren, bevor du refactorst.
Wo es kippt: KI-Tests neigen dazu, die Implementierung zu bestätigen statt die Anforderung zu prüfen. Wenn die Funktion einen Bug hat, generiert die KI dir gern einen Test, der den Bug als Sollverhalten festschreibt. Deshalb gilt: Die Assertion — was soll richtig sein — ist deine Denkarbeit. Generierte Tests, die du ungelesen mergst, sind keine Qualitätssicherung, sondern Coverage-Kosmetik. Ich lasse KI Tests entwerfen, aber ich lese jede Assertion wie ein Review.
Was du bewusst weglassen darfst
Ohne schlechtes Gewissen streichen kannst du: Coverage-Mindestquoten als CI-Gate (sie erzeugen Tests, die Zahlen optimieren statt Risiken), Snapshot-Tests auf ganze UI-Komponenten (sie brechen bei jeder Änderung und werden reflexhaft weggeklickt), und Tests für Wegwerf-Code und Prototypen, deren Zukunft unklar ist. Testing ist eine Investition — und Investitionen in Code, der nächste Woche gelöscht wird, sind Verluste.
Was du nicht streichen solltest, auch wenn es verlockend ist: den einen Smoke-Test und die Tests auf Geld-Logik. Das sind die beiden Punkte, an denen “wir testen später” regelmäßig teuer wird.
Der Rahmen drumherum: CI ab Tag eins
Tests, die nur lokal laufen, existieren praktisch nicht. Eine minimale CI — GitHub Actions mit Install, Build, Test bei jedem Push — ist in dreißig Minuten aufgesetzt und macht aus deiner Testsammlung ein Sicherheitsnetz. Dazu eine Regel, die wichtiger ist als jedes Tool: Ein roter Test wird noch heute gefixt oder gelöscht, niemals ignoriert. Ein Test-Setup, in dem Rot der Normalzustand ist, ist totes Gewicht.
Mit diesem Setup — ein Smoke-Test, Logik-Units, DB-Integrationstests, Regressionstests für echte Bugs, CI — bist du als kleines Team besser aufgestellt als viele große mit beeindruckenden Coverage-Dashboards. Falls du über deine Test-Strategie sparren willst: Im Discord der Community diskutieren wir solche Setups regelmäßig an konkreten Projekten.