Prompt de plan de test d'API

Quand l'utiliser

Utilisez ce prompt lorsque vous devez concevoir un plan de test d'API fondé sur les risques et recherchez un point de départ concret plutôt que des recommandations génériques. Remplacez les éléments fictifs par vos propres spécifications validées avant d'exploiter le résultat en environnement réel.

Le prompt

## Rôle
Agis en tant qu'ingénieur qualité backend (QA). Fais preuve de jugement professionnel tout en maintenant ton raisonnement accessible à une personne non spécialiste.

## Contexte
Une API fictive de prise de rendez-vous expose POST /appointments, GET /appointments/{id} et DELETE /appointments/{id}. La création d'un rendez-vous accepte l'ID d'un prestataire (provider), un horodatage de début (timestamp) et une durée en minutes. Les utilisateurs doivent s'authentifier et ne peuvent consulter ou annuler que leurs propres rendez-vous. Un prestataire ne peut pas avoir de rendez-vous actifs qui se chevauchent. La persistance est assurée par PostgreSQL ; le framework applicatif n'est pas spécifié.

## Objectif
Créer une conception de tests de qualité prête à l'exécution avant de choisir un framework ou d'écrire du code de test dépendant de l'implémentation.

## Public cible
Les utilisateurs principaux sont les équipes backend. Rends le livrable exploitable dans leur travail quotidien, avec suffisamment d'explications pour éclairer les décisions, sans digressions théoriques inutiles.

## Exigences
Couvrir les cas nominaux (happy paths), les entrées mal formées, les valeurs limites temporelles, les décalages de fuseau horaire, le contrôle d'accès/propriété, le comportement de l'annulation, les réservations concurrentes et l'isolation au niveau de la base de données. Formuler les hypothèses sur les bornes d'intervalles et l'idempotence des annulations comme des décisions contractuelles en suspens. Spécifier la configuration initiale (setup), l'action, le résultat observable et le nettoyage (cleanup) pour les cas à haut risque. Séparer la couverture unitaire, d'intégration et de bout en bout (E2E) ; proposer des jeux de données (fixtures) déterministes et une suite de smoke tests CI légère, en justifiant ce qui est réservé à la suite de tests complète.

## Contraintes
Ne pas inventer de codes de statut HTTP comme s'il s'agissait d'exigences établies, ne pas supposer que les entrées en UTC sont obligatoires, et ne pas dépendre de l'ordre d'exécution des tests ni de données de production. Travailler uniquement à partir du scénario et des éléments explicitement fournis. Identifier clairement les hypothèses et distinguer les propositions d'actions des faits confirmés.

## Ton et style
Sois direct, rigoureux et précis. Privilégie un langage clair, des exemples concrets et des paragraphes courts. Adapte le vocabulaire au lecteur ciblé sans recourir au jargon inutile ni à des formules de motivation génériques.

## Format de sortie
Présente le livrable demandé en premier, en utilisant des titres descriptifs et des tableaux uniquement là où ils améliorent la lisibilité. Garde les notes explicatives séparées du contenu destiné à être partagé ou directement utilisé. Termine par une courte checklist des décisions en suspens ou des étapes de vérification.

## Ce qu'il faut éviter
Évite le remplissage, les certitudes non étayées et les détails inventés dans le seul but de rendre le résultat faussement exhaustif. Ne laisse pas une présentation soignée masquer des informations manquantes ou des exigences contradictoires.

## Critères de succès
Le plan met en évidence les ambiguïtés contractuelles et permet de détecter à la fois les accès non autorisés et les doubles réservations sous charge concurrente. Vérifie le résultat au regard des contraintes énoncées avant de le présenter et corrige toute incohérence détectée.

## Questions de clarification
Pose au maximum trois questions ciblées uniquement si une information manquante modifie de manière déterminante le résultat. Sinon, poursuis avec le scénario fictif, énonce brièvement les hypothèses nécessaires et précise ce qu'un utilisateur réel devrait valider avant de s'appuyer sur la réponse.

Pourquoi cela fonctionne

• Le scénario fournit au modèle des faits et des limites concrets au lieu de lui demander d'inventer un brief de toutes pièces.
• Les exigences détaillent les livrables attendus et les cas limites critiques pour cette tâche.
• Les contraintes empêchent l'introduction d'affirmations gratuites ou d'engagements non validés dans la réponse.
• Les critères de succès transforment la relecture en une vérification concrète : le plan met en lumière les zones de flou du contrat d'API et intercepte les accès illégitimes comme les doubles réservations concurrentes.

Adaptez-le à vos besoins

Créez une version sur mesure avec PromptDeck en remplaçant le scénario fictif par votre propre contexte, votre public et vos contraintes spécifiques. Conservez les étapes de vérification afin que le résultat final reflète précisément vos connaissances réelles.