PLAN DE TEST - TESTS DE LOGICIELS

Un plan de test est un document détaillé qui décrit les domaines et activités de test de logiciels. Il décrit la stratégie de test, les objectifs, le calendrier des tests, les ressources requises (ressources humaines, logiciels et matériel), l'estimation des tests et les livrables des tests.

Le plan de test est la base des tests de chaque logiciel. Il s'agit de l'activité la plus cruciale qui garantit la disponibilité de toutes les listes d'activités planifiées dans un ordre approprié.

Le plan de test est un modèle permettant de mener des activités de test de logiciels en tant que processus défini entièrement surveillé et contrôlé par le responsable des tests. Le plan de test est préparé par le Test Lead (60 %), le Test Manager (20 %) et par l'ingénieur de test (20 %).

Types de plans de test

Il existe trois types de plan de test

Plan de test principal
Plan de test des phases
Plans de test spécifiques au type de test

Plan de test principal

Le plan de test principal est un type de plan de test qui comporte plusieurs niveaux de test. Il comprend une stratégie de test complète.

Plan de test des phases

Un plan de test de phase est un type de plan de test qui aborde n'importe quelle phase de la stratégie de test. Par exemple, une liste d'outils, une liste de cas de test, etc.

Plans de tests spécifiques

Plan de test spécifique conçu pour les principaux types de tests tels que les tests de sécurité, les tests de charge, les tests de performances, etc. En d'autres termes, un plan de test spécifique conçu pour les tests non fonctionnels.

Comment rédiger un plan de test

L'élaboration d'un plan de test est la tâche la plus cruciale du processus de gestion des tests. Selon IEEE 829, suivez les sept étapes suivantes pour préparer un plan de test.

Tout d’abord, analysez la structure et l’architecture du produit.
Concevez maintenant la stratégie de test.
Définir tous les objectifs du test.
Définir la zone de test.
Définissez toutes les ressources utilisables.
Planifiez toutes les activités de manière appropriée.
Déterminez tous les livrables du test.

Composants ou attributs du plan de test

Le plan de test se compose de différentes parties qui nous aident à dériver l'ensemble de l'activité de test.

Objectifs: Il s'agit d'informations sur les modules, les fonctionnalités, les données de test, etc., qui indiquent l'objectif de l'application, le comportement de l'application, l'objectif, etc.

Portée: Il contient des informations qui doivent être testées avec une application. Le champ d’application peut être divisé en deux parties :

Portée
Hors champ d'application

Portée: Ce sont ces modules qui doivent être testés rigoureusement (en détail).

Hors champ d'application : Ce sont des modules qui n'ont pas besoin d'être testés rigoureusement.

Par exemple , Supposons que nous ayons une application Gmail à tester, où fonctionnalités à tester tel que Composer un courrier, éléments envoyés, boîte de réception, brouillons et le fonctionnalités qui ne sont pas testées tel que Aide , et ainsi de suite, ce qui signifie que lors de la phase de planification, nous déciderons quelle fonctionnalité doit être vérifiée ou non en fonction du délai indiqué dans le produit.

Maintenant comment décidons-nous quelles fonctionnalités ne doivent pas être testées ?

Nous avons les aspects suivants où nous pouvons décider quelle fonctionnalité ne doit pas être testée :

Comme on le voit ci-dessus Aide les fonctionnalités ne seront pas testées, car elles sont écrites et développées par le rédacteur technique et révisées par un autre rédacteur professionnel.
Supposons que nous ayons une application qui a P, Q, R et S fonctionnalités, qui doivent être développées en fonction des exigences. Mais ici, la fonctionnalité S a déjà été conçue et utilisée par une autre société. L'équipe de développement achètera donc S à cette société et l'intégrera à des fonctionnalités supplémentaires telles que P, Q et R.

Désormais, nous n'effectuerons pas de tests fonctionnels sur la fonctionnalité S car elle a déjà été utilisée en temps réel. Mais nous effectuerons les tests d'intégration et les tests système entre les fonctionnalités P, Q, R et S, car les nouvelles fonctionnalités pourraient ne pas fonctionner correctement avec la fonctionnalité S, comme nous pouvons le voir dans l'image ci-dessous :

