Génération de cas de test
Produire en 15-30 minutes un plan de test exhaustif (happy-path + edge cases) à partir d'une user story.
La génération de cas de test est une des activités les plus rentables où injecter l'IA dans le flow QA. À partir d'une user story, l'IA peut produire en quelques minutes 20-50 cas de test couvrant les comportements attendus, les cas limites et les erreurs. Le QA garde la valeur centrale : prioriser, exécuter, identifier les bugs réels que l'IA n'a pas pensé à tester. Ce guide présente le workflow.
Workflow étape par étape
Soumettre la user story et le contexte
Story + critères d'acceptation + contexte technique (API, UI, mobile). Plus le contexte est riche, plus les cas générés sont pertinents.
Demander 4 catégories de cas
Happy-path (3-5 cas), edge cases (5-10), erreurs et invalid inputs (5-10), tests de régression (3-5). Couverture systématique sans oublis.
Hiérarchiser par priorité
L'IA produit beaucoup ; le QA priorise. Critères : impact business, fréquence d'usage, criticité. Top 20% des cas couvrent souvent 80% des bugs réels.
Convertir au format outil
Selon votre stack : Gherkin pour Cucumber, format TestRail/Xray, ou simplement liste markdown. L'IA peut convertir entre formats.
Maintenir au fil de l'évolution
À chaque évolution de la feature : faire actualiser les cas de test. C'est ce qui rend le test vivant plutôt que dette.
Prompts copiables
3 prompts testés et optimisés. Adaptez les variables entre crochets [VARIABLE] à votre contexte.
Plan de test depuis user story
Tu es QA senior. Génère un plan de test pour cette user story : **User story** : [STORY] **Critères d'acceptation** : [LISTE] **Stack technique** : [WEB / MOBILE / API] **Contexte projet** : [INFOS UTILES] Produis : 1. **Happy-path** (3-5 cas) : comportement nominal 2. **Edge cases** (5-10) : valeurs limites, états vides, premiers usages, comptes désactivés, permissions partielles 3. **Cas d'erreur** (5-10) : invalid inputs, timeouts, network errors, conflits concurrence, données manquantes 4. **Tests de régression** (3-5) : impact possible sur features existantes Format : pour chaque cas — (a) ID, (b) titre, (c) prérequis, (d) étapes, (e) résultat attendu, (f) priorité (critique/haute/moyenne/basse). Marque [À VALIDER] tout cas dépendant d'un comportement non spécifié.
Génération format Gherkin
Convertis ces cas de test en Gherkin (Cucumber/SpecFlow) :
[CAS DE TEST]
Format attendu :
```gherkin
Feature: [NOM]
Background:
Given [ÉTAT INITIAL COMMUN]
Scenario: [NOM SCÉNARIO]
Given [PRÉCONDITION]
When [ACTION]
Then [RÉSULTAT ATTENDU]
Scenario Outline: [NOM TABLE]
Given [...]
Examples:
| param1 | param2 | expected |
```
Respecte les bonnes pratiques : Background pour le commun, Scenario Outline pour les variations, naming clair.Test exploratoire ciblé
Pour cette feature :
[FEATURE]
Produis un plan d'exploration ciblé (60-90 min de test exploratoire) :
1. **Charters** (3-5) : missions d'exploration courtes ("explorer X pour découvrir Y dans Z")
2. **Tactiques** par charter : approches à utiliser (boundary testing, error guessing, persona-based)
3. **Risques cachés** : zones où des bugs sont probables vu le métier de l'app
4. **Questions à se poser** pendant l'exploration
5. **Format de notes** pour capitaliser les observations
Objectif : exploration structurée mais ouverte, qui trouve les bugs que les tests automatisés ne trouvent pas.Top outils pour ce cas d'usage
Sélection commentée des 3 meilleurs outils IA pour génération de cas de test.
Pourquoi pour ce cas d'usage : Le plus rigoureux pour la génération de cas exhaustifs avec edge cases bien anticipés.
Pourquoi pour ce cas d'usage : Pour générer en contexte projet : accès au code, aux conventions, aux fixtures existantes.
Pourquoi pour ce cas d'usage : Code Interpreter utile pour générer des datasets de test variés et tester rapidement des hypothèses.
ROI estimé
Temps gagné
70% sur la planification (15-30 min vs 1-2h)
Gain qualité
Couverture exhaustive des edge cases, format prêt pour outils QA
Coût stack
20-30€/mois
Estimations basées sur des benchmarks 2026 et retours d'utilisateurs. Le ROI réel dépend de votre contexte.
Questions fréquentes
Les cas de test générés sont-ils suffisants ?
Pour la couverture systématique : oui. Pour la créativité (cas vraiment improbables qui révèlent les bugs subtils) : moins. Bonne pratique : IA pour le 80% mécanique, exploration humaine pour les 20% restants.
L'IA peut-elle prioriser les cas de test ?
Pour une priorisation indicative basée sur la criticité technique : oui. Pour la priorisation business (impact financier d'un bug, segment client touché) : moins. Le QA arbitre selon le contexte.
Faut-il automatiser tous les cas générés ?
Non. Règle classique : 70% automatisés (régression, smoke), 20% manuels (exploration, UX), 10% hors scope. L'IA peut conseiller la répartition mais c'est un choix d'équipe.
L'IA améliore-t-elle vraiment la qualité ?
Indirectement : exhaustivité de la couverture, baisse des oublis. Indirectement aussi : libère du temps pour l'exploration et le test critique. Net : moins de bugs en prod, plus de confiance dans les releases.