Prompt für einen API-Testplan

Wann dieser Prompt zum Einsatz kommt

Nutzen Sie diesen Prompt, wenn Sie einen risikobasierten API-Testplan benötigen und einen konkreten Ausgangspunkt statt allgemeiner Ratschläge suchen. Ersetzen Sie die fiktiven Details durch Ihre eigenen gesicherten Fakten, bevor Sie das Ergebnis in der Praxis einsetzen.

Der Prompt

## Rolle
Agieren Sie als Backend-Quality-Engineer. Wenden Sie fachliches Urteilsvermögen an und halten Sie Ihre Argumentation auch für Nicht-Spezialisten nachvollziehbar.

## Kontext
Eine fiktive Termin-API stellt POST /appointments, GET /appointments/{id} und DELETE /appointments/{id} bereit. Die Terminerstellung akzeptiert eine Provider-ID, einen Startzeitstempel und eine Dauer in Minuten. Benutzer müssen sich authentifizieren und dürfen nur ihre eigenen Termine einsehen oder stornieren. Ein Provider darf keine überlappenden aktiven Termine haben. Als Persistenzschicht dient PostgreSQL; das Anwendungs-Framework ist nicht festgelegt.

## Ziel
Erstellen Sie ein Testdesign von ausführungsreifer Qualität, noch bevor ein Framework ausgewählt oder implementationsspezifischer Testcode geschrieben wird.

## Zielgruppe
Die primären Anwender sind Backend-Teams. Gestalten Sie das Ergebnis so, dass es im Arbeitsalltag direkt nutzbar ist – mit ausreichend Erklärungen zur Unterstützung von Entscheidungen, aber ohne unnötige theoretische Vorträge.

## Anforderungen
Decken Sie Happy Paths, fehlerhafte Eingaben, Randzeiten, Zeitzonen-Offsets, Berechtigungen/Ownership, Stornierungsverhalten, parallele Buchungen und Datenbank-Isolation ab. Benennen Sie Annahmen zu Intervallgrenzen und Idempotenz von Stornierungen explizit als noch offene Schnittstellenentscheidungen (Contract Decisions). Definieren Sie Setup, Aktion, beobachtbares Ergebnis und Cleanup für Risikofälle. Trennen Sie Unit-, Integrations- und End-to-End-Abdeckung voneinander; schlagen Sie deterministische Fixtures und eine schlanke CI-Smoke-Suite vor – jeweils mit Begründung, was in der umfangreicheren Suite verbleibt.

## Einschränkungen
Erfinden Sie keine Statuscodes als festgelegte Anforderungen, setzen Sie UTC-Eingaben nicht zwingend voraus und verlassen Sie sich weder auf die Testreihenfolge noch auf Produktionsdaten. Arbeiten Sie ausschließlich mit dem Szenario und explizit bereitgestellten Materialien. Kennzeichnen Sie Annahmen und unterscheiden Sie vorgeschlagene Maßnahmen klar von bestätigten Fakten.

## Tonfall & Stil
Direkt, durchdacht und präzise. Bevorzugen Sie verständliche Sprache, konkrete Beispiele und kurze Absätze. Passen Sie die Sprache an die Zielgruppe an, anstatt auf Jargon oder allgemeine Motivationsfloskeln zurückzugreifen.

## Ausgabeformat
Präsentieren Sie das angeforderte Ergebnis zuerst. Verwenden Sie aussagekräftige Überschriften und Tabellen nur dort, wo sie die Verständlichkeit verbessern. Trennen Sie erläuternde Anmerkungen vom eigentlichen Dokument für die direkte Verwendung. Schließen Sie mit einer kurzen Checkliste offener Entscheidungen oder Verifizierungsschritte ab.

## Was zu vermeiden ist
Vermeiden Sie Füllwörter, unbelegte Gewissheiten und Details, die nur erfunden wurden, um das Ergebnis vollständiger wirken zu lassen. Lassen Sie nicht zu, dass eine geschliffene Darstellung über fehlende Informationen oder widersprüchliche Anforderungen hinwegtäuscht.

## Erfolgskriterien
Der Plan deckt Unklarheiten im API-Vertrag auf und fängt sowohl unberechtigte Zugriffe als auch Doppelbuchungen unter paralleler Last zuverlässig ab. Überprüfen Sie das Ergebnis vor der Ausgabe anhand der genannten Einschränkungen und korrigieren Sie etwaige Unstimmigkeiten.

## Rückfragen
Stellen Sie maximal drei gezielte Rückfragen nur dann, wenn fehlende Informationen das Ergebnis grundlegend verändern würden. Fahren Sie andernfalls mit dem fiktiven Szenario fort, benennen Sie notwendige Annahmen kurz und heben Sie hervor, was ein tatsächlicher Anwender vor der Umsetzung noch bestätigen sollte.

Warum er funktioniert

• Das Szenario liefert dem Modell konkrete Fakten und Grenzen, anstatt es ein Briefing selbst erfinden zu lassen.
• Die Anforderungen definieren die tatsächlichen Lieferergebnisse und die entscheidenden Randfälle für diese Aufgabe.
• Die Einschränkungen verhindern, dass sich unbelegte Behauptungen und nicht abgestimmte Zusagen in das Ergebnis einschleichen.
• Die Erfolgskriterien machen das Review zu einer praktischen Überprüfung: Der Plan legt Vertragslücken offen und verhindert unberechtigte Zugriffe sowie Doppelbuchungen unter Last.

Machen Sie ihn zu Ihrem

Erstellen Sie eine maßgeschneiderte Version mit PromptDeck indem Sie das fiktive Szenario durch Ihren eigenen Kontext, Ihre Zielgruppe und Ihre Rahmenbedingungen ersetzen. Behalten Sie die Verifizierungsschritte bei, damit das Endergebnis exakt auf Ihrem tatsächlichen Kenntnisstand aufbaut.