test plan tutorial guide write software test plan document from scratch
Un guide ultime du document de plan de test logiciel:
Ce tutoriel vous expliquera tout sur le document de plan de test logiciel et vous guidera sur la façon d'écrire / créer un plan de test logiciel détaillé à partir de zéro avec le différences entre la planification des tests et l'exécution des tests.
Live Project QA Training Day 3 - Après avoir présenté à nos lecteurs l'application en direct de notre Formation en ligne gratuite sur les tests de logiciels , nous avons appris à connaître comment réviser SRS et écrire des scénarios de test . Et maintenant, c'est le bon moment pour plonger plus profondément dans la partie la plus importante du cycle de vie des tests logiciels - c.-à-d. Planification des tests .
Liste de TOUS les didacticiels de cette série:
Document de planification des tests:
Tutoriel n ° 1: Comment rédiger un document de plan de test (Ce tutoriel)
Tutoriel n ° 2: Contenu du modèle de plan de test simple
Tutoriel n ° 3: Exemple de plan de test logiciel
Tutoriel n ° 4: Différence entre le plan de test et la stratégie de test
Tutoriel n ° 5: Comment rédiger un document de stratégie de test
Conseils de planification de test:
Tutoriel n ° 6: Gestion des risques pendant la planification des tests
Tutoriel n ° 7: Que faire lorsqu'il n'y a pas assez de temps pour tester
Tutoriel n ° 8: Comment planifier et gérer efficacement les projets de test
Planification des tests à différentes étapes du STLC:
Tutoriel n ° 9: Planification des tests de régression
Tutoriel n ° 10: Plan de test UAT
Tutoriel n ° 11: Plan de test d'acceptation
Planification de l'automatisation des tests:
Tutoriel n ° 12: Plan de test d'automatisation
Tutoriel n ° 13: Planification des tests d'applications ERP
Tutoriel n ° 14: Planification des tests HP ALM
Tutoriel n ° 15: Planification des tests Mindmap
Tutoriel n ° 16: Plan de test JMeter et WorkBench
Ce que vous apprendrez:
- Création d'un plan de test - La phase de test la plus importante
- Planification des tests vs exécution des tests
Création d'un plan de test - La phase de test la plus importante
Ce didacticiel informatif vous expliquera les moyens et les procédures impliqués dans la rédaction d'un document de plan de test.
À la fin de ce tutoriel, nous avons partagé un Document de plan de test complet de 19 pages qui a été spécialement créé pour le projet live OrangeHRM, que nous utilisons gratuitement Série de formations sur l'assurance qualité
Qu'est-ce qu'un plan de test?
Test Plan est un document dynamique . Le succès d'un projet de test dépend d'un document de plan de test bien rédigé et à jour à tout moment. Le plan de test est plus ou moins comme un schéma directeur de l'activité de test se dérouler dans un projet.
Vous trouverez ci-dessous quelques conseils sur un plan de test:
#1) Le plan de test est un document qui sert de point de référence et qui se base uniquement sur le fait que les tests sont effectués au sein de l'équipe d'assurance qualité.
#deux) C'est aussi un document que nous partageons avec les Business Analysts, les chefs de projet, l'équipe de développement et les autres équipes. Cela permet d’améliorer le niveau de transparence du travail de l’équipe d’assurance qualité vis-à-vis des équipes externes.
# 3) Il est documenté par le responsable AQ / responsable AQ sur la base des contributions des membres de l'équipe AQ.
# 4) La planification des tests est généralement allouée avec 1/3rddu temps nécessaire à l'ensemble de l'engagement d'assurance qualité. L'autre 1/3rdest pour la conception de tests et le reste est pour l'exécution de tests.
# 5) Ce plan n'est pas statique et est mis à jour à la demande.
# 6) Plus le plan est détaillé et complet, plus l'activité de test sera réussie.
Processus STLC
Nous sommes maintenant à mi-chemin de notre série de projets en direct. Par conséquent, prenons du recul par rapport à l'application et jetons un coup d'œil au processus du cycle de vie des tests logiciels (STLC).
STLC peut être grossièrement divisé en 3 parties:
- Planification des tests
- Conception des tests
- Exécution des tests
Dans notre tutoriel précédent, nous avons appris que dans un projet d'AQ pratique, nous avons commencé par la révision SRS et l'écriture de scénario de test - qui est en fait la 2ème étape du processus STLC. La conception de test implique les détails sur ce qu'il faut tester et comment tester.
Pourquoi n'avons-nous pas commencé avec la planification des tests?
La planification est en effet la première et la plus importante activité qui se produit dans tout projet de test.
Planification des tests aux phases SDLC
Phase SDLC | Activité de planification des tests |
---|---|
Horaires => | Préparation du scénario de test |
Lancer | Idéalement, l'équipe d'AQ devrait s'impliquer pendant que la portée du projet est recueillie auprès du client / client sous la forme d'exigences commerciales. Mais dans le monde réel, ce n'est pas le cas. D'un point de vue pratique, l'implication de l'équipe QA est NUL. À la fin de cette phase, le BRD est finalisé et un plan de projet de base est créé. |
Définir | SRS est créé à partir de la BRD. L'ébauche initiale du plan de test est créée. À ce stade, étant donné que l'équipe d'AQ n'a pas terminé l'examen du SRS, la portée des tests n'est pas claire. Ainsi, le TP à cette phase ne contiendra que des informations sur le moment où les tests vont avoir lieu, les informations sur le projet et les informations sur l'équipe (si nous les avons). |
Conception | La revue SRS est effectuée et la portée des tests est identifiée. Nous avons beaucoup plus d'informations sur ce qu'il faut tester et une bonne estimation du nombre de cas de test que nous pourrions obtenir, etc. Une deuxième version du plan de test est créée en incorporant toutes ces informations. |
D'après le tableau ci-dessus, il est très clair qu'un plan de test n'est pas simplement un document que vous pouvez créer en une seule fois et l'utiliser à partir de là.
Composantes d'un document de plan
Éléments dans un modèle de plan de test | Que contiennent-ils? |
---|---|
Portée => | Scénarios de test / objectifs de test qui seront validés. |
Hors de portée => | Plus de clarté sur ce que nous n'allons pas couvrir |
Hypothèses => | Toutes les conditions qui doivent être réunies pour que nous puissions procéder avec succès |
Documentation de test - cas de test / données de test / environnement de configuration | |
Exécution des tests | |
Cycle de test - combien de cycles | |
Date de début et de fin des cycles | |
Rôles et responsabilités => | Les membres de l'équipe sont répertoriés |
Qui fait quoi | |
les propriétaires de modules sont répertoriés et leurs coordonnées | |
Livrables => | Quels documents (artefacts de test) vont produire à quels délais? |
Que peut-on attendre de chaque document? | |
Environnement => | Quels types d'exigences d'environnement existent? |
Qui va être responsable? | |
Que faire en cas de problème? | |
Outils => | Par exemple, JIRA pour le suivi des bogues |
Connexion | |
Comment utiliser JIRA? | |
Gestion des défauts => | À qui allons-nous signaler les défauts? |
Comment allons-nous rendre compte? | |
Qu'est-ce qui est attendu - fournissons-nous une capture d'écran? | |
Risques et gestion des risques => | Les risques sont répertoriés |
Les risques sont analysés - la probabilité et l'impact sont documentés | |
Des plans d'atténuation des risques sont élaborés | |
Critères de sortie => | Quand arrêter les tests? |
Comme toutes les informations mentionnées ci-dessus sont les plus critiques pour le travail quotidien d'un projet d'AQ , il est important de garder le document du plan à jour de temps en temps.
Exemple de document de plan de test pour un projet en direct
Un exemple de document de modèle de plan de test est créé pour notre ' ORANGEHRM VERSION 3.0 - MON MODULE D'INFORMATION » Projet et joint ci-dessous. Jetez-y un œil. Des commentaires supplémentaires ont été ajoutés au document en rouge pour expliquer les sections.
Ce plan de test concerne à la fois les phases fonctionnelles et UAT. Il explique également le processus de gestion des tests à l'aide de l'outil HP ALM.
Télécharger un exemple de plan de test:
Format de document => Cliquez ici pour télécharger le plan de test au format Doc c'est celui que nous avons créé pour le projet OragngeHRM live et nous l'utilisons également pour notre cours intensif de test de logiciels.
Format PDF => Cliquez ici pour télécharger le plan de test au format pdf .
Fichiers de feuille de travail (.xls) référencés dans les versions doc / pdf ci-dessus => Téléchargez le Fichiers XLS référencés dans le plan de test ci-dessus
Le modèle ci-dessus est très complet et détaillé également. Veuillez donc lui donner une lecture approfondie pour obtenir les meilleurs résultats.
Comme le plan est également bien créé et bien expliqué, passons à la phase suivante à la fois dans SDLC et STLC.
Code du SDLC:
Alors que le reste du projet passait son temps à la création de TDD, nous avons identifié la portée du test (scénarios de test) et créé le premier projet de plan de test fiable. La phase suivante de SDLC consiste à vérifier quand le codage se produit.
Les développeurs sont le principal point de mire de toute l'équipe dans cette phase. L'équipe QA se livre également à la tâche la plus importante qui n'est rien d'autre 'Création de cas de test' .
Si les scénarios de test étaient «Que tester», alors les cas de test traitent de «Comment tester». La création de cas de test est une partie prédominante de la phase de conception de test du STLC. L'entrée pour l'activité de création de cas de test est les scénarios de test et le document SRS.
Pour les testeurs comme nous, Cas de test sont la vraie affaire - c'est la matière dans laquelle nous passons la plupart de notre temps. Nous les créons, les examinons, les exécutons, les maintenons, les automatisons - et bien, vous obtenez l'image. Peu importe notre expérience et le rôle que nous jouons dans un projet, nous travaillerions toujours avec les cas de test.
Planification des tests vs exécution des tests
La planification des tests logiciels réserve une portée bien meilleure en comparaison Phase STLC . La livraison de logiciels de qualité est assurée par l'équipe de test. Et ce qui doit être fait lors des tests est en fait décidé lors de la phase de planification des tests.
Cette section fournira un aperçu complet et comprendra des illustrations sur l'importance de la planification des tests et phase d'exécution . Après avoir lu ceci, vous comprendrez l'importance significative de la phase de planification par rapport à la phase d'exécution avec plus exemples en direct et études de cas pour les illustrations .
Planification des tests
Vous trouverez ci-dessous certaines choses essentielles à noter lors de la planification:
La planification d'un test est la partie essentielle du cycle de test. Le résultat de la phase de test sera déterminé par la qualité et la portée de la planification qui a été faite pour les tests.
La planification du test a généralement lieu pendant la phase de développement afin de gagner du temps pour l'exécution du test sur accord mutuel de toutes les parties impliquées.
Certains faits importants à noter comprennent:
- La planification doit être lancée parallèlement au développement, à condition que les exigences aient été gelées.
- Toutes les parties prenantes telles que les concepteurs, les développeurs, les clients et les testeurs doivent être impliquées lors de la finalisation du plan.
- La planification ne peut pas être élaborée pour des besoins commerciaux non confirmés ou non approuvés.
- Des plans de test similaires seront appliqués aux nouvelles exigences dont l'entreprise aura besoin.
Exemple 1
L'équipe de développement travaille sur un logiciel XYZ après avoir obtenu quelques exigences des clients. L'équipe de test a presque commencé sa préparation pour la phase de définition ou de planification du test. La planification des tests doit être conçue pour répondre aux exigences initiales citées par les clients. Cela a été fait par l'équipe de test.
Aucune des autres parties prenantes n'a été impliquée pendant cette phase et la planification a été gelée.
L’équipe de développement a maintenant apporté quelques modifications au flux d’activité afin de résoudre quelques problèmes dans son travail avec l’approbation du client. Maintenant, le logiciel est venu à l'équipe de test pour un test. Avec le plan de test conforme à l'ancien flux commercial, l'équipe de test a commencé sa série de tests. Cela a eu un impact sur les livrables de test avec de nombreux retards, car le flux commercial modifié n'a pas été partagé avec l'équipe de test.
Observation de l'exemple 1:
Il y a certaines observations de l'exemple ci-dessus.
Elles sont:
- Comprendre le nouveau flux commercial a pris beaucoup de temps.
- Retards dans les livrables du projet.
- Refonte de la planification et des autres tâches de la phase.
Toutes ces observations doivent être converties en besoins essentiels pour un livrable de test efficace.
Principaux composants de la phase de planification
Vous trouverez ci-dessous les principaux composants impliqués dans la phase de planification.
- Stratégie de test: C'est l'une des sections les plus importantes qui peuvent expliquer la stratégie qui sera utilisée lors des tests.
- Couverture de test: Ceci est essentiellement nécessaire et il effectuera une cartographie de conformité des besoins de l'entreprise et des cas de test afin de s'assurer que l'ensemble du logiciel a été testé ou non.
- Cycles et durées des tests: Cela peut devenir très critique en fonction des cycles de développement et de leur temps pour terminer chaque cycle.
- Critères de réussite / échec: Il est très nécessaire de définir les critères de réussite et d'échec. A quelques reprises, cela sera également défini par les clients.
- Exigences commerciales et techniques: Le besoin d'avoir le logiciel et les objectifs qu'ils servent seront clairement définis avec les explications de bas niveau.
Limites
Il y a peu de choses qui peuvent réellement contrôler la phase de test du logiciel, en particulier la phase de planification.
Voici quelques domaines:
- Caractéristiques à tester et à ne pas tester: Cela indiquera clairement ce qui doit être testé et ce qui ne devrait pas l'être.
- Critères de suspension et conditions de reprise: Il s'agit du décideur sur le logiciel développé et les critères définis afin de suspendre les tests ou de reprendre les tests.
- Responsabilités: Un testeur aura de multiples responsabilités pour garantir les problèmes, les bogues et les défauts du logiciel testé. De plus, les bogues doivent être validés avec les développeurs pour qu'ils soient corrigés.
- Risques et éventualités: Les risques associés pendant les tests doivent être clairement mentionnés et les éventualités appropriées pendant la période doivent être définies très clairement.
Étude de cas n ° 1
L'équipe de développement de Exemple 1 prévoit de publier le logiciel XYZ en 2 phases. La phase 1 a de nombreuses fonctionnalités à tester et quelques-unes à ne pas l'être. Encore une fois, le logiciel a été publié pour tester sans tenir l'équipe de test informée des fonctionnalités qui doivent encore être développées.
Maintenant, l'équipe de test commence son exécution sur la base des plans de test qu'elle a déjà élaborés. Ils proposent un grand nombre de bogues. Et après validation de l'équipe de développement, la plupart d'entre eux deviennent invalides.
Observations de l'étude de cas ci-dessus:
- L'équipe de développement publiera le logiciel à l'équipe de test avec des notes de version et des notes de couverture des exigences (notes de version).
- Les fonctionnalités à tester et à ne pas tester doivent être prises en compte en fonction du logiciel publié avant les tests.
- Les critères de suspension et de reprise des tests doivent être définis correctement.
- Les risques et les plans d'urgence liés à l'indisponibilité du logiciel doivent être parfaitement représentés.
Lire aussi=> Comment gérer les risques pendant la phase de planification des tests
Plan d'exécution des tests
L'exécution des cas de test est l'une des étapes de la phase STLC. Cela devra être réalisé conformément aux plans élaborés précédemment. Par conséquent, la planification continue de dominer toute la phase de test. Voici un exemple où l'équipe de test est affectée par les changements dans les plans de test.
Exemple # 2
Le test du logiciel A a été lancé sur la base du plan 1 élaboré par l'équipe. Plus tard, en raison des besoins commerciaux et des changements, le plan de test a dû subir quelques changements. Ceci, à son tour, a forcé les cas de test ou l'exécution à être modifiés.
Observations:
- Le plan de test déterminera l'exécution du scénario de test.
- La partie exécution varie selon le plan.
- Tant que le plan et les exigences sont valides, les cas de test le sont également.
Moyens de surmonter les problèmes lors de l'exécution
Les testeurs rencontrent plus souvent divers scénarios pendant qu'ils exécutent le test. C'est à ce moment que les testeurs devront comprendre et connaître les moyens de résoudre le problème ou au moins trouver une solution de contournement au problème.
Exemple # 3
Lors de l'exécution du scénario de test du logiciel B, l'équipe de test rencontre plusieurs problèmes. Peu d'entre eux sont des bouchons de spectacle. Ils ont besoin des développeurs pour les aider à surmonter le problème. Cela s'est produit plusieurs fois et il en résulte un retard dans le test des livrables.
Observations:
- Il existe une dépendance pour surmonter les problèmes et les problèmes environnementaux.
- Une bonne compréhension de l'environnement est requise pour les testeurs.
- Les problèmes fréquents et connus doivent être documentés pour les surmonter à l'avenir.
Contrôle et gestion des versions
Contrôle de version et la gestion des plans de test et des cas de test sont vraiment importants afin de présenter les livrables en temps opportun. Ceci est plus important et se fait souvent à l'aide d'un outil de contrôle de version.
Un outil de contrôle de version les aide non seulement à contrôler les plans de test, mais aide également à la gestion des défauts. Lorsqu'il y a des projets de test avec plusieurs cycles et versions, ces outils peuvent vraiment aider beaucoup à réduire les métriques pour prendre en charge les livrables de test.
Aussi, lisez=> Gestion des risques lors de la phase d'exécution des tests
Différence entre la planification des tests et l'exécution des tests
Voici quelques domaines importants qui indiqueront en quoi la planification différera de la phase d'exécution des tests.
Zone de comparaison | Planification des tests | Exécution des tests |
---|---|---|
Positionnement livrable | Le plan de test sera considéré comme un livrable majeur pour l'activité de test. Cela sera fait comme première étape du processus de test. | Ce sera le dernier membre du banc dans la phase de test. Après l'exécution, l'état des défauts / bogues ainsi que l'état d'exécution du scénario de test seront partagés comme l'un des livrables de test. |
Personne responsable | Le responsable du test préparera le plan de test et le partagera avec toutes les parties prenantes pour leur examen. | Cela sera normalement effectué par le testeur en gardant à l'esprit que les cas de test préparés ont été approuvés et signés. |
Objectif principal | Les domaines d'intervention du plan de test sont la manière dont les tests doivent être effectués, ce qui doit être pris en compte et ce qu'il ne faut pas faire, l'environnement qui peut être utilisé, les calendriers de test, etc. | L'exécution du test se concentre principalement sur l'exécution des cas de test fournis pour être testés sur le logiciel. |
Mode récurrent ou itératif | Il s'agit d'une activité ponctuelle. Cela dit, cela peut nécessiter ou non des modifications pour les futures versions du logiciel. | Il y a 3 parties dans ce domaine lorsque nous parlons d'itération. 1. Test fonctionnel. 2. Test de régression. 3. Re-test. |
Contributions | Les entrées pour la création d'un plan de test sont vraiment nécessaires et doivent être fournies par les analystes d'affaires, l'architecte, les clients, etc., | Le document de cas de test est la principale entrée. |
Période à laquelle il peut être démarré | Il doit être lancé en même temps que le cycle de développement pour obtenir des résultats efficaces et gagner du temps. Mais il existe peu de modèles comme le modèle de chute d'eau où la phase de test ne commencera qu'une fois la phase de développement terminée. | L'exécution doit être lancée strictement après le développement du logiciel. |
Période de fermeture | Le plan de test n'aura pas de période de clôture. En général, une approbation de toutes les parties intéressées pour le logiciel sera fournie. | L'exécution pour une version ou un cycle spécifique sera considérée comme clôturée lorsque tous les scénarios de test auront été exécutés sur le logiciel. |
Utilisation des outils | Il n'y aura pas beaucoup d'outils utilisés car l'activité de planification sera davantage de discussion et de documentation. Pour suivre les modifications apportées au plan, les gestionnaires de tests utiliseront normalement n'importe quel outil de contrôle de version comme VSS ou autre. | Cela dépendra du mode d'exécution. En cas de manuel, aucun outil ne sera utilisé pour l'exécution. Mais pour consigner les défauts et gérer, certains outils seront utilisés. En cas de test d'automatisation, l'exécution se fera à l'aide d'outils tels que QTP, SELENIUM etc. |
Impacts sur les livrables | Cela aura un impact sur toutes les phases de test d'une manière plus large | Cela aura un impact sur le cycle ou la version ultérieure à tester. |
Les illustrations ci-dessus auraient pu mieux expliquer l'importance des activités de planification des tests que celle de l'exécution des tests. Par certains moyens, la phase d'exécution est une sorte de sous-ensemble du plan de test.
outils de test d'enregistrement et de lecture gratuits
Sur la base de la stratégie de test, de l'approche et des autres éléments, le plan de test a une probabilité plus élevée d'être modifié pour laisser place aux changements. C'est une chose certaine que l'exécution des tests dépend des cas de test. Les cas de test sont basés sur les plans. Par conséquent, des changements dans les plans garantiront des changements dans les cas de test.
Mais inversement, les changements dans les cas de test ne doivent pas obligatoirement rechercher des changements. C'est l'une des principales raisons pour lesquelles la planification se maintient par rapport à la phase d'exécution des tests.
Notre prochain tutoriel vous expliquera plus en détail comment créer des cas de test? Que sont-ils? Et comment nous pouvons les faire fonctionner pour nous avec les divers autres aspects liés aux cas de test.
Tutoriel SUIVANT=> Formation QA Jour-4: Écriture de cas de test à partir d'un document SRS
Êtes-vous un expert dans la rédaction d'un document de plan de test? Alors c'est le bon endroit pour partager vos précieux conseils d'amélioration pour les futurs testeurs. N'hésitez pas à nous faire part de vos réflexions dans la section commentaires ci-dessous !!
lecture recommandée
- Exemple de modèle de plan de test logiciel avec format et contenu
- Guide de documentation des tests de logiciels (pourquoi c'est important)
- Ressources et téléchargements de tests de logiciels d'assurance qualité
- Exemple de document de plan de test (exemple de plan de test avec les détails de chaque champ)
- Exécution des tests dans les tests logiciels: processus exact et plan avec l'exemple
- Comment rédiger un document de stratégie de test (avec un exemple de modèle de stratégie de test)
- Écrire des cas de test à partir d'un document SRS (TÉLÉCHARGER des exemples de cas de test de projet en direct)
- Programme de cours de test de logiciels - Plan de formation détaillé du cours en ligne