KI-Test-Prompts: kleine Prüfungen für wichtige Benutzerflüsse

Warum du immer wieder Features statt Tests bekommst

Die meisten KI-Coding-Tools sind darauf trainiert, sichtbaren Fortschritt zu zeigen. Wenn du fragst: „Kannst du das Login verbessern?“, ist die sicherste Reaktion, Code, neue Bildschirme oder zusätzliche Optionen hinzuzufügen. Tests wirken langsamer, weil sie nicht sofort ändern, worauf du klicken kannst.

Ein zweites Problem ist, wie viele Prompts formuliert sind. Wenn du ein Problem ohne harte Grenzen beschreibst, füllt das Modell Lücken, indem es Extras erfindet: Edge-Case-Handling, neue Einstellungen, „Nice-to-haves“. Es will helfen, optimiert aber fürs Bauen, nicht fürs Prüfen.

Ohne kleine Prüfungen werden grundlegende Benutzerflüsse stillschweigend kaputt. Eine kleine UI-Anpassung kann Signup stoppen. Ein Refactor kann das Passwort-Zurücksetzen kaputtmachen. Eine „einfache“ Auth-Änderung kann Geheimnisse offenlegen oder Validierung überspringen. Meist bemerkst du das erst, wenn Nutzer sich beschweren oder die Datenbank falsche Daten sammelt.

Eine „kleine Prüfung“ ist absichtlich eng gefasst: ein schneller Test, der bestätigt, dass ein wichtiger Flow noch funktioniert. Es ist kein kompletter Testplan und kein Rewrite des Frameworks. Es ist eine kurze Abfolge von Schritten und erwarteten Ergebnissen, die du in Minuten (manuell oder automatisiert) ausführen kannst, um teure Fehler zu erkennen.

Gute KI-Test-Prompts fordern Prüfungen, keine Verbesserungen. Sie sagen der KI, keine Features hinzuzufügen und sich auf beobachtbare Ergebnisse zu konzentrieren.

Eine kleine Prüfung enthält normalerweise den Ausgangszustand, die genauen Schritte, das erwartete Ergebnis und ein oder zwei klare Fehlersignale.

Kleine Prüfungen schützen deine wichtigsten Benutzerflüsse, weil sie wie Stolperdrähte wirken. Wenn Signup, Login, Checkout oder „Projekt erstellen“ zentral für dein Business sind, willst du sofort wissen, wenn dieser Pfad nicht mehr funktioniert — bevor du neue Features darauf stapelst.

Das gilt besonders für KI-generierte Prototypen. Code kann „fertig“ aussehen, während Auth brüchig ist, Datenregeln chaotisch sind und Sicherheitslücken offen sichtbar sind. Eine Handvoll gut geschriebener Prüfungen fängt diese Fehler früh ab und lässt dich selbstbewusst weiterbauen.

Wähle zuerst die Flows, die du schützen willst

Wenn du Tests ohne Prioritäten anforderst, bekommst du meist einen Haufen vager Ideen. Bevor du KI-Test-Prompts schreibst, wähle eine kleine Menge von Benutzerflüssen, bei deren Ausfall es sofort wehtut.

Beginne mit 3 bis 5 Flows, die das Produkt tragen. Für viele Apps sind das Signup, Login, Checkout (wenn du Geld verlangst), das Erstellen des Hauptobjekts (Post/Projekt/Aufgabe/Datei) und das Aktualisieren zentraler Einstellungen (E-Mail/Passwort/Plan).

Formuliere nun für jeden Flow in einem Satz, was „done“ ist. Halte es klar und testbar. Beispiel: „Ein neuer Nutzer kann sich per E-Mail registrieren, erhält eine Verifizierungsnachricht und kann sich nach der Verifizierung einloggen.“ Dieser Satz wird der Anker für die Prüfungen, die du die KI erzeugen lässt.

Wähle als Nächstes das Test-Level, das du wirklich brauchst. Denk nicht zu viel nach. Nutze den günstigsten Test, der die Art von Fehler erkennen würde, die du erwartest.

• Unit-Tests: gut, wenn eine einzelne Funktion oder Regel oft kaputtgeht (z. B. Passwortstärke-Regeln).
• Integrationstests: gut, wenn mehrere Teile zusammenarbeiten müssen (Auth + DB + Session).
• End-to-End-Tests: gut für die Flows, die Nutzer sehen (Signup, Login, Bezahlung). Halte sie gering.

