Il nous faut maintenant planifier l’exécution et exécuter le plan. Pour cela, je recommande quelques documents formels. Notre plan de test système établit les règles de base pour la phase de test et fournit des éléments tels que l’étendue, les plannings, les ressources, les éléments à tester, la gestion de
Exécuter le plan
la configuration, et les critères d’entrée et de sortie. Pour un vaste projet de développement système, ce document peut comporter de nombreuses pages. Je vous conseille de consulter la IEEE 829-1983 pour déterminer ce qui est applicable dans votre environnement. (Vous trouverez IEEE 829- 1983 à cette adresse).
Il est inutile de produire un document de 20 pages si votre test système ne comporte que trois programmes à faible risque. Et un document de deux ou trois pages est insuffisant pour une application à haut risque de 20 programmes. L’IEEE est considéré comme l’oracle en matière de standards et de bonnes pratiques Information Systems. Et c’est une riche source d’informations sur tous les aspects de l’ingénierie logicielle. Quand nous rassemblons les plans de test système et les autres documents décrits ci-dessous, nous devons intégrer notre priorité de test. Il nous faudra regrouper nos spécifications de modèle de test de haute, moyenne et basse priorité dans des groupes logiques.
Le document de conception de test est l’endroit où nous spécifions les groupages de cas de tests associés :
• La spécification de conception de test recense les zones système à tester. Elle précise l’objectif, les fonctions à tester, la méthode de test retenue, les identifications de test (avec référence aux cas de tests individuels), et le critère réussite/échec.
• Les cas de tests sont des scripts de test qui spécifient chaque test à effectuer et les résultats qu’on en attend. Ce document est au coeur du test système.
La version IEEE standard est très détaillée, peut-être trop sauf pour les cas de tests les plus complexes. Je préconise l’approche plus simple que montre la figure 2. Ce document rassemble le cas de test et le journal de test dans un format simple d’emploi. Il est bon de faire une référence croisée des documents d’exigences fonctionnelles et des spécifications de conception, le cas échéant, pour la traçabilité des exigences.
• Les journaux de test enregistrent les résultats de cas de tests. Vous pouvez combiner un journal de test avec le cas de test en format tableur.
• Les journaux de problèmes enregistrent les problèmes et les classent en ordre de priorité d’après le risque qu’ils posent à l’entreprise. A moins que votre entreprise utilise la traçabilité des exigences, vous devez utiliser à la fois les exigences documentées de l’utilisateur et la spécification fonctionnelle pour construire les spécifications du modèle de test et du cas de test. Vous serez peut-être surpris de voir des exigences absentes de la spécification fonctionnelle ou des discordances dans l’interprétation.
Téléchargez cette ressource
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le Zero Trust : pourquoi votre entreprise en a besoin
- Cloud souverain : répondre aux enjeux d’hybridation et de maîtrise des dépendances
- Cybermenaces 2026 : l’IA devient la nouvelle arme des attaquants
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
