Générateur et modèle de plan de test
Neuf champs en entrée, un plan de test Markdown en six sections en sortie, plus une vérification face aux quatre choses qui séparent un vrai plan d'un modèle rempli.
Périmètre, approche, environnements, critères, risques — un élément par ligne, et la sortie est un plan que vous pouvez coller partout où Markdown s'affiche.
Ouvrir l'outil — gratuit, sans inscriptionCe que fait cet outil
Vous entrez le nom de la fonctionnalité et la release, puis sept champs de liste : dans le périmètre, hors périmètre, approche de test, environnements, risques, critères d'entrée et critères de sortie. La sortie est un plan à six sections numérotées, daté à la génération. Les champs vides sont marqués à définir plutôt que discrètement supprimés, pour que les manques restent visibles. Quatre vérifications qualité tournent en parallèle : hors-périmètre énoncé, risques nommés, critères de sortie définis, et une approche de plus d'une ligne.
Ce qui va dans chaque section
Dans le périmètre est ce que vous allez tester, au niveau fonctionnalité, pas au niveau cas de test. « Flux panier vers paiement », « checkout invité », « application de code promo » — trois lignes, pas trente.
Hors périmètre est la section que les gens sautent et celle qui compte le plus. Nommer ce que vous ne testez délibérément pas, et pourquoi, fixe les attentes avant la release plutôt que pendant la revue d'incident. « Intégration PayPal legacy — dépréciée au Q4. » « Test de charge — appartient à l'équipe plateforme. » Quand quelque chose casse dans une zone que vous avez exclue, cette section est la différence entre une conversation et une attribution de blâme.
L'approche de test est comment vous allez tester chaque zone, et elle devrait nommer plus d'une couche. Un plan qui dit seulement « automatisation UI » se lit comme inexpérimenté. Une approche crédible mélange les couches : régression au niveau API sur le service de paiement, smoke UI sur le chemin critique, une session exploratoire sur les cas limites de code promo. Le but est de montrer que vous avez choisi la couche la moins chère capable d'attraper chaque classe de défaut.
Les critères d'entrée sont ce qui doit être vrai avant le début des tests — déployé en staging, tests unitaires verts, données de test seedées. Sans eux, les tests commencent sur un build cassé et le planning glisse pour des raisons que personne n'a enregistrées.
Les critères de sortie sont ce qui doit être vrai pour le déclarer fini : aucun défaut critique ou haut ouvert, 95 pour cent des cas prévus exécutés. Sans eux, le « fini » est une question d'opinion — et l'opinion qui gagne appartient au plus senior de la salle le jour de la release.
Risques et mitigations sont les choses précises qui pourraient dérailler cet effort de test, avec ce que vous ferez pour chacune. « La sandbox de paiement est instable — mockez la passerelle pour la régression, n'utilisez la sandbox que pour les deux confirmations end-to-end. » Un plan sans risques dit aux parties prenantes que vous n'avez pas assez réfléchi.
Erreurs courantes
Laisser le hors-périmètre vide. Le marqueur le plus fort d'un plan senior, et le plus facile à remplir.
Des critères de sortie qu'on ne peut pas évaluer. « La fonctionnalité est stable » n'est pas un critère. « Aucun défaut critique ou haut ouvert, et la suite de régression de paiement passe trois runs consécutifs » en est un.
Une approche à une seule couche. Tout à travers l'UI est lent, instable et coûteux. Dites ce que vous poussez vers les couches API et unitaire.
Confondre un plan de test avec une stratégie de test. La stratégie est l'approche permanente de l'équipe à travers les projets ; un plan, c'est cette fonctionnalité, cette release, ces critères.
Le générateur tourne entièrement dans votre navigateur — rien de ce que vous tapez ne quitte la page. Un vrai plan pour une vraie fonctionnalité, dans un dépôt public, est aussi l'un des plus forts artefacts d'entretien que vous pouvez construire : en montrer un bat en décrire un.
Questions fréquentes
Comment écrire un plan de test ?
Définissez ce qui est dans le périmètre et explicitement ce qui en est hors. Énoncez votre approche par zone, en nommant plus d'une couche de test. Listez les environnements, les critères d'entrée qui doivent tenir avant le début des tests, les critères de sortie qui définissent le « fini », et les risques avec votre mitigation pour chacun.
Quelle est la différence entre un plan de test et une stratégie de test ?
Une stratégie de test est l'approche permanente de l'organisation face aux tests, à travers les projets — couches, outillage, standards. Un plan de test applique cette stratégie à une fonctionnalité ou une release, avec un périmètre, des environnements, des critères et des risques précis. La stratégie change rarement ; les plans s'écrivent par release.
Que devrait contenir les critères de sortie ?
Des conditions qui peuvent être évaluées objectivement : aucun défaut critique ou haut ouvert, un pourcentage d'exécution des cas prévus, l'automatisation du chemin critique qui passe, une performance dans un seuil convenu. Si un critère a besoin de l'avis de quelqu'un pour être évalué, réécrivez-le.
Les petites équipes ont-elles besoin d'un plan de test ?
Pour les changements de routine, non. Pour tout ce dont le périmètre est contesté, où plusieurs personnes sont impliquées, ou où un tiers est dans la boucle, un plan d'une page évite la dispute sur ce qui était censé être couvert. La longueur n'est pas le sujet ; les sections hors-périmètre et sortie le sont.