> Tech > Exécuter le plan

Exécuter le plan

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

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

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010