Supposons que dans la première version du produit, les éléments qui ont été développés, tels que P, Q, R, S, T, U, V, W…..X, Y, Z . Désormais, le client fournira les exigences pour les nouvelles fonctionnalités qui améliorent le produit dans la deuxième version et les nouvelles fonctionnalités sont A1, B2, C3, D4 et E5.

Après cela, nous écrirons la portée pendant le plan de test comme

Portée

Fonctionnalités à tester

A1, B2, C3, D4, E5 (nouvelles fonctionnalités)

P, Q, R, S, T

Fonctionnalités à ne pas tester

âge de Rihanna

W…..X, Y, Z

Par conséquent, nous vérifierons d'abord les nouvelles fonctionnalités, puis continuerons avec les anciennes fonctionnalités, car elles pourraient être affectées après l'ajout des nouvelles fonctionnalités, ce qui signifie que cela affectera également les zones d'impact. Nous effectuerons donc une série de tests de régression pour P, Q. , R…, T caractéristiques.

Méthodologie des tests :

Il contient des informations sur l'exécution de différents types de tests, tels que les tests fonctionnels, les tests d'intégration et les tests système, etc. sur l'application. En cela, nous déciderons quel type de test ; nous effectuerons les différentes fonctionnalités en fonction des exigences de l'application. Et ici, nous devons également définir le type de tests que nous utiliserons dans les méthodologies de test afin que tout le monde, comme la direction, l'équipe de développement et l'équipe de test, puisse comprendre facilement car les termes de test ne sont pas standard.

Par exemple, pour une application autonome telle que Adobe Photoshop , nous effectuerons les types de tests suivants :

Tests de fumée → Tests fonctionnels → Tests d'intégration → Tests système → Tests ad hoc → Tests de compatibilité → Tests de régression → Tests de globalisation → Tests d'accessibilité → Tests d'utilisabilité → Tests de fiabilité → Tests de récupération → Tests d'installation ou de désinstallation

Et supposons que nous devions tester le https://www.jeevansathi.com/ application, nous effectuerons donc les types de tests suivants :

Test de fumée	Test fonctionel	Tests d'intégration
Test du système	Tests ponctuels	Tests de compatibilité
Les tests de régression	Test de mondialisation	Tests d'accessibilité
Tests d'utilisation	Test de performance

Approche

Cet attribut est utilisé pour décrire le flux de l'application lors de l'exécution des tests et pour référence future.

Nous pouvons comprendre le flux de l'application à l'aide des aspects ci-dessous :

En écrivant les scénarios de haut niveau En écrivant le graphe de flux

En écrivant les scénarios de haut niveau

Par exemple , supposons que nous testions le Gmail application:

Connectez-vous à Gmail - envoie un e-mail et vérifie s'il se trouve sur la page Éléments envoyés
Se connecter à …….
……
…....

Nous écrivons ceci pour décrire les approches qui doivent être adoptées pour tester le produit et uniquement pour les fonctionnalités critiques pour lesquelles nous rédigerons les scénarios de haut niveau. Ici, nous ne nous concentrerons pas sur tous les scénarios, car l'ingénieur de test peut décider quelles fonctionnalités doivent être testées ou non.

En écrivant le graphe de flux

Le graphique de flux est écrit car l'écriture des scénarios de haut niveau prend un peu de temps, comme nous pouvons le voir dans l'image ci-dessous :

Nous créons des graphiques de flux pour apporter les avantages suivants tels que :

La couverture est facile
La fusion est facile

La démarche peut être classée en deux parties qui sont les suivantes :

Approche de haut en bas
Approche de bas en haut

Hypothèse

Il contient des informations sur un problème ou une question qui a pu survenir pendant le processus de test et lorsque nous rédigeons les plans de test, les hypothèses assurées seraient faites comme les ressources et les technologies, etc.

Risque

Ce sont les défis auxquels nous devons faire face pour tester l'application dans la version actuelle et si les hypothèses échouent, des risques sont impliqués.

Par exemple, l'effet pour une application, la date de sortie est reportée.

