Exemple de modèle de plan de test

Qu'est-ce qu'un modèle de plan de test ?

A Modèle de plan de test Il s'agit d'un document détaillé décrivant la stratégie de test, les objectifs, le calendrier, l'estimation, les livrables et les ressources nécessaires aux tests. Il permet de déterminer l'effort requis pour valider la qualité et sert de plan directeur contrôlé par le responsable des tests.

Création d'un Plan de test est indispensable à la réussite de votre projet de test. Si vous débutez, consultez Comment créer un plan de test.

Télécharger un exemple de modèle de plan de test

Structure du modèle de plan de test

Vous trouverez ci-dessous les éléments importants d'un modèle de plan de test, expliqués dans l'ordre :

• 1. Introduction
• 1.1 Scope
• 1.1.1 Dans la portée
• 1.1.2 Hors de portée
• 1.2 Objectif qualité
• Rôles et responsabilités de 1.3
• 2. Méthodologie des tests
• 2.1 Aperçu
• 2.2 Niveaux de tests
• 2.3 Tri des bogues
• 2.4 Critères de suspension et exigences de reprise
• 2.5 Complétude des tests
• 3. Livrables de test
• 4. Besoins en ressources et en environnement
• 4.1 Outils de test
• 4.2 Environnement de test
• 5. Termes/Acronymes

1) Introduction

L'introduction présente un bref aperçu des stratégies de test, des processus, du flux de travail et des méthodologies utilisés pour le projet.

1.1) Portée

---

Le périmètre est divisé en deux parties afin que les limites du test restent sans ambiguïté.

1.1.1) Dans le champ d'application

Dans la section « Portée », on définit les caractéristiques, les exigences fonctionnelles ou non fonctionnelles du logiciel qui sera testé.

1.1.2) Hors de portée

Hors du périmètre définit les caractéristiques, les exigences fonctionnelles ou non fonctionnelles du logiciel qui ne sera pas testé.

1.2) Objectif qualité

---

Vous mentionnez ici les objectifs généraux que l'équipe prévoit d'atteindre grâce aux tests manuels et aux tests automatisés. Voici quelques objectifs typiques d'un projet de test :

• S’assurer que l’application testée (AUT) est conforme aux exigences fonctionnelles et non fonctionnelles.
• S'assurer que le dispositif testé au laboratoire (AUT) répond aux spécifications de qualité définies par le client.
• Identifier et corriger les bugs avant la mise en production de l'application.

1.3) Rôles et responsabilités

---

Veuillez fournir une description détaillée des rôles et responsabilités des différents membres de l'équipe impliqués, tels que :

• Analyste QA
• Test Manager
• Panneau de configuration
• Développeurs
• Équipe d'installation

Entre autres.

👉 Inscrivez-vous gratuitement au projet de test de logiciel en direct

2) Méthodologie des tests

Cette section détermine le cycle de vie, les niveaux et les règles utilisés pour régir l'exécution des tests.

2.1. Vue d'ensemble

---

Indiquez la raison du choix d'une méthodologie de test particulière pour ce projet. La méthodologie de test sélectionnée pourrait être :

• Cascade
• Itératif
• Agile
• Programmation extrême

La méthodologie choisie dépend de plusieurs facteurs. Vous pouvez en savoir plus sur les méthodologies de test. ici.

2.2) Niveaux de tests

---

Les niveaux de test définissent les types de tests à exécuter sur l'application testée (AUT).Les niveaux choisis dépendent principalement de la portée du projet, des délais et des contraintes budgétaires.

2.3) Tri des bogues

---

L'objectif du triage des bogues est de :

• Définissez le type de résolution pour chaque bogue.
• Prioriser les bogues et établir un calendrier pour tous les bogues « À corriger ».

2.4) Critères de suspension et exigences de reprise

---

Les critères de suspension définissent les conditions dans lesquelles tout ou partie de la procédure de test sera interrompue. Les critères de reprise déterminent quand les tests peuvent reprendre après une suspension.

2.5) Complétude des tests

---

Vous définissez ici les critères qui permettront de considérer vos tests comme terminés. Par exemple, les critères courants pour vérifier la complétude des tests seraient :

• Couverture des tests à 100 % atteinte.
• Tous les cas de test manuels et automatisés ont été exécutés.
• Tous les bugs connus sont corrigés ou prévus pour la prochaine version.

3) Tester les livrables

Répertoriez tous les artefacts produits tout au long du cycle de vie des tests. Leur enregistrement préalable évite les erreurs de transmission entre les équipes.

4) Besoins en ressources et en environnement

Lister les outils et l'infrastructure nécessaires pour sécuriser les budgets, les licences et les environnements avant le début de l'exécution.

4.1) Outils de test

---

Dressez une liste d'outils tels que :

• Outil de suivi des exigences
• Outil de suivi des bogues
• Outils d'automatisation

Ces éléments sont nécessaires pour tester efficacement le projet.

4.2) Environnement de test

---

Mentionnez le minimum matériel exigences qui seront utilisées pour tester l'application.

