Un plan de test est le document qui indique ce qui sera vérifié, comment, par qui, sur quels appareils et pour quand. Il définit aussi ce que signifie « terminé », afin que personne ne discute ensuite pour savoir si les tests sont finis. Si vous vous apprêtez à confier votre produit à une équipe QA pour la première fois, ce document est ce qui maintient les deux parties orientées vers le même résultat.
Un bon plan n’est pas de la paperasse pour la forme. Tester sans cet accord a tendance à déraper : l’équipe QA choisit ce qui lui semble important, les développeurs supposent que quelqu’un d’autre a couvert le reste, et les lacunes n’apparaissent qu’après la mise en production.
Ce guide passe en revue ce qui entre dans un vrai plan de test, comment QAwerk planifie les tests avec ses clients et où se situent les cas de test. Plutôt que de dérouler un modèle générique, nous utiliserons des exemples de projets que nous avons réellement menés. Se mettre d’accord sur un plan de test fait partie des premières choses que notre équipe QA dédiée fait avec un nouveau client.
Ce que contient réellement un plan de test
La plupart des plans de test suivent la même structure, et pour une bonne raison : chaque partie répond à une question que quelqu’un finira par poser. Le syllabus Foundation Level de l’ISTQB, utilisé pour certifier les testeurs logiciels dans le monde entier, énumère presque les mêmes sections. La norme internationale de documentation des tests, ISO/IEC/IEEE 29119-3, établit une liste équivalente. Voici ce qui y figure, en termes simples.
- Objectifs : c’est ce que les tests doivent accomplir, par exemple confirmer que le paiement fonctionne avant une opération commerciale de fin d’année ou que rien n’a cassé après une refonte.
- Périmètre : il liste les fonctionnalités vérifiées et, tout aussi important, celles qui ne le sont pas. Écrire ce qui est hors périmètre évite la dispute la plus courante dans tout projet de test.
- Approche de test : elle couvre la façon dont les tests se dérouleront : à la main, avec des scripts automatisés, ou les deux. La même section indique ce qu’il faut vérifier, comme les fonctionnalités, la vitesse ou la sécurité.
- Ressources : elles précisent qui fait le travail, sur quels appareils et navigateurs, et avec quels outils.
- Environnement de test : il indique où les tests ont lieu, généralement une copie séparée de votre produit configurée pour que les testeurs ne touchent jamais aux comptes ou aux données de vrais clients.
- Calendrier : il fixe le début et la fin de chaque campagne de tests, et la façon dont ce rythme s’aligne sur vos dates de livraison.
- Critères d’entrée et de sortie : ce sont les conditions pour commencer, par exemple que la nouvelle version soit installée et que la connexion fonctionne. Les critères de sortie marquent ensuite la fin du travail, par exemple plus aucun bug critique ouvert.
- Risques : ils recensent ce qui pourrait faire dérailler le travail, comme un build en retard ou un compte de test manquant, ainsi que le plan de repli de l’équipe pour chacun.
- Restitution : elle explique à quelle fréquence vous serez informé de l’avancement et des bugs, et sous quelle forme.
Les critères de sortie fonctionnent mieux sous forme de chiffres que chacun peut vérifier, comme les métriques de test logiciel sur lesquelles les équipes s’appuient habituellement pour trancher.
Considérez cette liste comme un modèle de plan de test : c’est ce que vous devriez attendre de tout partenaire QA potentiel, simplement adapté à votre produit. S’il vous faut un exemple plus détaillé, consultez notre checklist de test d’applications mobiles.
Exemples réels : comment QAwerk planifie les tests
QAwerk crée un plan de test pour chaque client, et voici comment le processus se déroule en pratique :
- Revue du produit : avant de planifier quoi que ce soit, nous lisons vos exigences et explorons ce qui est déjà construit pour voir où les problèmes reviennent.
- Périmètre validé : les deux parties valident ce qui est testé, jusqu’aux appareils et navigateurs exacts. Par exemple, sur le projet de place de marché Unpakt, la liste indiquait Windows 10 avec Chrome et un iPhone X avec Safari.
- Priorités : les tests se déroulent par phases, les fonctionnalités les plus importantes pour votre activité étant vérifiées en premier.
- Scénarios imprévus : une part de l’effort, environ 20% sur le projet Unpakt, est consacrée à ce qui se passe quand les utilisateurs font quelque chose que personne n’avait prévu.
- Restitution : les bugs vont directement dans votre propre outil de suivi, et les points d’avancement arrivent chaque jour.
- Couverture complète : une checklist partagée consigne chaque test réussi et échoué, pour que rien ne passe entre les mailles.
Bien sûr, le processus s’ajuste aux besoins de chaque client. Voici quelques cas qui ont appelé des plans très différents :
- Un délai serré : avec environ un mois devant nous, nous avons couvert toutes les fonctionnalités, les deux rôles utilisateur et 7 appareils pour Escuela Coaching. L’application est sortie à la date prévue.
- Aucun processus QA : pour DrAnsay, nous avons d’abord audité les applications web et mobile, puis orienté les tests vers les problèmes récurrents que nous avions relevés. Depuis, plus de 60 bugs sont restés hors production.
- Un produit encore en développement : ChitChat nous a associés alors que les fonctionnalités étaient encore en cours de conception, nous avons donc conçu les vérifications fonctionnalité par fonctionnalité, à mesure que l’application prenait forme. Les tests ont été menés sur 24 téléphones correspondant au marché zambien.
Comment rédiger un plan de test avec votre équipe QA
Quand vous faites appel à une équipe QA, la rédaction du plan de test revient aux testeurs. Votre part consiste à fournir ce que vous seul savez :
- Documents existants : spécifications, tickets, maquettes et rapports de bugs passés montrent comment le produit devrait se comporter. Les manques ne sont pas un problème, puisque le plan transforme les détails absents en questions ouvertes.
- Priorités : indiquez à l’équipe quelles fonctionnalités rapportent de l’argent ou feraient le plus de dégâts si elles cassaient, pour que les tests commencent là.
- Données d’usage : les statistiques sur les téléphones et navigateurs réellement utilisés par vos clients déterminent la liste des appareils.
- Accès : des comptes de test et une copie séparée du produit permettent à l’équipe de travailler sans approcher la version en production.
- Dates de livraison et validation : votre calendrier fixe le moment de chaque campagne, et votre approbation rend le plan définitif.
Au-delà de ces apports, beaucoup dépend de ce que vous construisez. Pour un site web, l’accent porte sur la compatibilité des navigateurs, les écrans de téléphone et la vitesse de chargement, comme le montre notre liste de contrôle pour les tests de site web. Un jeu, à l’inverse, ajoute des vérifications de forte affluence, des revues de conformité aux stores et des phases bêta, le tout détaillé dans notre checklist de tests de jeux mobiles.
Les outils d’IA savent désormais rédiger rapidement un plan en ébauche. D’après le rapport State of Testing 2026 de PractiTest, la moitié des petites équipes QA utilisent déjà l’IA pour la planification des tests, alors que seuls 19,9% des testeurs s’y fient pour identifier les risques. Autrement dit, un outil accélère la rédaction, tandis que juger ce qui peut réellement nuire à votre activité demande toujours des ingénieurs QA expérimentés.
Si votre produit est encore peu documenté, nos services de conception de documentation et rédaction technique peuvent rédiger les cas de test et les autres documents QA en même temps que le plan.
Plan de test et cas de test : quelle différence ?
On confond souvent plans de test et cas de test, mais ces deux documents interviennent à des niveaux très différents.
Rôle
Le document stratégique d’un projet ou d’une version entière
Des instructions pas à pas pour une vérification précise
Question traitée
Que testons-nous, comment et pour quand ?
Cette action exacte produit-elle le bon résultat ?
Lecteurs principaux
Clients, responsables, développeurs, testeurs
Surtout les testeurs
Exemple
Tester le paiement sur les téléphones les plus utilisés par les clients avant la prochaine version
Saisir trois fois un mot de passe erroné et confirmer que le compte se verrouille
Moment de rédaction
Avant le début des tests
Après le plan, avant chaque campagne de tests
Lorsque vous travaillez avec une équipe QA, ce sont les testeurs qui rédigent et exécutent les cas de test, et ce qui vous parvient, ce sont des résultats et des rapports de bugs. Si la mécanique vous intéresse, nous expliquons comment écrire des cas de test dans un article distinct.
Vous entendrez peut-être aussi parler de stratégie de test, qui fixe l’approche générale pour toute une entreprise ou une gamme de produits. Un plan de test met ensuite ces principes en œuvre sur un projet précis. Les grandes organisations gardent généralement la stratégie comme document séparé, tandis que les petites équipes se contentent le plus souvent d’un plan unique. Pour voir de plus près comment les deux documents se répartissent le travail, lisez notre article sur les stratégies de test logiciel.
Où se place un plan de test et pourquoi il est rentable
Dans le cycle de vie des tests logiciels, la planification des tests intervient juste après l’analyse des exigences et avant que quiconque écrive des cas de test. Cet ordre compte, car des spécifications floues produisent un plan vague. Notre article dédié aux exigences de test logiciel explique quels documents aident le plus. À partir de là, la planification façonne chacune des phases du test logiciel restantes.
Un plan de test se révèle le plus précieux quand un projet change de direction, par exemple lorsqu’une fonctionnalité est supprimée, qu’une échéance bouge ou qu’une nouvelle plateforme s’ajoute. Plutôt que de renégocier tout le périmètre, les deux parties ne mettent à jour que les parties concernées et poursuivent.
Chaque collaboration avec QAwerk commence par un plan de test, afin que l’équipe et le client s’accordent sur les priorités dès le premier jour. Le document aide aussi nos testeurs à se familiariser rapidement avec un nouveau produit. De votre côté, le plan sert en outre de trace claire de ce qui a été couvert. Faites établir un plan de test pour votre produit.
FAQ
Qu'est-ce qu'un plan de test en test logiciel ?
Un plan de test en test logiciel est un accord écrit entre une équipe produit et les testeurs sur ce qui est vérifié et comment. Le document fixe les objectifs, le périmètre, les appareils, un calendrier et les responsabilités. Un plan de test définit aussi quand les tests peuvent commencer et ce qui compte comme terminé, pour que l’équipe et les testeurs partagent une même définition du fini.
Que doit contenir un plan de test ?
Un plan de test complet couvre neuf domaines : objectifs, périmètre, approche de test, ressources, environnement de test, calendrier, critères d’entrée et de sortie, risques et restitution. Les détails comptent autant que les intitulés. Un plan solide liste les fonctionnalités exclues à côté de celles incluses, nomme les appareils par modèle exact et énonce des conditions de fin que chacun peut vérifier, par exemple zéro bug critique ouvert.
Qui rédige le plan de test ?
C’est en général le responsable de l’équipe de test qui rédige le plan de test. Avec une société QA externe, le référent QA du prestataire prépare une première version tôt dans le projet et parcourt le document avec le client avant le démarrage. Le client confirme les priorités, communique les dates de livraison et approuve le périmètre, puisque personne ne sait mieux que lui quelles fonctionnalités comptent le plus pour l’activité.
Quelle doit être la longueur d'un plan de test ?
Un plan de test n’a pas de longueur standard, car le bon niveau de détail dépend de la complexité du produit. La mise à jour d’une petite application peut tenir sur deux pages, tandis qu’une plateforme avec plusieurs rôles utilisateur et des connexions à des tiers peut être bien plus longue. En règle générale, chaque section devrait trancher un point que les personnes du projet ont vraiment besoin de connaître.
Les équipes agiles ont-elles encore besoin d'un plan de test ?
Les équipes agiles ont toujours besoin d’un plan de test, simplement dans une version plus légère. Au lieu d’un long document rédigé en amont, le plan reste bref et se révise à chaque sprint, c’est-à-dire à chaque cycle court de développement. Les révisions portent sur le périmètre, les appareils, les responsables et la définition du fini. Sans cette référence commune, des livraisons fréquentes laissent passer des zones non testées, puisque chaque sprint se concentre sur le nouveau travail.
Découvrez le plan de test réel derrière notre travail sur plus de 100 sites web éducatifs Keystone