Um schnell zu entscheiden, notiere, wie ein Fehler aussieht und wie schlimm er ist. Was würde morgen am meisten Support-Zeit kosten? Was blockiert Nutzer daran, Wert zu erhalten? Was könnte Sicherheits- oder Geldprobleme verursachen? Was bricht oft, wenn du „nur eine Kleinigkeit änderst“?

Beispiel: Wenn dein Prototyp Nutzer manchmal zufällig ausloggt, schütze Login/Logout mit einem End-to-End-Check und einer Integrationsprüfung rund um die Session-Erstellung.

Gib der KI den richtigen Kontext (ohne zu viel zu verraten)

Wenn du Tests willst, beschreibe dein Produkt nicht wie ein Pitch-Deck. Gib gerade so viel Kontext, dass „funktionieren“ definiert ist, plus wo der Flow beginnt und endet. Guter Kontext hilft der KI, kleine, langweilige Prüfungen statt neuer Feature-Ideen zu erzeugen.

Beginne mit einer zweizeiligen Momentaufnahme: was die App macht und für wen. Beispiel: „Eine einfache Terminplanungs-App für Freelancer. Neue Nutzer registrieren sich, erstellen einen Buchungslink und teilen ihn.“

Gib nur die Technik-Basics, die du wirklich kennst. Kein Architekturdiagramm nötig. Ein paar Fakten helfen der KI, realistische Checks und die Dateneinrichtung zu wählen: Framework, Backend und Datenbank (falls bekannt). Wenn du es nicht weißt, sag das. Raten ist schlechter als Leer lassen.

Sei präzise über die Flow-Grenze. Nenne den genauen Start- und Endpunkt mit dem, was du hast: Bildschirmnamen, Routen oder Button-Labels. „Start: /signup. Ende: Redirect zu /dashboard mit einem ‚Willkommen‘-Toast.“ Diese Details machen oft den Unterschied zwischen einem Test und einer vagen Checkliste.

Füge praktische Hinweise zur Testumgebung hinzu, damit die KI keine unmöglichen Schritte erfindet. Zum Beispiel: ob du einen seeded Test-User verwenden kannst (und welche Passwortregeln gelten), ob du einen Test-Zahlungsmodus hast (und was „Erfolg“ bedeutet) und welche Demo-Daten vorhanden sein müssen (ein Plan, eine Organisation, ein Projekt).

Sag zuletzt in einfachen Worten, was aktuell schmerzt: was häufig kaputtgeht oder schwer zu prüfen ist. „Login funktioniert manchmal, aber Refresh loggt dich aus.“ Oder: „Signup gelingt, aber die Verifizierungs-E-Mail kommt nie an.“ Das sagt der KI, wo Checks und Assertions nötig sind.

Vermeide Überinformation, die das Modell ablenkt: lange User-Stories, ganze Code-Dumps und alle Features auf der Roadmap. Wenn der Codebasis chaotisch ist (bei KI-generierten Prototypen üblich), sag das auch.

Die Prompt-Regeln, die Testausgaben vorhersehbar machen

Wenn deine KI immer wieder neue Features vorschlägt, fehlt deinem Prompt eine harte Grenze. Beginne damit, was Erfolg ist: Prüfungen, die das heutige Verhalten bestätigen, kein Rewrite.

Dieser eine Satz ändert alles: „Do not change app behavior. Only add tests.“ Er reduziert außerdem die Chance, dass das Modell Code-Pfade „repariert“, nur damit Tests grün werden.

Regel 1: Halte den Scope klein und konkret

Tests werden unübersichtlich, wenn die Anfrage vage ist. Wähle einen Benutzerfluss (Signup, Checkout, Passwort-Reset), einen Testtyp und eine kleine Dateigruppe. Wenn du sagst „füge Tests für die App hinzu“, bekommst du Vermutungen.

Gute Einschränkungen sehen so aus: ein Flow, ein Testtyp (Unit oder API oder UI, nicht alle drei), ein Ordner oder Satz von Dateien und eine klare „Done“-Linie (z. B.: 5 Prüfungen, die Happy Path und 2 häufige Fehler abdecken).

Regel 2: Erzwinge eine konsistente Ausgabeform