Plan d'atténuation ou plan d'urgence

Il s'agit d'un plan de secours préparé pour surmonter les risques ou les problèmes.

Voyons un exemple d'hypothèse, de risque et de plan d'urgence ensemble, car ils sont corrélés les uns aux autres.

Dans tout produit, le hypothèse ce que nous ferons, c'est que les 3 ingénieurs de test seront là jusqu'à la fin du produit et que chacun d'eux se verra attribuer différents modules tels que P, Q et R. Dans ce scénario particulier, le risque Cela pourrait être le cas si l'ingénieur de test quittait le projet en plein milieu de celui-ci.

Par conséquent, la plan d'urgence se verra attribuer un propriétaire principal et un propriétaire subordonné pour chaque fonctionnalité. Ainsi, si l'ingénieur de test quitte l'entreprise, le propriétaire subordonné prend en charge cette fonctionnalité spécifique et aide également le nouvel ingénieur de test, afin qu'il puisse comprendre les modules qui lui sont attribués.

Les hypothèses, les risques et le plan d’atténuation ou d’urgence sont toujours précis sur le produit lui-même. Les différents types de risques sont les suivants :

Perspective du client
Approche ressources
Avis technique

Rôle et responsabilité

Il définit la tâche complète qui doit être effectuée par l'ensemble de l'équipe de test. Lorsqu'un grand projet arrive, alors le Gestionnaire de tests est une personne qui rédige le plan de test. S'il y a 3 à 4 petits projets, le responsable de test attribuera chaque projet à chaque responsable de test. Ensuite, le responsable du test rédige le plan de test du projet qui lui est attribué.

Voyons un exemple où nous comprendrons les rôles et la responsabilité du responsable de test, du responsable de test et des ingénieurs de test.

constante Java

Rôle : Gestionnaire de tests

Nom : Ryan

Responsabilité:

Préparer (rédiger et réviser) le plan de test
Animer la réunion avec l'équipe de développement
Conduire la réunion avec l'équipe de tests
Conduire la réunion avec le client
Organiser une réunion debout mensuelle
Signer la note de version
Gestion des escalades et des problèmes

Rôle : responsable des tests

Nom : Harvey

Responsabilité:

Préparer (rédiger et réviser) le plan de test
Organiser des réunions debout quotidiennes
Examiner et approuver le scénario de test
Préparer le RTM et les rapports
Attribuer des modules
Calendrier de manutention

Rôle : Ingénieur de test 1, Ingénieur de test 2 et Ingénieur de test 3

Nom : Louis, Jessica, Donna

Attribuer des modules : M1, M2 et M3

Responsabilité:

Rédiger, réviser et exécuter les documents de test qui comprennent un scénario de test et des scénarios de test.
Lire, réviser, comprendre et analyser l'exigence
Écrire le flux de l'application
Exécuter le scénario de test
RTM pour les modules respectifs
Suivi des défauts
Préparer le rapport d’exécution des tests et le communiquer au Test Lead.

Calendrier

Il est utilisé pour expliquer le calendrier de travail, ce qui doit être fait ou cet attribut couvre le moment exact où chaque activité de test doit commencer et se terminer ? Et les données exactes sont également mentionnées pour chaque activité de test pour une date particulière.

Par conséquent, comme nous pouvons le voir dans l’image ci-dessous, pour l’activité particulière, il y aura une date de début et une date de fin ; pour chaque test sur une version spécifique, il y aura la date spécifiée.

Par exemple

Rédaction de cas de tests
Processus d'exécution

Suivi des défauts

Cela se fait généralement à l’aide d’outils car nous ne pouvons pas suivre manuellement l’état de chaque bug. Et nous commentons également la manière dont nous communiquons les bogues identifiés au cours du processus de test et les renvoyons à l'équipe de développement et comment l'équipe de développement répondra. Ici, nous mentionnons également la priorité des bugs tels que élevé, moyen et faible.

Voici différents aspects du suivi des défauts :

Bloqueur ou obstacle

Par exemple

Critique

Majeur

Mineure

Haut-P1

Moyen-P2

Faible-P3

