Apprenez à créer des tests d'acceptation à partir de prompts en transformant chaque demande de fonctionnalité en 5 à 10 scénarios clairs, couvrant parcours nominaux et cas limites sans surcharger la suite de tests.
Les prompts en mode chat semblent clairs parce qu'ils ressemblent à une conversation. Mais ils condensent souvent des choix, des règles et des exceptions en quelques phrases amicales. Les lacunes n'apparaissent que lorsque quelqu'un utilise la fonctionnalité pour de vrai.
La plupart des prompts reposent silencieusement sur des hypothèses : qui est autorisé à faire l'action, ce qui compte comme « succès » (enregistré, envoyé, publié, payé), ce qui se passe quand des données manquent, et ce que l'utilisateur doit voir en cas d'échec. Ils cachent aussi des standards flous comme ce que signifie « assez rapide » ou « suffisamment sécurisé ».
L'ambiguïté se révèle généralement tard, sous forme de bugs et de reprise de travail. Un développeur implémente ce qu'il pense que le prompt signifie, un relecteur l'approuve parce que cela semble correct, puis les utilisateurs rencontrent les cas étranges : soumissions en double, fuseaux horaires, données partielles ou incohérences de permissions. Corriger cela plus tard coûte plus cher car cela touche souvent le code, le texte de l'interface et parfois le modèle de données.
La qualité ne nécessite pas des suites de tests énormes. Elle signifie que vous pouvez faire confiance à la fonctionnalité en utilisation normale et sous stress prévisible. Un petit ensemble de scénarios bien choisis vous donne cette confiance sans des centaines de tests.
Une définition pratique de la qualité pour des fonctionnalités issues de prompts :
C'est l'objectif de transformer des prompts en scénarios d'acceptation : prendre une demande vague et la convertir en 5–10 vérifications qui font apparaître les règles cachées tôt. Vous ne cherchez pas à tout tester. Vous cherchez à attraper les échecs qui arrivent réellement.
Si vous partez d'un prompt rapide dans un outil vibe-coding comme Koder.ai, la sortie peut sembler complète tout en sautant les règles limites. Un ensemble serré de scénarios force ces règles à être nommées tant que les changements restent peu coûteux.
Un scénario d'acceptation est une description courte et en langage simple d'une action utilisateur et du résultat qu'il doit voir.
Restez à la surface : ce que l'utilisateur peut faire et ce que le produit affiche ou modifie. Évitez les détails internes comme les tables de base de données, les appels d'API, les jobs en arrière-plan ou le framework utilisé. Ces détails peuvent importer plus tard, mais ils rendent les scénarios fragiles et plus difficiles à approuver.
Un bon scénario est aussi indépendant. Il doit être facile à exécuter demain sur un environnement propre, sans dépendre d'un autre scénario qui aurait été exécuté auparavant. Si un scénario dépend d'un état préalable, dites-le clairement dans la configuration (par exemple : « l'utilisateur a déjà un abonnement actif »).
Beaucoup d'équipes utilisent Given–When–Then parce que cela force la clarté sans transformer les scénarios en spec complète.
Un scénario est généralement « terminé » lorsqu'il a un seul objectif, un état de départ clair, une action concrète et un résultat visible. Il doit être binaire : n'importe qui dans l'équipe peut dire « réussite » ou « échec » après l'avoir exécuté.
Exemple : « Étant donné un utilisateur connecté sans moyen de paiement enregistré, quand il choisit Pro et confirme le paiement, alors il voit un message de succès et le plan s'affiche comme Pro dans son compte. »
Si vous construisez dans un constructeur chat-first comme Koder.ai, gardez la même règle : testez le comportement de l'application générée (ce que l'utilisateur expérimente), pas la manière dont la plateforme a produit le code.
Le meilleur format est celui que les gens écriront et liront. Si la moitié de l'équipe utilise de longues narrations et l'autre moitié écrit des puces concises, vous aurez des lacunes, des doublons et des discussions sur le libellé au lieu d'améliorer la qualité.
Given–When–Then fonctionne bien quand la fonctionnalité est interactive et stateful. Un tableau simple marche bien quand vous avez des règles d'entrée-sortie et beaucoup de cas similaires.
Si votre équipe est divisée, choisissez un format pendant 30 jours et ajustez ensuite. Si les relecteurs demandent sans cesse « qu'est-ce que le succès ? », c'est souvent un signe d'aller vers Given–When–Then. Si les scénarios deviennent verbeux, un tableau peut être plus facile à parcourir.
Quoi que vous choisissiez, standardisez-le. Gardez les mêmes en-têtes, le même temps et le même niveau de détail. Convenez aussi de ce qu'il ne faut pas inclure : détails UI pixel-perfect, implémentation interne et jargon base de données. Les scénarios doivent décrire ce que l'utilisateur voit et ce que le système garantit.
Placez les scénarios là où le travail a déjà lieu et gardez-les proches de la fonctionnalité.
Options courantes : les stocker à côté du code produit, dans vos tickets sous une section « Acceptance scenarios », ou dans un espace de doc partagé avec une page par fonctionnalité. Si vous utilisez Koder.ai, vous pouvez aussi garder les scénarios en Planning Mode pour qu'ils restent avec l'historique de build, les instantanés et les points de restauration.
L'essentiel est de les rendre recherchables, de garder une source de vérité, et d'exiger des scénarios avant que le développement soit considéré comme « commencé ».
Commencez par réécrire le prompt comme un objectif utilisateur plus une ligne d'arrivée claire. Utilisez une phrase pour l'objectif (qui veut quoi), puis 2–4 critères de réussite vérifiables sans débat. Si vous ne pouvez pas pointer un résultat visible, ce n'est pas encore un test.
Ensuite, décomposez le prompt en entrées, sorties et règles. Les entrées sont ce que l'utilisateur fournit ou sélectionne. Les sorties sont ce que le système affiche, enregistre, envoie ou bloque. Les règles sont les « seulement si » et « doit » cachés entre les lignes.
Puis vérifiez de quoi la fonctionnalité dépend avant de fonctionner. C'est là que se cachent les omissions : données requises, rôles utilisateurs, permissions, intégrations et états système. Par exemple, si vous construisez une app dans Koder.ai, précisez si l'utilisateur doit être connecté, avoir un projet créé, ou satisfaire des exigences de plan ou d'accès avant que l'action puisse se produire.
Maintenant rédigez l'ensemble minimal de scénarios qui prouve que la fonctionnalité fonctionne : généralement 1–2 parcours nominaux, puis 4–8 cas limites. Gardez chaque scénario concentré sur une seule cause d'échec potentielle.
Bons cas limites à choisir (seulement ce qui correspond au prompt) : entrée manquante ou invalide, mismatch de permission, conflits d'état comme « déjà soumis », problèmes de dépendances externes comme timeouts, et comportement de récupération (erreurs claires, retry sûr, pas d'enregistrement partiel).
Terminez par un rapide passage « que pourrait-il mal se passer ? ». Cherchez les échecs silencieux, les messages confus et les endroits où le système pourrait produire des données incorrectes.
Un scénario de parcours nominal est la route la plus courte et la plus normale où tout va bien. Si vous le gardez volontairement ennuyeux, il devient une base fiable qui facilite la détection des cas limites plus tard.
Nommez l'utilisateur par défaut et les données par défaut. Utilisez un rôle réel, pas « Utilisateur » : « client connecté avec email vérifié » ou « administrateur avec permission d'éditer la facturation ». Puis définissez les données d'exemple minimales qui ont du sens : un projet, un élément dans une liste, un moyen de paiement enregistré. Cela garde les scénarios concrets et réduit les hypothèses cachées.
Écrivez d'abord le chemin le plus court vers le succès. Supprimez les étapes optionnelles et les flux alternatifs. Si la fonctionnalité est « Créer une tâche », le parcours nominal ne devrait pas inclure le filtrage, le tri ou l'édition après création.
Une façon simple de rester concis : confirmer quatre éléments :
Ajoutez ensuite une variante qui ne change qu'une variable. Choisissez la variable la plus susceptible de casser plus tard, comme « titre long » ou « utilisateur sans éléments existants », et gardez tout le reste identique.
Exemple : si votre prompt dit « Ajouter un toast ‘Snapshot créé’ après enregistrement d'un snapshot », le parcours nominal est : l'utilisateur clique sur Créer le snapshot, voit un état de chargement, obtient « Snapshot créé », et le snapshot apparaît dans la liste avec le bon horodatage. Une variante à une variable pourrait être les mêmes étapes, mais avec un nom vide et une règle de nommage par défaut claire.
Les cas limites sont là où se cachent la plupart des bugs, et vous n'avez pas besoin d'une suite énorme pour les attraper. Pour chaque prompt de fonctionnalité, choisissez un petit ensemble qui reflète le comportement réel et les modes d'échec réels.
Catégories communes :
Toutes les fonctionnalités n'ont pas besoin de toutes ces catégories. Une barre de recherche se soucie plus des entrées. Un flux de paiement se soucie plus d'intégration et de données.
Choisissez des cas limites qui correspondent au risque : coût élevé d'échec (argent, sécurité, confidentialité), forte fréquence, flux facile à casser, bugs connus, ou problèmes difficiles à détecter après coup.
Exemple : pour « l'utilisateur change de plan d'abonnement », les scénarios qui rapportent souvent sont : expiration de session au moment du checkout, double-clic sur « Confirmer », et timeout du fournisseur de paiement laissant le plan inchangé tout en affichant un message clair.
Prompt d'exemple (langage simple) :
« Quand je casse quelque chose, je veux revenir à un instantané précédent pour que la dernière version fonctionnelle soit à nouveau en ligne. »
Voici un ensemble compact de scénarios. Chaque scénario est court, mais il précise le résultat.
S1 [Indispensable] Restaurer vers l'instantané le plus récent
Étant donné que je suis connecté et que je suis propriétaire de l'app
Quand je choisis « Restaurer » et que je confirme
Alors l'app déploie l'instantané précédent et le statut de l'app affiche la nouvelle version comme active
S2 [Indispensable] Restaurer vers un instantané spécifique
Étant donné que je consulte la liste des instantanés de mon app
Quand je sélectionne l'instantané « A » et confirme la restauration
Alors l'instantané « A » devient la version active et je peux voir sa date de création
S3 [Indispensable] Non autorisé (auth)
Étant donné que je suis connecté mais que je n'ai pas accès à cette app
Quand j'essaie de restaurer
Alors je vois une erreur d'accès et aucune restauration ne démarre
S4 [Indispensable] Instantané introuvable (validation)
Étant donné qu'un ID d'instantané n'existe pas (ou a été supprimé)
Quand je tente d'y restaurer
Alors j'obtiens un message clair « instantané introuvable »
S5 [Indispensable] Double soumission (doublons)
Étant donné que je clique deux fois rapidement sur « Confirmer la restauration »
Quand la seconde requête est envoyée
Alors une seule restauration s'exécute et je vois un seul résultat
S6 [Indispensable] Échec de déploiement (échecs)
Étant donné que la restauration a démarré
Quand le déploiement échoue
Alors la version actuellement active reste en ligne et l'erreur est affichée
S7 [Nice-to-have] Timeout ou perte de connexion
Étant donné que ma connexion coupe en plein milieu d'une restauration
Quand je recharge la page
Alors je peux voir si la restauration est toujours en cours ou terminée
S8 [Nice-to-have] Déjà sur cet instantané
Étant donné que l'instantané « A » est déjà actif
Quand j'essaie de restaurer vers l'instantané « A »
Alors on m'indique qu'il n'y a pas de changement et aucune nouvelle déploiement ne démarre
Chaque scénario répond à trois questions : qui le fait, ce qu'il fait, et ce qui doit être vrai ensuite.
Le but n'est pas « tout tester ». Le but est de couvrir les risques qui nuiraient aux utilisateurs, sans créer une pile de scénarios que personne n'exécute.
Une astuce pratique est d'étiqueter les scénarios selon l'usage prévu :
Limitez-vous à un scénario par risque distinct. Si deux scénarios échouent pour la même raison, vous n'en avez probablement besoin que d'un. « Format email invalide » et « email manquant » sont des risques différents. Mais « email manquant à l'étape 1 » et « email manquant à l'étape 2 » peuvent être le même risque si la règle est identique.
Évitez aussi de dupliquer des étapes UI dans de nombreux scénarios. Gardez les parties répétées courtes et concentrez-vous sur ce qui change. Cela compte encore plus quand vous construisez dans un outil basé sur le chat comme Koder.ai, car l'UI peut évoluer tandis que la règle métier reste la même.
Enfin, décidez ce qu'il faut vérifier maintenant vs plus tard. Certaines vérifications sont mieux manuelles au début, puis automatisées lorsque la fonctionnalité se stabilise :
Un scénario doit vous protéger des surprises, pas décrire comment l'équipe prévoit de construire la fonctionnalité.
L'échec le plus courant est de transformer un objectif utilisateur en check-list technique. Si le scénario dit « l'API retourne 200 » ou « la table X a la colonne Y », il vous enferme dans un design et ne prouve toujours pas que l'utilisateur a obtenu ce dont il avait besoin.
Un autre problème est de combiner plusieurs objectifs en un seul long scénario. Il ressemble à un parcours complet, mais lorsqu'il échoue, personne ne sait pourquoi. Un scénario doit répondre à une seule question.
Méfiez-vous aussi des cas limites qui paraissent astucieux mais qui ne sont pas réalistes. « L'utilisateur a 10 millions de projets » ou « le réseau coupe toutes les 2 secondes » correspondent rarement à la production et sont difficiles à reproduire. Choisissez des cas limites que vous pouvez mettre en place en quelques minutes.
Évitez aussi les résultats vagues comme « marche », « sans erreurs » ou « s'exécute avec succès ». Ces mots cachent le résultat exact que vous devez vérifier.
Si vous construisez quelque chose comme la fonctionnalité d'« exporter le code source » de Koder.ai, un scénario faible est : « Quand l'utilisateur clique sur exporter, le système zippe le repo et retourne 200. » Cela teste une implémentation, pas la promesse.
Un meilleur scénario est : « Étant donné un projet avec deux instantanés, quand l'utilisateur exporte, alors le téléchargement contient le code de l'instantané courant et le journal d'export enregistre qui a exporté et quand. »
N'oubliez pas les chemins « non » : « Étant donné un utilisateur sans permission d'export, quand il essaie d'exporter, alors l'option est masquée ou bloquée, et aucun enregistrement d'export n'est créé. » Une ligne peut protéger à la fois la sécurité et l'intégrité des données.
Avant de traiter un ensemble de scénarios comme « terminé », relisez-le comme un utilisateur pointilleux et comme une base de données. Si vous ne pouvez pas dire ce qui doit être vrai avant le test, ou ce que « succès » signifie, ce n'est pas prêt.
Un bon ensemble est petit mais spécifique. Vous devriez pouvoir le confier à quelqu'un qui n'a pas écrit la fonctionnalité et obtenir les mêmes résultats. Utilisez cette vérification rapide pour approuver (ou renvoyer) les scénarios :
Si vous générez des scénarios dans un constructeur chat-based comme Koder.ai, tenez-le au même standard : pas de « marche comme attendu » vague. Demandez des sorties observables et des changements enregistrés, puis approuvez uniquement ce que vous pouvez vérifier.
Faites de la rédaction de scénarios une étape réelle de votre processus, pas une tâche de nettoyage à la fin.
Rédigez les scénarios avant le début de l'implémentation, tant que la fonctionnalité reste peu coûteuse à modifier. Cela force l'équipe à répondre aux questions gênantes tôt : ce que signifie « succès », ce qui arrive en cas de mauvaise entrée et ce que vous ne supporterez pas encore.
Utilisez les scénarios comme définition partagée du « done ». Product possède l'intention, QA possède la réflexion sur le risque, et engineering possède la faisabilité. Quand les trois lisent le même ensemble et sont d'accord, vous évitez d'envoyer quelque chose de « terminé » mais inacceptable.
Un workflow qui tient la route dans la plupart des équipes :
Si vous construisez dans Koder.ai (koder.ai), rédiger les scénarios d'abord puis utiliser Planning Mode peut vous aider à mapper chaque scénario aux écrans, règles de données et résultats visibles avant de générer ou d'éditer le code.
Pour les changements risqués, prenez un instantané avant de commencer à itérer. Si un nouveau cas limite casse un flux fonctionnel, la restauration peut vous sauver d'une journée de démêlage des effets secondaires.
Gardez les scénarios à côté de la demande de fonctionnalité (ou dans le même ticket) et traitez-les comme des exigences versionnées. Quand les prompts évoluent, l'ensemble de scénarios doit évoluer avec eux, sinon votre notion de « terminé » dérivera en silence.
Commencez par une phrase qui exprime l'objectif utilisateur et la ligne d'arrivée.
Puis décomposez le prompt en :
Ensuite, rédigez 1–2 parcours nominaux puis 4–8 cas limites qui correspondent aux risques réels (permissions, doublons, timeouts, données manquantes).
Parce que les prompts cachent des hypothèses. Un prompt peut dire « enregistrer », sans définir si cela signifie brouillon vs publié, ce qui se passe en cas d'échec, ou qui est autorisé à le faire.
Les scénarios vous obligent à nommer les règles tôt, avant d'envoyer des bugs comme les soumissions en double, les désaccords de permissions ou les résultats incohérents.
Utilisez Given–When–Then lorsque la fonctionnalité a de l'état et de l'interaction utilisateur.
Utilisez un tableau simple entrée/sortie quand vous avez beaucoup de cas de règles similaires.
Choisissez un format pendant un mois et standardisez-le (même temps, même niveau de détail). Le meilleur format est celui que votre équipe utilisera réellement.
Un bon scénario :
Il est « terminé » quand n'importe qui peut l'exécuter et s'accorder sur le résultat sans débat.
Concentrez-vous sur le comportement observable :
Évitez les détails d'implémentation tels que tables de base de données, codes de réponse d'API, jobs en arrière-plan ou frameworks. Ces détails évoluent souvent et ne prouvent pas que l'utilisateur a obtenu le résultat attendu.
Écrivez le parcours le plus ennuyeux et normal où tout se passe bien :
Puis vérifiez quatre points : bon écran/état, message de succès clair, données enregistrées, et possibilité pour l'utilisateur de continuer.
Choisissez les cas limites selon le risque et la fréquence :
Visez , pas chaque variation possible.
Restez sûr et clair :
Un scénario d'échec doit prouver que le système ne corrompt pas les données ni n'induit en erreur l'utilisateur.
Considérez la sortie de Koder.ai comme n'importe quelle autre app : testez ce que vit l'utilisateur, pas comment le code a été généré.
Approche pratique :
Stockez-les là où le travail a déjà lieu et conservez une source de vérité :
Si vous utilisez Koder.ai, gardez les scénarios en Planning Mode pour qu'ils restent liés à l'historique de build. Surtout : exigez les scénarios avant que le développement soit considéré comme commencé.