KI-Test-Prompts funktionieren am besten, wenn du ein vorhersehbares Format verlangst. Fordere Testnamen, Schritte, Assertions und Fixtures in dieser Reihenfolge an. Das verhindert Textwände und macht fehlende Fälle offensichtlich.

Ein Prompt-Muster, das lesbar bleibt:

Write tests only. Do not change production code.
Flow: [describe one flow]
Output:
1) Assumptions (max 5)
2) Questions (if needed, max 5)
3) Test list with names
4) For each test: steps + assertions + data fixtures
Constraints: deterministic data only; no randomness unless seeded.

Regel 3: Fordere deterministische Prüfungen

Flakige Tests verschwenden mehr Zeit als fehlende Tests. Sag der KI, zeitbasierte Assertions, zufällige E-Mails und ungeordnete Ergebnisse zu vermeiden, es sei denn, sie kann sie kontrollieren (seeded values, feste Uhrzeit).

Regel 4: Lass sie Unsicherheit zugeben

Verlange, dass das Modell Annahmen auflistet und Fragen stellt, bevor es Tests schreibt. Das ist besonders wichtig bei KI-generierten Prototypen, wo Logik oft unklar ist.

Prompt-Vorlagen, die kleine Prüfungen erzeugen

Der einfachste Weg, kleine Checks statt neuer Features zu bekommen, ist strikte Scope-Vorgabe: ein Flow, ein Ziel, ein Ausgabeformat. Sag außerdem, was du nicht willst: keine UI-Ideen, keine Refactors, keine neuen Endpoints.

Benutze die Vorlagen unten unverändert und tausche Flow und Tech-Stack. Wenn das Tool trotzdem Features erfindet, wiederhole die Constraint-Zeile am Ende.

Vorlage 1: Minimaler Testplan für einen Flow

Fordere erst einen kurzen Plan, bevor du vollständige Tests verlangst. Das hält die Ausgabe eng.

You are a QA tester.
Flow: <name the single flow>.
Goal: produce a minimal test plan with small checks.

Context:
- App type: <web/mobile>
- Auth state: <logged out/logged in>
- Data needed: <e.g., existing user, empty cart>

Output format:
- 8-12 test checks max
- Each check is 1 sentence, starting with “Verify…”
- Cover happy path + 2 failure cases + 1 security-ish check

Constraints:
- Tests only. Do not suggest features, UI changes, refactors, or new APIs.
- If you need assumptions, list them under “Assumptions” (max 3).

Vorlage 2: Acceptance Criteria zuerst, dann Tests

Nützlich, wenn der Flow vage ist oder du Formulierungen für Nicht-Techniker brauchst.

Act as a product QA.
User flow: <flow name>.
User goal: <one sentence>.

Step 1: Write acceptance criteria in Given/When/Then (5-7 items).
Step 2: Convert each criterion into 1-2 small test checks.

Constraints:
- Do not add new features.
- Keep wording specific (no “should work”, no “fast”).
- If something is unclear, ask 2 questions max, then proceed with assumptions.

Vorlage 3: Boundary Cases und Error States

Nutze dies, wenn du bereits Basisabdeckung hast und die „Dinge, die in Produktion brechen“ auflisten willst.

You are generating edge-case checks for <flow name>.
List 10 small checks focused on boundary cases and error states.

Include cases like:
- invalid input (e.g., wrong password)
- expired/invalid session
- missing permissions
- rate limit / too many attempts
- network timeout and retry behavior

Constraints:
- Tests only. No feature suggestions.
- Each check must name the expected user-visible result (message, redirect, blocked action).

Vorlage 4: „Top 5 Regressionen“ nach einem Refactor

Gut für Prototypen, bei denen kleine Code-Änderungen zentrale Pfade still kaputtmachen.

We just refactored <area: auth, payments, settings>.
Give the top 5 regressions that commonly happen in <flow name>.
For each regression, provide:
- what breaks
- how to detect it (1 small check)
- what logs or signals would confirm it (1 short hint)

Constraints:
- Do not propose refactors or new features.
- Keep it to 5 items.

Vorlage 5: „Nur Tests“ mit hartem No-Change-Constraint

Nutze dies, wenn dein KI-Tool ständig „hilfreich“ die App umschreibt.

Task: write tests for <flow name>.