software est requis en plus du logiciel spécifique au client :

• Windows 11 et ci-dessus
• Microsoft 365 (ou Office 2021 et versions ultérieures)
• MS Exchange, etc.

5) Termes/Acronymes

Documentez tous les termes et acronymes utilisés dans le projet afin que les nouveaux arrivants puissent lire le plan sans ambiguïté.

Téléchargez le format de modèle de plan de test ci-dessus

Exemple de document de plan de test : Exemple d’application Web bancaire

L'exemple suivant montre comment remplir le modèle ci-dessus pour l'application web de la banque Guru99.

1. Introduction

Le plan de test définit le périmètre, l'approche, les ressources et le calendrier de toutes les activités de test du projet Guru99 Bank. Il identifie les éléments et fonctionnalités à tester, les types de tests effectués, le personnel responsable et les risques associés au plan.

1.1 Scope

1.1.1 Dans la portée

Toutes les fonctionnalités du site web de Guru99 Bank définies dans les spécifications logicielles spécifications doivent être testées.

Nom du module	Rôles applicables	Description
Demande de solde	Responsable, Client	Client: Un client peut posséder plusieurs comptes bancaires et ne peut consulter que les soldes de ses propres comptes. Gestionnaire: Un responsable peut consulter le solde de tous les clients placés sous sa supervision.
Transfert de fonds	Responsable, Client	Client: Un client peut transférer des fonds de son propre compte vers n'importe quel compte de destination. Gestionnaire: Un gestionnaire peut transférer des fonds de n'importe quel compte source vers n'importe quel compte de destination.
Mini déclaration	Responsable, Client	Un mini-relevé affiche les 5 dernières transactions d'un compte. Client: Il ne voit que le mini-relevé de ses propres comptes. Gestionnaire: Affiche le mini-relevé de tout compte.
Déclaration personnalisée	Responsable, Client	Un relevé personnalisé filtre et affiche les transactions d'un compte par date ou par valeur de transaction. Client: Ses propres comptes uniquement. Gestionnaire: N'importe quel compte.
Changer mot de passe	Responsable, Client	Client: Il peut modifier le mot de passe de son propre compte. Gestionnaire: Il peut modifier le mot de passe de son propre compte, mais pas celui de ses clients.
Nouveau client	Gérant	Gestionnaire: Un responsable peut ajouter un nouveau client.
Modifier le client	Gérant	Gestionnaire: Permet de modifier les informations telles que l'adresse, l'adresse e-mail et le numéro de téléphone d'un client.
Nouveau compte	Gérant	Le système propose deux types de comptes : épargne et courant. Un client peut détenir plusieurs comptes d’épargne (individuels ou joints) et plusieurs comptes courants. Gestionnaire: Possibilité d'ajouter un nouveau compte pour un client existant.
Modifier le compte	Gérant	Gestionnaire: Permet de modifier les détails d'un compte existant.
Supprimer le compte	Gérant	Gestionnaire: Peut supprimer un compte appartenant à un client.
Supprimer le client	Gérant	Une cliente ne peut être supprimée que si elle ne possède aucun compte courant ou d'épargne actif. Gestionnaire: Peut supprimer un client.
Caution	Gérant	Gestionnaire: Il est possible de déposer de l'argent sur n'importe quel compte, généralement lorsqu'on dépose des espèces dans une agence bancaire.
Retrait	Gérant	Gestionnaire: Il est possible de retirer de l'argent de n'importe quel compte, généralement lors d'un retrait d'espèces dans une agence bancaire.

1.1.2 Hors de portée

Ces fonctionnalités ne sont pas testées car elles ne font pas partie des spécifications des exigences logicielles :

• Interfaces utilisateur
• Interfaces matérielles
• Interfaces logicielles
• Conception logique de la base de données
• Interfaces de communication
• Sécurité et performances du site Web

1.2 Objectif qualité

Les objectifs du test sont de vérifier le fonctionnement du site web de la banque Guru99. Le projet devrait se concentrer sur les tests de… opérations bancaires, comme la gestion de compte, les retraits et la consultation de solde, à guarantir que toutes ces opérations fonctionnent normalement dans un véritable environnement professionnel.

Rôles et responsabilités de 1.3

Le projet devrait utiliser externalisé Des membres comme testeurs pour réduire les coûts du projet.

Non.	Membre	Tâches
1.	Test Manager	Il gère l'intégralité du projet, définit son orientation et acquiert les ressources nécessaires.
2.	Testeur	Identifie et décrit les techniques de test, les outils et l'architecture d'automatisation appropriés ; vérifie l'approche de test ; exécute les tests ; consigne les résultats ; signale les anomalies. Membres externes.
3.	Développeur en test	Met en œuvre les cas de test, les programmes de test, les suites de tests, etc.
4.	Administrateur de tests	Conçoit et maintient l'environnement de test et les ressources nécessaires ; apporte son soutien aux testeurs pendant l'exécution.
5.	Membres de la SQA	Prendre en charge l'assurance qualité et vérifier si le processus de test répond aux exigences spécifiées.