Par conséquent, en fonction de la priorité des bogues comme élevée, moyenne et faible, nous les classerons en P1, P2, P3 et P4.

Environnements de test

Ce sont les environnements dans lesquels nous allons tester l'application, et nous avons ici deux types d'environnements, qui sont de logiciel et matériel configuration.

Le configuration du logiciel signifie les détails sur différents Systèmes d'exploitation tel que Windows, Linux, UNIX et Mac et divers Navigateurs comme Google Chrome, Firefox, Opéra, Internet Explorer , et ainsi de suite.

Et le configuration matérielle désigne les informations sur les différentes tailles de RAM, ROM et processeurs .

Par exemple

Le Logiciel comprend les éléments suivants :

Serveur

Système opérateur	Linux
Serveur Web	Apache Tomcat
Serveur d'application	Websphère
Serveur de base de données	Serveur Oracle ou MS-SQL

Remarque : Les serveurs ci-dessus sont les serveurs utilisés par l'équipe de test pour tester l'application.

Client

Système opérateur	Windows XP, Vista 7
Navigateurs	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 et Internet Explorer 8

Remarque : Les détails ci-dessus fournissent les différents systèmes d'exploitation et navigateurs dans lesquels l'équipe de test testera l'application.

Le Matériel comprend les éléments suivants :

Serveur : Soleil StarCat 1500

Ce serveur particulier peut être utilisé par l'équipe de test pour tester son application.

Client:

Il a la configuration suivante, qui est la suivante :

Processeur	Intal2GHz
RAM	2 Go
….	….

Remarque : Il fournira la configuration des systèmes des ingénieurs de test qui constituent l'équipe de test.

L'équipe de développement fournira la configuration de la façon d'installer le logiciel. Si l'équipe de développement ne fournit pas encore le processus, nous l'écrirons en tant que développement basé sur les tâches (à déterminer) dans le plan de test.

Critères d'entrée et de sortie

Il s’agit d’une condition nécessaire qui doit être remplie avant de démarrer et d’arrêter le processus de test.

Critère d'entrée

Les critères d'entrée contiennent les conditions suivantes :

Les tests en boîte blanche devraient être terminés.
Comprendre et analyser l'exigence et préparer les documents de test ou lorsque les documents de test sont prêts.
Les données de test devraient être prêtes.
Build ou l'application doit être préparée
Les modules ou fonctionnalités doivent être attribués aux différents ingénieurs de test.
La ressource nécessaire doit être prête.

Critère de sortie

Les critères de sortie contiennent les conditions suivantes :

Lorsque tous les cas de test sont exécutés.
La plupart des cas de test doivent être passé .
Cela dépend de la gravité des bugs, ce qui signifie qu'il ne doit pas y avoir de bloqueur ou de bug majeur, alors que certains bugs mineurs existent.

Avant de commencer à effectuer des tests fonctionnels, tout ce qui précède Critère d'entrée devrait être suivi. Après avoir effectué des tests fonctionnels et avant de faire des tests d'intégration, alors le Critères de sortie de les tests fonctionnels doivent être suivis car le % des critères de sortie est décidé par la réunion avec le responsable du développement et du test car leur collaboration peut atteindre le pourcentage. Mais si les critères de sortie des tests fonctionnels ne sont pas respectés, nous ne pouvons pas poursuivre les tests d'intégration.

Ici en fonction de la gravité du bug signifie que l'équipe de test aurait décidé de procéder ainsi pour les phases suivantes.

Automatisation des tests

En cela, nous déciderons de ce qui suit :

Quelle fonctionnalité doit être automatisée et ne doit pas être automatisée ?
Quel outil d'automatisation des tests allons-nous utiliser sur quel framework d'automatisation ?

Nous automatisons le scénario de test uniquement après la première version.

Ici se pose la question de savoir sur quelle base nous volonté décider quelles fonctionnalités doivent être testées ?

Dans l'image ci-dessus, comme nous pouvons le voir, les fonctionnalités les plus couramment utilisées doivent être testées encore et encore. Supposons que nous devions vérifier l'application Gmail où se trouvent les fonctionnalités essentielles Composer un courrier, des éléments envoyés et une boîte de réception . Nous allons donc tester ces fonctionnalités car effectuer des tests manuels, cela prend plus de temps et cela devient également un travail monotone.