Hard rule:
- Output tests only.
- Do not suggest code changes, new features, new endpoints, or UI updates.

Tech:
- Framework: <Playwright/Cypress/Jest/etc>
- App URL/routes: <list>
- Test data: <credentials, sample records>

Output:
- Provide exactly 6 tests: 3 happy path, 2 negative, 1 security check.
- If any test is not possible with given info, write a placeholder test with TODO and explain what info is missing (1 sentence).

Wenn das Tool ohne Erfinden von Verhalten keinen Test schreiben kann, ist das oft das erste Signal, dass du eine echte Diagnose brauchst, bevor du mehr Code hinzufügst.

Schritt für Schritt: in 30 Minuten zu einem nützlichen Test

Du bekommst schnell einen brauchbaren Test, wenn du aufhörst, alles abdecken zu wollen. Wähle einen Flow, schreibe eine kleine Prüfung und erweitere erst dann. KI-Test-Prompts helfen am meisten, wenn sie eine vage Idee wie „Teste Login“ in eine konkrete, wiederholbare Prüfung verwandeln.

Hier ein einfacher 30-Minuten-Pfad, der auch bei einem Prototyp funktioniert:

1. Schreibe einen Happy Path für einen Flow. Wähle einen einzelnen Start und ein Ende. Beispiel: „Nutzer registriert sich mit einer unbenutzten E-Mail und landet auf dem Dashboard.“ Kurz genug, dass ein Fehlschlag etwas Spezifisches aussagt.

2. Füge einen negativen Fall hinzu, der realistisch ist. Erfinde noch keine Randfälle. Nutze einen Fehler, den du tatsächlich gesehen hast, z. B. „Login schlägt mit richtigem Passwort fehl“ oder „Signup gelingt, aber der Nutzer wird nicht angelegt.“

3. Behaupte, was Nutzer sehen, nicht interne Details. Prüfe Outcomes: eine Erfolgsmeldung, ein Redirect, ein aktivierter Button, ein Eintrag in der DB oder ein Error-Banner. Wenn du das erwartete Ergebnis nicht in einem Satz erklären kannst, ist der Test zu groß.

4. Führe den Test einmal aus und erfasse den exakten Fehler. Kopiere den vollständigen Fehltext und das kleinste Kontextstück (was du geklickt hast, welche Daten du benutzt hast). Nicht paraphrasieren. Kleine Details wie eine Routenbezeichnung oder ein Statuscode weisen oft auf das eigentliche Problem.

5. Bitte die KI zuerst, den Test zu reparieren. Tests scheitern aus langweiligen Gründen: selektoren haben sich geändert, Timing-Probleme, falsche Setup-Schritte, fehlende Seed-Daten. Bitte die KI nur dann, den Code zu ändern, wenn das erwartete Verhalten eindeutig richtig ist und die App offensichtlich falsch.

Wenn du feststeckst, füge drei Dinge in deinen Prompt ein: die User-Story (ein Satz), das aktuelle Verhalten (was du gesehen hast) und die Fehlermeldung (genauer Text). Beispiel: „Nach dem Signup zeigt die Seite Erfolg, aber nach Refresh bin ich ausgeloggt“ plus die fehlgeschlagene Assertion.

Häufige Fehler, die Zeit kosten

Der schnellste Weg, einen Nachmittag zu verlieren, ist, Tests vage anzufordern und dann alles zu akzeptieren, was die KI zurückgibt. Du endest mit Seiten voller „Coverage“, die nicht das eine schützen, was dir wirklich wichtig ist: dass eine reale Person einen zentralen Flow abschließen kann.

Diese Fehler treten ständig auf:

• „Teste alles“ oder „volle Abdeckung“ fordern. Du bekommst viele niedrigwertige Checks (Leere-Zustände, kleine UI-Details, Randfälle, über die du noch nicht entschieden hast).
• Der KI erlauben, das Produkt zu ändern, um Tests grün zu bekommen. Sie schlägt vor, Fehlermeldungen zu ändern, Validierung zu lockern oder Auth zu überspringen.
• Zerbrechliche Prüfungen, die an UI-Trivia hängen. Wenn ein Test von einem spezifischen CSS-Selector, pixelgenauer Darstellung oder exakt gleichem Button-Text abhängt, bricht er beim kleinsten UI-Tweak.
• Setup und Cleanup überspringen. Ohne klare Testdaten und Reset-Schritte beeinflusst ein Lauf den nächsten und erzeugt flakige Fehler.
• Versionen und Testdaten nicht pinnen. Wenn Test-Runner, Browser, Seed-Daten oder Env-Variablen zwischen Runs wechseln, werden Ergebnisse inkonsistent.

