Utilisez ce modèle
Une documentation de tests solide est le socle de toute pratique d’ingénierie de qualité. Avec Trupeer, vous pouvez gagner des heures sur la rédaction de vos documents de tests en commençant par des modèles de documentation de tests gratuits, en les personnalisant avec vos directives de marque, puis en transformant les plans de test en visites vidéo qui alignent l’ingénierie, le produit et le QA.
Quels sont les modèles de documentation de tests gratuits ?
Les modèles de documentation de tests gratuits sont des structures réutilisables pour les documents produits par un effort de test : la stratégie, le plan, les cas de test, les données, les résultats et les rapports de défauts.
La plupart des recherches à leur sujet sont en réalité des recherches d’un seul document. Les cas de test sont ce que les testeurs passent leur temps à rédiger, et un modèle de cas de test est un tableau contenant des étapes, ce qui n’a rien de difficile.
Les modèles ne sont pas le problème. Chaque modèle de cas de test publié comporte les mêmes colonnes : identifiant, titre, préconditions, étapes, résultat attendu, résultat réel, statut. Cette structure est correcte et elle est stable depuis des décennies.
Ce qui pose problème dans la plupart des suites de tests, c’est l’équilibre des efforts à l’intérieur de cette structure, et cela produit des cas de test qui peuvent passer alors que le système est cassé.
La forme suit l’usage. Un téléchargement gratuit d’un modèle de cas de test Excel est le format de travail le plus courant et convient bien au tableau de cas. Un fichier Word de modèle de cas de test convient aux plans de test et aux stratégies, qui sont rédigés en prose. Un exemple de document de test au format PDF est ce qui est joint à un enregistrement de version comme preuve.
Les documents d’un ensemble de tests
Six documents, chacun répondant à une question différente, et il vaut la peine de savoir lesquels vous avez réellement besoin avant d’adopter quoi que ce soit.
Stratégie de test. Comment cette organisation teste, en général. Rédite une fois, révisée rarement, appliquée à l’ensemble des projets.
Plan de test. Ce qui sera testé pour cette version ou ce projet, dans quels environnements, par qui, avec quels critères d’entrée et de sortie et quel calendrier.
Cas de test. Les vérifications individuelles. Des étapes et, surtout, des résultats attendus.
Scripts de test. L’équivalent automatisé, lorsqu’un cas a été codé plutôt qu’exécuté par une personne.
Données de test. Les données sur lesquelles les cas sont exécutés : c’est une documentation à part entière, et c’est souvent la partie la moins contrôlée de l’ensemble.
Résultats de test et rapports de défauts. Ce qui s’est passé, et ce qui a été remonté. C’est généralement ce qu’un exemple de document de cas de test au format PDF devient lorsqu’on en trouve un publié, puisque les résultats sont la partie que les organisations conservent.
Tout pack de modèles de documentation de tests doit couvrir les six, et la plupart en couvrent deux. La plupart des organisations ont le troisième et le sixième, et improvisent le reste. C’est acceptable. Ce qui ne l’est pas, c’est d’écrire mal le troisième, car tout ce qui suit en dépend.
Comment personnaliser ce modèle dans Trupeer
Étape 1 : Ouvrir la section Modèles
Accédez à la section Modèles depuis la navigation principale.
Étape 2 : Sélectionner et ouvrir un modèle
Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.
Étape 3 : Développer l’affichage du modèle
Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.
Étape 4 : Modifier le modèle
Cliquez sur Modifier pour commencer à modifier le modèle sélectionné.
Dans l’éditeur, vous pouvez :
Ajouter de nouvelles sections
Définir ou mettre à jour des règles de mise en forme
Ajouter un logo et ajuster sa position ainsi que les paramètres associés
Étape 5 : Enregistrer votre modèle personnalisé
Après avoir effectué toutes les modifications nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.
Étape 6 : Aperçu et ajustements fins du modèle
Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.
Depuis l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.
Avec les modèles de documentation de tests, vous pouvez :
Gagner du temps sur la rédaction : ignorez la page blanche avec des structures utilisées par des équipes QA expérimentées.
Améliorer la couverture des tests : des sections intégrées garantissent qu’aucun élément important n’est oublié.
Rester conforme à votre marque : appliquez votre logo, vos polices et vos couleurs grâce au kit de marque de Trupeer.
Standardiser entre les produits : utilisez les mêmes modèles pour chaque version et chaque équipe.
Rester prêt pour l’audit : aligné sur IEEE 829, ISO 29119 et des standards similaires.
Toucher des équipes internationales : traduisez votre documentation de tests en 65+ langues en un clic.
Le résultat attendu correspond au cas de test
Lisez n’importe quelle suite de tests et regardez où se trouvent les mots.
Les étapes seront détaillées. Ouvrez l’application. Accédez à l’écran des paiements. Sélectionnez la transaction. Cliquez sur Rembourser. Saisissez le montant. Confirmez. Sept instructions précises, chacune sans ambiguïté.
Puis regardez le résultat attendu. Il dira quelque chose comme : le remboursement est traité avec succès.
Cette ligne, c’est tout le test. Tout ce qui se trouve au-dessus sert de configuration. Et c’est la ligne qui a reçu le moins de réflexion, car rédiger des étapes précises est facile et définir ce que signifie « correct » est difficile.
La conséquence est qu’un testeur suit sept instructions exactes, voit quelque chose qui ressemble à un succès, puis coche « pass ». Il n’a rien fait de mal. Le document demandait si le remboursement avait été traité avec succès : ils ont vu un message de succès, et c’était le cas.
Ce que le document n’a jamais demandé, en revanche, c’est si exactement un remboursement avait été créé, si le grand livre avait bougé exactement du bon montant, ou si quoi que ce soit en aval avait reçu un doublon.
Un cas de test dont le résultat attendu peut être satisfait par une lecture optimiste de l’interface est un cas de test qui passera chaque fois que le testeur est pressé, ce qui est le cas la plupart du temps juste avant une version.
Rédiger un résultat attendu qui peut échouer
Trois propriétés, et elles sont faciles à vérifier sur une suite existante.
Il nomme un état, pas une impression. Pas « l’enregistrement se fait correctement », mais « l’enregistrement apparaît dans la liste avec le statut Actif et un horodatage de modification datant de la dernière minute ».
Il est vérifiable en dehors de l’élément qui a exécuté l’action. C’est cette propriété qui repère les défauts coûteux. Si l’action a eu lieu dans l’interface utilisateur, le résultat attendu le plus solide est une vérification ailleurs : dans la base de données, dans un rapport, dans le système en aval, sur un relevé. Les interfaces sont bonnes pour signaler un succès et mauvaises pour indiquer ce qui s’est réellement passé en dessous.
Il pourrait échouer sans que le système ait l’air cassé. Si la seule façon d’échouer le test est une erreur visible, le test ne détecte que les erreurs qui se manifestent. Une erreur silencieuse, c’est ce que les cas de test existent pour détecter, et ce que des résultats attendus vagues ratent de manière fiable.
Un audit pratique, qui prend un après-midi sur une suite de quelques centaines. Lisez uniquement les résultats attendus, en ignorant les étapes. Comptez combien pourraient être satisfaits en regardant l’écran seul, et combien utilisent des mots comme correctement, avec succès, comme prévu ou sans erreur, qui ne sont pas des résultats du tout. Dans la plupart des suites, les deux nombres sont élevés.
Ce qu’un modèle de cas de test doit contenir
Neuf champs. Le modèle n’est pas le problème, et la consigne contre deux de ces champs non plus.
Champ | À quoi il sert |
|---|---|
Identifiant | Stable, jamais réutilisé, pour que les cas puissent être référencés dans les rapports de défauts et les discussions sur la couverture. |
Titre | Ce qui est testé, en une phrase que quelqu’un pourrait rechercher. |
Priorité | Parce que personne n’exécute jamais toute la suite, et si vous ne choisissez pas, celui ou celle qui est sous pression le fera. |
Préconditions | État, données et accès requis avant l’étape une. |
Étapes | Une action chacune. La partie facile. |
Résultat attendu | Ce qui doit être vrai, où le vérifier, et formulé de façon à pouvoir échouer. Le test complet. |
Résultat réel | Ce qui a été observé, rempli pendant l’exécution, pas une coche. |
Statut | Pass, fail, bloqué, non exécuté. Bloqué et non exécuté sont différents, et les fusionner masque les écarts de couverture. |
Preuve | Capture d’écran, sortie de requête, référence. Tout ce qui montre le résultat réel plutôt que de l’affirmer. |
La distinction entre bloqué et non exécuté compte plus qu’elle n’en a l’air. Une suite qui affiche quatre-vingt-dix pour cent de pass peut n’avoir exécuté que soixante pour cent de ses cas, et la différence est invisible si tout ce qui n’a pas passé est enregistré de la même manière.
Modèles de documentation de tests gratuits : la structure à copier
Remplis avec un exemple réel plutôt que des placeholders. Le système est une plateforme de traitement des paiements.
Copiez depuis ici.
Plan de test, en résumé. Périmètre : traitement des remboursements pour la version 4.9. Dans le périmètre : remboursements complets, remboursements partiels, remboursements sur des transactions réglées et non réglées. Hors périmètre : les contestations (chargebacks), inchangées. Environnements : staging avec des volumes de données similaires à la production. Critères d’entrée : build déployé, test smoke réussi, données de test chargées. Critères de sortie : tous les cas de priorité un ont passé, aucun défaut de priorité un ou deux n’est ouvert, rapprochement du grand livre (ledger) propre sur l’ensemble de l’exécution.
Cas de test.
Identifiant : TC-118. Titre : Un remboursement complet sur une transaction réglée crée exactement une entrée de remboursement.
Priorité : Un.
Préconditions : le compte marchand M-4471 existe avec une transaction réglée T-88210 de 240,00. Solde du grand livre pour M-4471 enregistré avant le démarrage. Le testeur dispose des autorisations de remboursement.
Étapes.
Ouvrez l’écran des paiements et recherchez T-88210.
Sélectionnez la transaction et choisissez Rembourser.
Saisissez 240,00 et confirmez.
Résultat attendu. Quatre conditions, toutes doivent être remplies.
Un enregistrement de remboursement existe pour T-88210, et un seul. Vérifié dans le tableau des remboursements, pas dans l’interface.
Le solde du grand livre marchand pour M-4471 a diminué exactement de 240,00 par rapport à la valeur de départ enregistrée. Vérifié dans le rapport du grand livre.
Le relevé marchand de la période affiche une seule ligne de remboursement de 240,00.
Le statut de la transaction affiche Remboursé dans l’interface.
Notez que la vérification dans l’interface est la dernière et la plus faible des quatre. Elle est incluse parce que les utilisateurs la voient, pas parce qu’elle vérifie quoi que ce soit.
Résultat réel : enregistré lors de l’exécution, avec les chiffres du grand livre observés plutôt que supposés.
Statut : pass, fail, bloqué ou non exécuté.
Preuve : sortie de requête du tableau des remboursements et une copie de la ligne du rapport du grand livre.
Rapport de défaut, si le test échoue. Identifiant du cas, ce qui était attendu, ce qui a été observé, environnement, build, données utilisées, étapes pour reproduire, sévérité. Le champ « données utilisées » est celui qui est le plus souvent omis et celui qui empêche le plus souvent la reproduction.
Copiez ici.
Exemple de documentation de tests : trois cent trente-huit pass
Brayford Payments traite les paiements par carte pour de petits commerçants et emploie environ deux cents personnes. Elle a publié un flux de remboursement révisé.
Le module paiements comptait trois cent quarante cas de test. Les tests d’acceptation utilisateur ont exécuté toute la suite. Trois cent trente-huit ont passé. Deux ont échoué, ont été corrigés, puis ont été retestés.
En production, les remboursements au-dessus d’une certaine valeur étaient appliqués deux fois sous une condition de timing particulière. Cela a tourné pendant neuf jours avant que quelqu’un ne s’en aperçoive, générant environ quatorze cents remboursements en double d’une valeur de quatre cent douze mille livres. Récupérer l’argent déjà versé aux commerçants a été lent et compliqué, et environ soixante pour cent est revenu.
Le cas TC-118 couvrait les remboursements. Il comportait sept étapes détaillées et un résultat attendu formulé ainsi : le remboursement est traité avec succès.
Le testeur a suivi les sept étapes, a vu un message de confirmation et un statut Remboursé, puis a enregistré un pass. C’était une application correcte du document sous ses yeux.
Personne n’a regardé le grand livre. Rien dans le cas ne leur demandait de le faire. Un remboursement unique et un remboursement double se ressemblent exactement sur l’écran de confirmation, c’est précisément pour cela que la vérification devait se faire ailleurs.
L’audit ensuite a lu tous les trois cent quarante résultats attendus, en ignorant les étapes.
Deux cent onze pouvaient être satisfaits en observant uniquement l’interface utilisateur. Quarante-sept ne contenaient aucune déclaration vérifiable, en utilisant des formulations comme fonctionne comme prévu, se comporte correctement ou se termine sans erreur.
La solution a été trois semaines de réécriture, pas de nouveaux tests. Chaque résultat attendu devait nommer un état, indiquer où il était vérifié, et pouvoir échouer sans erreur visible. Là où la vérification naturelle se faisait en dehors de l’interface, c’est là qu’elle a été déplacée. Certains cas ont fusionné et la suite est descendue à deux cent quatre-vingt-dix.
Deux versions plus tard, les défauts trouvés pendant les tests d’acceptation utilisateur étaient passés d’une moyenne de quatre par version à dix-neuf.
Cette hausse est le résultat. Les défauts en production sur les six mois suivants sont passés de onze à deux.
La suite n’était pas trop petite. Elle posait trois cent quarante questions que le système pouvait satisfaire de manière optimiste.
Comment rédiger des cas de test en six étapes
Rédigez le résultat attendu avant les étapes. Cela inverse l’ordre habituel et vous oblige à décider ce que signifie « correct » avant de décrire comment y parvenir. Les étapes rédigées ensuite sont plus courtes et plus pertinentes.
Indiquez où le résultat est vérifié. Interface, base de données, rapport, système en aval. Nommer l’emplacement rend un résultat vérifiable par quelqu’un d’autre.
Demandez comment cela pourrait passer tout en étant faux. Si vous pouvez répondre, le résultat attendu doit inclure une autre condition.
Puis rédigez les étapes, une action chacune. Ce sont les parties faciles et elles doivent prendre le moins de temps.
Enregistrez les préconditions, y compris les données. La plupart des échecs de reproduction d’un défaut viennent de données différentes plutôt que d’étapes différentes.
Priorisez honnêtement. Personne n’exécute toute la suite avant une version. Décider à l’avance quels cas comptent est mieux que décider à neuf heures du soir, la veille, au moment où tout le monde est sous pression.
L’étape une, c’est toute la méthode. Les étapes deux et trois sont celles qui détectent les défauts qui atteignent la production.
Cas de test vs scénarios de test
Les deux sont utilisés de manière interchangeable, et la différence est un niveau.
Un scénario de test décrit quoi tester, à un niveau que n’importe qui peut comprendre. Vérifiez que les remboursements fonctionnent correctement pour les transactions réglées. C’est une déclaration de couverture.
Un cas de test explique comment le tester, avec des données spécifiques, des étapes spécifiques et un résultat attendu spécifique. Un scénario produit généralement plusieurs cas.
La discipline utile consiste à écrire d’abord des scénarios, à valider la couverture avec des personnes qui comprennent le métier, puis à écrire les cas en dessous. Faire l’inverse produit une suite qui couvre tout ce que la personne qui l’a rédigée a eu l’idée de penser.
Un scénario qui ne produit qu’un seul cas est généralement un scénario qui n’a pas été correctement réfléchi. Les remboursements pour des transactions réglées doivent produire des cas pour le montant total, un montant partiel, un montant supérieur à l’original, une deuxième tentative de remboursement sur la même transaction, et un remboursement sur une transaction déjà remboursée. Quatre de ces cinq cas sont là où vivent les défauts.
Stratégie de test, plan de test et plan QA
Trois documents au-dessus des cas de test, et les distinctions ont un poids pratique.
Une stratégie de test est organisationnelle et durable. Comment nous testons, quels types de tests nous utilisons, quels sont nos standards. Elle s’applique à l’ensemble des projets et est révisée rarement.
Un plan de test est spécifique à une version ou à un projet. Périmètre, environnements, critères d’entrée et de sortie, calendrier, ressources, risques. Un téléchargement gratuit d’un modèle Excel de plan de test vous donnera un calendrier et une matrice, et les sections en prose appartiennent à un document.
Un plan QA est plus large que les deux autres, car l’assurance qualité inclut tout ce qui est fait pour prévenir les défauts plutôt que pour les trouver : revue des exigences, définition du « done », standards de revue de code, parité des environnements. Le modèle de plan QA couvre cette distinction, et c’est important ici parce qu’un document intitulé « plan QA » qui ne contient que des phases de test est devenu, en silence, un plan de test.
Le test pratique, c’est le timing. Les activités qui se produisent avant que le travail soit terminé sont de l’assurance. Celles qui se produisent après sont du contrôle, et les tests sont du contrôle.
Ce que les modèles de documentation de tests gratuits ne peuvent pas corriger
Des exigences sur lesquelles personne n’est tombé d’accord. Un cas de test vérifie un comportement par rapport à une attente, et lorsque l’attente n’a jamais été clarifiée, les testeurs rédigent des cas basés sur leur propre hypothèse.
Une suite trop grande pour être exécutée. Chaque organisation arrive au point où la suite de non-régression complète ne tient pas dans la fenêtre. Prioriser délibérément vaut mieux que prioriser sous pression, et aucun téléchargement gratuit d’un modèle Excel de cas de test ne le fera à votre place.
Un résultat attendu vague. Aucun modèle de cas de test : téléchargement gratuit et aucun modèle simple de cas de test au format Excel ne vous l’écrira à votre place, et c’est le seul champ qui décide si le cas fonctionne.
Des données de test qui ne représentent pas la production. Le défaut de Brayford nécessitait une condition de timing particulière et un volume de données réaliste. Ni l’un ni l’autre n’existait dans l’environnement de test, et aucun modèle ne traite cela.
Des testeurs sans autorité pour bloquer. Des critères de sortie qui peuvent être levés par quiconque veut expédier ne sont pas des critères.
Montrer le test plutôt que le décrire
Deux problèmes dans ce domaine sont le même problème, et les deux concernent les preuves.
Les preuves de test sont normalement une coche dans une colonne de statut. Quelqu’un a exécuté le cas et dit qu’il a passé. Si un défaut apparaît plus tard dans cette zone, il n’y a aucun moyen d’établir ce qui a réellement été observé, donc la question de savoir si le cas a été exécuté correctement ne peut pas être répondue et se transforme généralement en débat.
Le deuxième problème est qu’un nouveau testeur qui rejoint une équipe apprend ce que signifie « vérifier correctement » en regardant quelqu’un, et si personne n’a le temps, il l’apprend à partir des documents, c’est là que vient la lecture optimiste.
Trupeer AI répond aux deux. L’enregistrement d’une exécution de test produit une visite guidée écrite avec des captures d’écran déjà capturées et placées, en plus de la vidéo, dans votre propre branding. Ce qui a réellement été observé à chaque étape est capturé plutôt qu’affirmé : c’est la preuve dont un enregistrement de version a besoin, et la matière à partir de laquelle un nouveau testeur apprend.
Enregistrez-le. Mettez-le en marque. Traduisez-le. Trupeer it.
Deux points suivent. L’enregistrement d’un testeur expérimenté exécutant un cas complexe montre les vérifications qu’il effectue en dehors de l’interface, exactement l’habitude que les cas rédigés n’arrivent pas à transmettre. Et lorsque les tests sont réalisés sur plusieurs sites ou par une équipe externalisée, le même enregistrement définit la même norme de vérification plutôt que de la laisser à l’interprétation.
Le contenu se trouve dans votre base de connaissances et sert aussi de formation pour les nouveaux testeurs. La question de savoir si la version peut être expédiée du tout est une question distincte, couverte dans le modèle de critères de version. La cohérence entre vos documents dépend du fait de définir le kit de marque une fois, et la configuration est couverte dans le guide de configuration du modèle de document.
Questions fréquentes
Existe-t-il un téléchargement gratuit d’un modèle Excel de cas de test ?
Excel est le format de travail standard pour les cas de test et leur convient très bien, car une suite est un tableau que vous filtrez par module, priorité et statut. Un téléchargement gratuit d’un modèle Excel de cas de test vous donnera les colonnes standard et constitue vraiment un bon point de départ.
Deux ajouts valent la peine d’être faits. Une colonne qui enregistre où le résultat attendu est vérifié, c’est-à-dire l’interface, la base de données, le rapport ou le système en aval. Et des valeurs de statut distinctes pour bloqué et non exécuté, car les fusionner masque la part réelle de la suite qui a été exécutée.
Existe-t-il une version simple du modèle Excel de cas de test ?
Oui, et le simple est généralement la bonne option. Une mise en page simple de modèle Excel de cas de test avec identifiant, titre, priorité, préconditions, étapes, résultat attendu, résultat réel et statut couvre presque tout.
Résistez à l’ajout de colonnes. Les modèles de cas de test accumulent des champs qui semblent utiles au moment de la conception et restent vides en pratique, et une suite avec huit colonnes remplies est plus utile que celle avec vingt colonnes dont douze sont vides.
Existe-t-il une version Word du modèle de cas de test ?
Word convient aux documents qui entourent les cas, plutôt qu’aux cas eux-mêmes. Un fichier Word de modèle de cas de test fonctionne pour un plan de test, une stratégie de test ou un rapport récapitulatif, qui sont tous rédigés en prose.
Pour les cas eux-mêmes, un document est un mauvais choix. Vous ne pouvez pas le filtrer, vous ne pouvez pas trier par priorité, et mettre à jour le statut sur deux cents cas dans un tableau Word pendant une exécution de test est suffisamment lent pour que les gens finissent par ne plus le faire correctement.
Existe-t-il un modèle de cas de test : un téléchargement gratuit qui vaut le coup d’être utilisé ?
Les colonnes sont stables depuis des décennies, donc un modèle de cas de test : un téléchargement gratuit ne vous fait gagner que très peu, et chaque version publiée est globalement la même.
Évaluez n’importe lequel d’entre eux sur une seule question. La colonne « résultat attendu » contient-elle des indications, ou s’agit-il simplement d’une cellule vide ? La cellule vide est là où la plupart des suites de tests se trompent, et aucun modèle ne le résout, mais un modèle qui invite à indiquer où le résultat est vérifié améliorera ce qui sera écrit dans cette colonne.
Existe-t-il un téléchargement gratuit d’un modèle Excel de plan de test ?
Excel convient au calendrier, à la matrice de couverture et au plan des ressources dans un plan de test. Un téléchargement gratuit d’un modèle Excel de plan de test vous donnera généralement cela.
La partie narrative appartient à un document : périmètre, critères d’entrée et de sortie, environnements, hypothèses et risques. Ceux-ci sont lus et négociés, et négocier dans des cellules de tableur se passe mal. Conservez les deux, et faites référence à l’un depuis l’autre.
Où puis-je trouver un exemple de document de test au format PDF ?
Les documents publics de passation de marchés, les projets universitaires et certains organismes de normalisation publient de la documentation de tests réelle, et un exemple de document de test au format PDF provenant de l’une de ces sources est plus instructif qu’un modèle commercial, car il a été produit avec de vraies contraintes.
Lisez un exemple de document de cas de test au format PDF pour ses résultats attendus plutôt que pour sa structure. La structure se transfère depuis n’importe où. La façon dont une équipe réelle a formulé ce que signifie « correct », et si leurs vérifications se situaient en dehors de l’interface, c’est la partie qui vaut la peine d’être apprise.
Où puis-je trouver un exemple de document de cas de test au format PDF ?
Les mêmes sources s’appliquent, et les secteurs réglementés sont les plus riches, car les preuves de test doivent y survivre à l’audit et sont généralement rédigées de manière plus précise en conséquence.
Lorsque vous lisez un exemple de document de cas de test au format PDF, regardez si la colonne « résultat réel » contient des observations ou des coches. Les coches vous indiquent que la suite a été exécutée. Les observations vous disent ce qui a été vu, et seule la deuxième est une preuve.
Existe-t-il un ensemble de modèles de documentation de tests logiciels ?
Oui, et l’ensemble comprend six documents : stratégie, plan, cas, scripts, données et résultats avec des rapports de défauts. Un pack de modèles de documentation de tests logiciels couvre généralement le plan et les cas, et laisse le reste.
Les données de test sont le champ le plus souvent manquant et celui qui empêche le plus souvent qu’un défaut soit reproduit. Documenter sur quelles données la suite s’exécute et comment elles sont mises à jour vaut autant que cinquante autres cas de test.