Maintenant, comment décidons-nous quelles fonctionnalités ne seront pas testées ?

'algorithme du banquier'

Supposer l'aide La fonctionnalité de l'application Gmail n'est pas testée encore et encore car ces fonctionnalités ne sont pas régulièrement utilisées, nous n'avons donc pas besoin de la vérifier fréquemment.

Mais si certaines fonctionnalités sont instables et comportent beaucoup de bugs , ce qui signifie que nous ne testerons pas ces fonctionnalités car elles doivent être testées encore et encore lors de tests manuels.

Si il y a une fonctionnalité qui doit être testée fréquemment , mais nous nous attendons à ce que les exigences changent pour cette fonctionnalité, nous ne la vérifions donc pas car la modification des cas de test manuels est plus confortable que la modification du script de test d'automatisation.

Estimation des efforts

En cela, nous planifierons les efforts qui doivent être déployés par chaque membre de l’équipe.

Livrable du test

Il s'agit des documents issus de l'équipe de test, que nous avons remis au client avec le produit. Il comprend les éléments suivants :

Plan de test Cas de test Scripts de test RTM (Matrice de traçabilité des exigences) Rapport de défaut Rapport d'exécution des tests Graphiques et mesures Notes de version

Graphiques et mesures

Graphique

Dans celui-ci, nous discuterons des types de graphiques nous l'enverrons, et nous fournirons également un échantillon de chaque graphique.

Comme nous pouvons le voir, nous avons cinq graphiques différents qui montrent les différents aspects du processus de test.

Graphique1 : En cela, nous montrerons combien de défauts ont été identifiés et combien de défauts ont été corrigés dans chaque module.

Graphique 2 : La figure 1 montre combien de défauts critiques, majeurs et mineurs ont été identifiés pour chaque module et combien ont été corrigés pour leurs modules respectifs.

Graphique3 : Dans ce graphique particulier, nous représentons le construire un graphique judicieux , ce qui signifie que dans chaque build, combien de défauts ont été identifiés et corrigés pour chaque module. Sur la base du module, nous avons déterminé les bugs. Nous ajouterons R. pour montrer le nombre de défauts dans P et Q, et nous ajoutons également S pour montrer les défauts dans P, Q et R.

Graphique4 : Le responsable du test concevra le Analyse des tendances des bogues graphique qui est créé chaque mois et l'envoyer également à la Direction. Et c’est comme la prédiction qui se fait à la fin du produit. Et ici, on peut aussi évaluez les corrections de bugs comme on peut le constater arc a un tendance à la hausse dans l'image ci-dessous.

Graphique5 : Le Gestionnaire de tests a conçu ce type de graphique. Ce graphique est destiné à comprendre l'écart entre l'évaluation des bogues et les bogues réels survenus, et ce graphique contribue également à améliorer l'évaluation des bogues à l'avenir.

Métrique

Comme ci-dessus, nous créons le graphique de distribution des bogues, qui figure dans la figure 1, et à l'aide des données mentionnées ci-dessus, nous concevrons également les métriques.

Par exemple

Dans la figure ci-dessus, nous conservons les enregistrements de tous les ingénieurs de test d'un projet particulier et du nombre de défauts qui ont été identifiés et corrigés. Nous pouvons également utiliser ces données pour des analyses futures. Lorsqu'une nouvelle exigence survient, nous pouvons décider à qui fournir la fonctionnalité difficile à tester en fonction du nombre de défauts détectés précédemment selon les mesures ci-dessus. Et nous serons dans une meilleure situation pour savoir qui peut très bien gérer les fonctionnalités problématiques et trouver un maximum de défauts.

Note de version : Il s'agit d'un document qui est préparé lors de la sortie du produit et signé par le Test Manager.

Dans l'image ci-dessous, nous pouvons voir que le produit final est développé et déployé auprès du client, et le nom de la dernière version est Bêta .

Le Note de version se compose des éléments suivants :