Ein einfaches Beispiel: Du bittest um einen Login-Test und die KI schreibt: „klicke den dritten Button im Header, dann erwarte den Text ‚Welcome back!‘“. Nächste Woche nennst du den Button „Sign in“ und der Check schlägt fehl, obwohl das Login funktioniert.

Ein paar Leitplanken verhindern das meiste:

• Sag, was nicht geändert werden darf (Regeln, Validierung, Sicherheit, Copy, falls wichtig).
• Bevorzuge stabile Hooks (Test-IDs, API-Antworten, Datenbankeinträge) gegenüber visuellen Details.
• Bestehe auf Wiederholbarkeit (Seed-Daten, Reset-Schritt, feste Versionen).

Schnelle Checks für einen guten Test (bevor du mehr hinzufügst)

Bevor du mehr Coverage hinzufügst, vergewissere dich, dass jeder Test wirklich nützlich ist. Ein kleiner, zuverlässiger Check schlägt zehn flakige.

Fünf Sanity-Checks, die die meisten schlechten Tests fangen

• Breche den Flow absichtlich und sieh, warum er fehlschlägt. Nutze falsches Passwort, entferne ein Pflichtfeld oder blockiere eine Anfrage. Der Fehler sollte auf den Nutzerschritt verweisen, nicht auf einen unrelated Timeout.
• Behaupte etwas, das der Nutzer sieht. Bevorzuge „zeigt Fehlermeldung“ oder „landet auf Dashboard“ statt „Konsole enthält Log“ oder nur „API gab 200 zurück“.
• Gib dem Test einen lesbaren Namen. „login lehnt falsches Passwort ab“ ist besser als „auth test 3“.
• Führe ihn zweimal hintereinander aus ohne Überraschungen. Wenn der zweite Lauf fehlschlägt, weil der Nutzer bereits existiert, ist der Test nicht isoliert.
• Mach Updates günstig, wenn die UI sich ändert. Wenn ein Button-Label sich ändert, update einen Selector oder Helper, nicht zehn Files.

Ein schnelles Beispiel (Signup)

Wenn dein Signup-Test nur „POST /signup gibt 201 zurück“ prüft, kann er das echte Problem übersehen: die UI zeigt eine leere Seite, weil ein Redirect kaputt ist. Ein besserer Check: fülle E-Mail und Passwort aus, sende ab und bestätige, dass du auf einer Seite landest, die beweist, dass du eingeloggt bist (z. B. Begrüßung oder „Log out“-Button).

Beispiel: Signup und Login in einer einfachen App schützen

Eine häufige Geschichte: Du bittest ein KI-Tool, deinen Code aufzuräumen, es refaktorisiert viele Files und der Onboarding-Flow bricht stillschweigend. Die UI sieht noch in Ordnung aus, aber Signup legt keine Nutzer mehr an, Verifizierungslinks 404en oder Login funktioniert nur manchmal, weil das Session-Cookie sich geändert hat.

Statt neue Features zu verlangen, nutze KI-Test-Prompts, um drei kleine Prüfungen zu erhalten, die den Flow schützen, der dir am wichtigsten ist:

• Signup legt einen neuen Nutzer an und zeigt den erwarteten nächsten Schritt
• E-Mail-Verifizierung markiert den Nutzer als verifiziert (oder erlaubt Login)
• Erstes Login funktioniert nach Verifizierung und landet auf der richtigen Seite

Hier sind exakte Prompts, die du in dein KI-Tool einfügen kannst. Sie sind so geschrieben, dass sie kleine Prüfungen erzwingen, nicht eine riesige Testsuite.

You are helping me write SMALL user-flow checks, not new features.
App context:
- Stack: [fill in: e.g., Next.js + Supabase]
- Auth: [fill in: email/password]
- Environments: local only
- Seed user: none

Goal: Create 3 checks for onboarding.
Flows:
1) Signup
2) Email verification
3) First login

Output format MUST be:
- For each check: Name, Preconditions, Steps (max 6), Expected results (max 5)
- No code. No extra commentary.
- Use plain English.

