Comment rédiger un scénario de test?
Pour rédiger un cas de test, commencez par sélectionner un outil, comme des feuilles de calcul Excel, pour vous aider à garder une trace du cas et de ses données associées. Ensuite, configurez un modèle qui comprend le nombre de cas de test, les procédures de test, les résultats attendus et les résultats réels. Ensuite, écrivez une instruction de cas de test de base qui inclut ce qui est testé, les conditions du test et ce qui est affiché. Enfin, passez en revue votre cas de test écrit. Pour savoir comment dire ce qui constitue un bon cas de test, continuez à lire!
Être conscient de ce qui constitue un bon scénario de test vous aidera à rédiger un scénario de test meilleur et plus solide.
Un cas de test en génie logiciel est une seule étape ou une série d'étapes pour vérifier le bon comportement / fonctionnalité de certaines fonctionnalités d'une application. Un cas de test détermine essentiellement si l'application ou le système logiciel fonctionne comme prévu. Le but de l'écriture de cas de test est d'aider à normaliser le processus de test et de minimiser les approches arbitraires ou ad hoc. Il peut prendre de nombreux cas de test pour vérifier qu'un système logiciel a été suffisamment examiné et examiné avant sa sortie.
Méthode 1 sur 2: se préparer à écrire un cas de test
- 1Vérifiez si un scénario de test existe déjà. Avant d'écrire un nouveau cas de test pour votre module, vérifiez s'il existe déjà des cas de test qui testent le même composant. Cela peut être un véritable gain de temps!
- Si vous trouvez des cas de test existants, envisagez de mettre à jour le cas de test plutôt que d'en écrire un nouveau.
- 2Connaître les caractéristiques d'un bon cas de test. Être conscient de ce qui constitue un bon scénario de test vous aidera à rédiger un scénario de test meilleur et plus solide. Ces caractéristiques comprennent:
- Précision: le test énonce clairement l'objectif.
- Tracing: Le test peut être tracé aux exigences.
- Répétition: Le test peut être utilisé pour faire le test autant de fois que nécessaire.
- Réutilisation: le test peut être réutilisé si nécessaire.
- Indépendance: chaque scénario de test que vous écrivez doit pouvoir être exécuté dans n'importe quel ordre, sans aucune dépendance vis-à-vis d'autres scénarios de test.
- Concision: La description d'un cas de test doit être simple et claire et ne comporter ni étapes ni mots superflus. Un testeur doit être capable de le comprendre en le relisant une fois. La description doit utiliser des mots d'action, comme "faire 'x'" et "faire 'y'."
Si vous trouvez des cas de test existants, envisagez de mettre à jour le cas de test plutôt que d'en écrire un nouveau. - 3Considérez les différents scénarios possibles avant d'écrire. Concentrez-vous sur ce qui pourrait arriver avec le produit lorsqu'il est utilisé par un client. Pensez-y attentivement et concevez vos tests en conséquence.
- Les scénarios doivent être concis. L'objectif d'un scénario de test n'est pas de fournir beaucoup de détails spécifiques, mais plutôt de transmettre une idée spécifique sur le test d'un cas particulier.
- 4Donnez-vous suffisamment de temps pour écrire. Étant donné que les scénarios et les cas constituent la base des futurs cas de test et des tests, vous devez vous donner suffisamment de temps pour rédiger un test de qualité ainsi que du temps pour revoir la procédure en profondeur.
Méthode 2 sur 2: rédaction d'un cas de test
- 1Sélectionnez un outil pour rédiger un cas de test. Les feuilles de calcul Excel sont fortement recommandées pour écrire des cas de test de base et pour les tester manuellement.
- Lorsque vous prévoyez d'automatiser des cas de test, obtenez la licence pour des outils tels que Test Director. Il existe également un certain nombre d'outils qui peuvent être téléchargés gratuitement sur Internet.
Indépendance: chaque scénario de test que vous écrivez doit pouvoir être exécuté dans n'importe quel ordre, sans aucune dépendance vis-à-vis d'autres scénarios de test. - 2Rédigez un cas de test avec l'outil que vous avez choisi. Cela vous permettra de garder une trace du cas et de ses données connexes. Un bon modèle comprend:
- Numéros de série: il s'agit du nombre de cas de test.
- ID de la suite de tests: il s'agit de l'ID de la suite de tests à laquelle appartient ce cas de test.
- ID du scénario de test: ID du scénario de test.
- Résumé du scénario de test: résumé ou objectif du scénario de test.
- Exigence connexe: ID de l'exigence à laquelle ce cas de test se rapporte / trace.
- Conditions préalables: il s'agit de toutes les conditions préalables ou préalables qui doivent être remplies avant d'exécuter le test.
- Procédure de test / étapes: Il s'agit de la procédure étape par étape pour exécuter le test. Soyez très détaillé et précis ici car c'est l'élément le plus important. Chaque étape peut être écrite très directement à l'aide de mots clés tels que «entrer», «vérifier», «cliquer», «se connecter», etc.
- Résultat attendu: résultat attendu du test. Lors de la rédaction des cas de test, notez la page / l'écran que vous prévoyez d'apparaître après le test.Vous pouvez également joindre des captures d'écran ou des documents de spécification à l'étape pertinente et noter que le système doit fonctionner comme indiqué pour aider à simplifier l'étape et le résultat escompté et à faire le processus plus facile à suivre pour le testeur.
- Résultat réel: il s'agit du résultat du test après son exécution.
- Statut: Il s'agit de l'état qui se produira dans le test, par exemple «Réussite» ou «Échec». Un autre état peut également être utilisé, tel que "Non exécuté" si le test n'est pas effectué et "Bloqué" si le test est bloqué.
- Remarques: Ici, vous pouvez ajouter des commentaires sur le scénario de test ou l'exécution du scénario de test.
- Créé par: il s'agit du nom du créateur du test.
- Date de création: il s'agit de la date à laquelle vous exécutez le test.
- Exécuté par: Il s'agit du nom de la personne qui a réellement effectué le test.
- Date d'exécution: la date à laquelle vous avez effectué le test.
- Environnement de test: les systèmes dans lesquels le texte a été exécuté. Ici, vous noterez, par exemple, le système d'exploitation et le navigateur Web que vous avez utilisés.
- 3Écrivez une instruction de cas de test de base. Il existe un format typique pour ces déclarations:
- Vérifiez [ce qui est testé].
- En utilisant [nom de l'outil, nom de la balise, boîte de dialogue, etc.] Au lieu de "utiliser", vous pouvez également utiliser "entrer" ou "sélectionner", selon la situation de votre cas de test particulier.
- Avec [conditions du test].
- À [ce qui est renvoyé, montré, démontré]
- 4Passez en revue le cas de test écrit. Votre travail n'est pas tout à fait terminé une fois que vous avez écrit le cas de test; vous devez toujours revoir tout ce qui a été écrit et évaluer que toutes les étapes sont claires et compréhensibles et que les résultats attendus correspondent à ces étapes.
- Vous pouvez examiner le cas vous-même et évaluer les lacunes ou les domaines manquants en vous mettant dans le rôle de testeur. Mais vous pouvez également faire examiner votre cas de test par des pairs testeurs (appelés `` examen par les pairs ''), des développeurs, des propriétaires de produits ou toute autre partie prenante.
Avant d'écrire un nouveau cas de test pour votre module, vérifiez s'il existe déjà des cas de test qui testent le même composant.
- Lors de l'écriture de cas de test, assurez-vous que tous vos cas de test doivent être simples et faciles à comprendre. Soyez concis, précis et allez droit au but immédiatement. N'écrivez pas un cas de test comme un essai.
- Écrivez votre cas de test avec suffisamment de détails pour qu'il puisse être remis à un nouveau membre de l'équipe ou à un collègue qui serait en mesure d'effectuer facilement le test et de localiser les zones problématiques.
Lisez aussi: Comment écrire un essai de style Chicago?