Manuel de l'Utilisateur.
Liste des défauts en attente et ouverts.
Liste des fonctionnalités ajoutées, modifiées et supprimées.
Liste de la plateforme (Système d'exploitation, Matériel, Navigateurs) sur laquelle le produit est testé.
Plateforme sur laquelle le produit n'est pas testé.
Liste des bugs corrigés dans la version actuelle et liste des bugs corrigés dans la version précédente.
Processus d'installation
Versions du logiciel

Par exemple

Supposer que Bêta est la deuxième version de l'application après la première version Alpha est libérée. Certains des défauts identifiés dans la première version ont été corrigés dans la version ultérieure. Et ici, nous soulignerons également la liste des fonctionnalités nouvellement ajoutées, modifiées et supprimées de la version alpha à la version bêta.

Modèle

Cette partie contient tous les modèles de documents qui seront utilisés dans le produit, et tous les ingénieurs de tests utiliseront uniquement ces modèles dans le projet pour maintenir la cohérence du produit. Ici, nous avons différents types de modèles qui sont utilisés pendant tout le processus de test, tels que :

Modèle de cas de test
Modèle de révision de cas de test
Modèle RTM
Modèle de rapport de bug
Rapport d'exécution des tests

Voyons un exemple de document de plan de test

Page 1

Page3-page18

Page-20

Dans la page 1, nous remplissons principalement uniquement le Versions, auteur, commentaires et révisé par champs, et après l'approbation du responsable, nous mentionnerons les détails dans le Approuvé par et date d'approbation des champs.

La plupart du temps, le plan de test est approuvé par le responsable des tests et les ingénieurs de test ne font que l'examiner. Et lorsque les nouvelles fonctionnalités arriveront, nous modifierons le plan de test et ferons les modifications nécessaires dans Version champ, puis il sera renvoyé à nouveau pour un examen plus approfondi, une mise à jour et une approbation du responsable. Le plan de test doit être mis à jour chaque fois que des changements sont survenus. À la page 20, le Les références précisez les détails de tous les documents que nous allons utiliser pour rédiger le document du plan de test.

Note:

Qui rédige le plan de test ?

Fil de test → 60 %
Gestionnaire de tests → 20 %
Ingénieur de test → 20 %

Par conséquent, comme nous pouvons le voir ci-dessus, dans 60 % du produit, le plan de test est rédigé par le Test Lead.

Qui examine le plan de test ?

Responsable des Tests
Gestionnaire de tests
Ingénieur d'essais
Client
Équipe de développement

L'ingénieur de test examine le plan de test du point de vue de son module et le responsable de test examine le plan de test en fonction de l'opinion du client.

Qui approuve le plan de test ?

Client
Gestionnaire de tests

Qui rédige le scénario de test ?

Responsable des Tests
Ingénieur d'essais

Qui examine le scénario de test ?

Ingénieur d'essais
Responsable des Tests
Client
Équipe de développement

Qui approuve les cas de test ?

Gestionnaire de tests
Responsable des Tests
Client

Lignes directrices du plan de test

Réduisez votre plan de test.
Évitez les chevauchements et les redondances.
Si vous pensez que vous n'avez pas besoin d'une section déjà mentionnée ci-dessus, supprimez cette section et continuez.
Être spécifique. Par exemple, lorsque vous spécifiez un système logiciel comme faisant partie de l'environnement de test, mentionnez la version du logiciel au lieu du seul nom.
Évitez les longs paragraphes.
Utilisez des listes et des tableaux dans la mesure du possible.
Mettre à jour le plan si nécessaire.
N'utilisez pas un document obsolète et inutilisé.

Importance du plan de test

Le plan de test oriente notre réflexion. C’est comme un livre de règles qu’il faut suivre.
Le plan de test aide à déterminer les efforts nécessaires pour valider la qualité de l'application logicielle testée.
Le plan de test aide ces personnes à comprendre les détails du test liés à l'extérieur comme les développeurs, les chefs d'entreprise, les clients, etc.
Les aspects importants tels que le calendrier des tests, la stratégie de test, la portée des tests, etc. sont documentés dans le plan de test afin que l'équipe de direction puisse les examiner et les réutiliser pour d'autres projets similaires.