Wenn deine App einen E-Mail-Link benutzt, füge eine weitere Einschränkung hinzu, damit die Ausgabe realistisch bleibt:

Email verification detail:
- The app sends a verification link to the user.
- For the check, assume we can access the link in a test inbox OR read the token from logs.
- Do not invent third-party tools.

Die erwartete Struktur (so sollte „gute Ausgabe“ aussehen):

Check 1: Signup creates account
Preconditions: ...
Steps:
1. ...
Expected results:
- ...

Check 2: Email verification enables login
...

Check 3: First login lands on dashboard
...

Wenn einer dieser Checks fehlschlägt, mache eine kurze Aufteilung:

• Bug: das App-Verhalten ist falsch (Signup hat keinen Nutzer angelegt, Verifizierung tut nichts, Login gibt 500)
• Testfehler: die Prüfung hat die falsche Bildschirm-Text, Route oder Verifikationsmethode angenommen

Eine schnelle Regel: Wenn ein echter Nutzer blockiert wäre, behandle es als Bug. Wenn der Nutzer die Reise noch abschließen kann, aber Copy oder Selector sich geändert haben, ist es wahrscheinlich ein Testfehler.

Für einen Prototyp, der Richtung Produktion geht, bedeutet „gut genug“ meist, dass die Prüfungen stabil, klein und Fehlerfindend sind:

• Jede Prüfung passt auf einen Screen und dauert manuell unter 10 Minuten
• Sie schlägt aus dem richtigen Grund fehl (nicht wegen fragiler Textänderungen)
• Sie deckt den Happy Path Ende-zu-Ende ab
• Sie hat klare erwartete Ergebnisse, die jeder verifizieren kann
• Sie ist nach einem KI-generierten Refactor leicht erneut auszuführen

Nächste Schritte: halte deinen Prototyp sicher, während er wächst

Sobald du ein paar Prüfungen hast, die echte Fehler finden, ist das Ziel einfach: Schutz hinzufügen, ohne Testing zur zweiten Vollzeitaufgabe zu machen. Halte eine winzige Liste von Nutzeraktionen, die du nicht zulässt, dass sie brechen.

Schreibe eine einseitige Liste „protected flows“. Halte sie langweilig: signup/login/logout, checkout oder „Trial starten“, erstellen/bearbeiten/löschen des Hauptobjekts, Zahlungen oder Planänderungen (falls relevant) und die eine E-Mail oder Benachrichtigung, die Nutzer unbedingt erhalten müssen.

Füge zuerst genau einen kleinen Test pro Flow hinzu. Wenn du KI-Test-Prompts nutzt, bleibe beim Happy Path plus einem häufigen Fehler (falsches Passwort, leeres Pflichtfeld, abgelaufener Token). Das findet meist mehr echte Bugs als ein großes „teste alles“-Request.

Führe die Prüfungen vor jedem Release und vor jeder Übergabe (an eine Agentur, einen neuen Dev oder an dein zukünftiges Ich) aus. Wenn dein Prototyp täglich verändert wird, wähle einen Trigger, der dich zwingt, sie auszuführen, z. B. „vor der Veröffentlichung in Produktion“ oder „vor dem Versand eines Demo-Links“.

Wenn Auth flakig ist, Geheimnisse offenliegen oder die Architektur Spaghetti ist, retten Tests dich nicht. Du verlierst Zeit mit ständigem Rauschen. In solchen Fällen ist eine kurze Diagnose und Aufräumaktion zuerst meist schneller, damit spätere Tests sinnvoll sind.

Wenn du einen kaputten, KI-generierten Codebestand geerbt hast und schnell eine Diagnose brauchst, konzentriert sich FixMyMess (fixmymess.ai) auf Codebasis-Diagnose, Logik-Reparatur, Sicherheits-Hardening, Refactoring und Deployment-Vorbereitung — beginnend mit einem kostenlosen Code-Audit.

Halte es einfach, während du wächst:

• Schütze eine kleine Liste von Flows
• Füge pro Flow einen kleinen Test hinzu
• Führe Checks vor Release oder Übergabe aus
• Diagnostiziere und repariere chaotische Grundlagen, bevor du Coverage erweiterst
• Und erst dann: mehr Randfälle hinzufügen