2. Méthodologie des tests

2.1 Aperçu

Le projet Guru99 Bank suit une méthodologie de test compatible avec les méthodes agiles, permettant aux testeurs de s'aligner sur des sprints de développement rapides tout en maintenant une documentation structurée.

2.2 Niveaux de tests

Dans le cadre du projet Guru99 Bank, trois types de tests doivent être effectués :

• Test d'intégration : Les modules logiciels individuels sont combinés et testés en groupe.
• Test du système : Réalisée sur un système complet et intégré afin d'évaluer la conformité aux exigences spécifiées.
• Test d'API: Teste toutes les API exposées par le logiciel testé.

2.3 Tri des bogues

Des réunions de triage des bogues sont organisées deux fois par semaine afin de classer la gravité des défauts, leur responsable et la version cible du correctif.

2.4 Critères de suspension et exigences de reprise

If 40 % des cas de test ont manquéSuspendre les tests jusqu'à ce que l'équipe de développement corrige tous les cas ayant échoué.

2.5 Complétude des tests

• Spécifie les critères qui dénotent un réussi achèvement d'une phase de test.
• Taux d'exécution est obligatoire à 100 % à moins qu'une raison claire soit donnée.
• Le taux de réussite is 80 %; atteindre le taux de réussite est obligatoire.

2.6 Tâches du projet, estimation et calendrier

Tâche	Membres	Effort estimé
Créer la spécification de test	Concepteur de tests	170 heures de travail
Effectuer l'exécution des tests	Testeur, Administrateur de Tests	80 heures de travail
Rapport d'essai	Testeur	10 heures de travail
Test de livraison	Test Manager	20 heures de travail
Total	-	280 heures de travail

Horaire : L'équipe s'engage à réaliser ces tâches pendant la période de test convenue.

3. Livrables de test

Les livrables de test pour le projet Guru99 Bank sont organisés en trois phases.

Avant la phase de test :

• Document de plan de test.
• Cas de test documents.
• Spécifications de conception des tests.

Durant la phase de test :

• Simulateurs d'outils de test.
• Données de test.
• Matrice de traçabilité des tests, journaux d'erreurs et journaux d'exécution.

Une fois les cycles de test terminés :

• Résultats et rapports des tests.
• Rapport de défaut.
• Consignes relatives à la procédure d'installation et de test.
• Notes de version.

4. Besoins en ressources et en environnement

4.1 Outils de test

Non.	Ressources	Description
1.	Server	Un serveur de base de données en cours d'exécution MySQL et un serveur web fonctionnant sous Apache.
2.	Outil d'essai	Un outil capable de générer automatiquement les résultats des tests dans un format prédéfini et d'automatiser leur exécution.
3.	Réseau	Une configuration LAN gigabit et une ligne Internet avec une vitesse minimale de 5 Mb/s.
4.	Ordinateur	Au moins 4 postes de travail en fonctionnement Windows 11, avec 8 Go de RAM et un processeur de 3.4 GHz.

4.2 Environnement de test

Cette section répertorie la configuration matérielle et logicielle minimale requise pour tester l'application. Les logiciels suivants sont nécessaires en plus des logiciels spécifiques au client :

• Windows 11 et ci-dessus
• Microsoft 365 (ou Office 2021 et versions ultérieures)
• MS Exchange, etc.

Comment l'IA contribue à la planification des tests

La planification moderne des tests utilise de plus en plus l'IA pour optimiser les efforts et identifier les angles morts. Les assistants génératifs tels que ChatGPT, Claude ou Gemini Il est possible de rédiger un plan de test initial à partir d'un document d'exigences, de suggérer des cas limites manquants et de générer automatiquement des matrices de traçabilité. Des modèles d'apprentissage automatique identifient les modules à risque à partir des données historiques de défauts, permettant ainsi au responsable des tests de concentrer ses efforts là où c'est le plus important.

Toutefois, l'assistance par IA ne remplace pas le jugement humain. RevAvant d'approuver un plan généré par l'IA, les examinateurs doivent en vérifier la portée, la conformité réglementaire et l'objectif commercial. Les suggestions de l'IA doivent être considérées comme une première ébauche, et non comme le document final.

Meilleures pratiques pour un plan de test efficace

Un plan de test bien rédigé permet de maintenir l'adhésion de toutes les parties prenantes. Appliquez ces bonnes pratiques lors de la rédaction de votre document :

• Restez concis : Utilisez un langage clair et des listes à puces ; évitez le jargon qui ralentit les lecteurs non spécialistes des questions-réponses.
• Fais-le Reviewable: Partagez rapidement ces informations avec les développeurs et les analystes fonctionnels afin de repérer les exigences manquantes.
• Quantifier les critères de sortie : Définir la couverture numérique, le taux de réussite et les seuils de défauts.
• Associer les risques aux mesures d'atténuation : Associez à chaque risque une stratégie de confinement ou de repli.
• Contrôler les versions du plan : Stockez-le dans un outil de documentation pour suivre les modifications apportées au projet.

Questions fréquentes