Tâche: Organiser l'implémentation du test
Cette tâche décrit comment définir la structure d'ensemble pour l'implémentation de la suite de tests.
Disciplines: Test
Objet

L'objectif de cette tâche est de :

  • Mettre en place la structure qui accueillera l'implémentation de la suite de tests
  • Attribuer des responsabilités pour les domaines d'implémentation de la suite de tests et leur contenu.
  • Décrire les suites de tests requises
Relations
RôlesExécutant principal: Exécutant supplémentaires:
EntréesObligatoire: Facultatif:
Sorties
Utilisation des processus
Etapes
Examen des approches de test, des éléments de test cible et des besoins d'évaluation
Objet :  Comprendre comment les tests seront évalués et leurs implications sur la façon dont les suites de tests doivent être implémentées afin d'évaluer les éléments de test ciblés. 

En commençant par une revue du plan de test pour déterminer les besoins en évaluation, examinez comment l'évaluation de l'ampleur du test et de la qualité des logiciels peut être déterminée en utilisant la démarche de test citée. Prenez en compte tous les besoins spécifiques associés aux éléments de test ciblés et devant être traités.

Examen des mécanismes de testabilité et des éléments de prise en charge
Objet :  Comprendre les éléments de testabilité disponibles, les mécanismes qu'ils supportent et les avantages qu'ils offrent. 

Revoyez les mécanismes utiles pour permettre les tests dans cet environnement, et identifiez les éléments de testabilité spécifiques qui implémentent ces mécanismes. Cela implique la révision de certaines ressources comme les bibliothèques de fonctions qui ont été développées par l'équipe de test et les éléments de remplacement ou les équipements implémentés par l'équipe de développement.

La testabilité est obtenue en développant des logiciels pouvant être testés et en définissant une démarche gérant les tests de façon adéquate. Ainsi, la testabilité est un aspect important du développement des actifs de l'équipe de test, ainsi qu'une part importante de l'effort de développement logiciel. Une testabilité réussie (la capacité de tester le produit logiciel de manière efficace) comportera généralement une combinaison de :

  • facilitateurs de testabilité fournis par des outils d'automatisation des tests
  • techniques spécifiques pour créer le composant Scripts de test
  • bibliothèques de fonctions séparant et intégrant des éléments complexes de la définition procédurale basique des tests dans le script de texte, ce qui procure un élément central de contrôle et de modification.

Analyse des exigences de distribution

La suite de tests actuelle doit-elle être distribuée ? Si c'est le cas, utilisez les éléments de testabilité gérant la distribution. Ces éléments sont généralement des caractéristiques d'outils de support d'automatisation spécifiques qui distribueront la suite de tests, l'exécutent à distance et rapatrient le journal du test et les autres résultats afin de déterminer les résultats de manière centralisée.

Analyse des exigences d'accès concurrent

La suite de tests actuelle doit-elle être exécutée en même temps que d'autres suites de tests ? Si c'est le cas, utilisez les éléments de testabilité qui gèrent la simultanéité. Ces éléments sont généralement une combinaison d'outils de support et de fonctions utilitaires spécifiques permettant à des suites de tests multiples d'être exécutées simultanément sur différentes machines physiques. La simultanéité implique une gestion et une conception soignées des données de test, afin de s'assurer qu'aucun effet secondaire imprévu ou non programmé n'ait lieu comme par exemple deux tests simultanés mettant à jour le même enregistrement de données.

Création de la structure initiale de la suite de tests
Objet :  Décrire la ou les suites de tests à implémenter. 

Enumérez une ou plusieurs suites de tests qui (lors de l'exécution) fourniront des valeurs complètes et significatives à l'équipe de test, permettant de présenter un compte-rendu aux parties prenantes. Essayez de trouver un compromis afin de donner assez de détails pour fournir des informations spécifiques à l'équipe du projet, sans tomber dans un excès d'information impossible à gérer.

Si des scripts de test existent déjà, vous pouvez probablement assembler vous-même la suite de tests et ses composants, puis confier le travail de stabilisation de la suite de tests à la personne chargée de l'implémentation des tests.

Lorsqu'il est nécessaire de créer de nouveaux scripts de test pour les suites de tests, vous devez aussi fournir des indications sur les scripts de test - ou les autres suites de tests - qui selon vous doivent être référencées par cette suite de tests. Lorsqu'il est facile de les énumérer, faites-le. Sinon, il vous suffit de fournir une description rapide décrivant la couverture de contenu prévue de la suite de tests principale et de charger la personne responsable de l'implémentation de la suite de tests de prendre les décisions tactiques concernant les scripts de test inclus.

Adapter la structure de la suite de tests en fonction de l'organisation de l'équipe et des contraintes en termes d'outils
Objet :  Préciser la structure de la suite de tests correspondant le mieux aux responsabilités de l'équipe. 

Il peut s'avérer nécessaire de sous-diviser ou de restructurer plus en profondeur les suites de tests que vous avez identifiées afin de respecter la structure de répartition du travail (WBS) sur laquelle l'équipe travaille. Cela permettra de réduire le risque de conflits d'accès pendant le développement de la suite de tests. Parfois les outils d'automatisation de test imposent des contraintes sur la façon de travailler avec les actifs d'automatisation et il est donc nécessaire de restructurer la suite de tests pour répondre à ce problème en cas de besoin.

Identification des mécanismes de communication des scripts inter-test
Objet :  Identifier les données de test et l'état du système devant être partagés ou transmis entre scripts de test. 

Dans la majorité des cas, les suites de tests peuvent simplement appeler les scripts de test dans un ordre spécifique. Généralement, cela sera suffisant pour s'assurer que l'état du système est transféré d'un script de test à un autre.

Cependant, dans certains types de systèmes, des données d'exécution dynamiques sont générées par le système ou obtenues à la suite des transactions qui ont eu lieu dans le système. Par exemple, dans un système de saisie et de distribution des commandes, chaque fois qu'une commande est saisie, un numéro de commande unique est généré par le système. Pour permettre à un script de test automatisé de distribuer une commande, un script de test préalable de saisie de commande doit consigner le numéro unique généré par le système et le transférer au script de test de distribution de la commande.

Dans des cas comme celui-ci, vous devez déterminer le mécanisme de communication de scripts inter-test approprié. Les alternatives peuvent être de transférer les paramètres, d'écrire et lire les valeurs sur un fichier disque, ou d'utiliser des variables d'exécution globales. Toutes ces stratégies ont des avantages et des inconvénients qui font qu'elles sont plus ou moins adaptées à chaque situation spécifique.

Définition des dépendances initiales entre les éléments de la suite de tests
Objet :  Identifier et enregistrer les dépendances d'exécution entre des éléments de la suite de tests. 

Cette activité est principalement associée au classement des scripts de test et éventuellement des suites de tests pour l'exécution. Les tests exécutés sans que les dépendances correctes soient établies courent le risque d'échouer ou bien de rendre compte de données incorrectes.

Modélisation visuelle de l'architecture d'implémentation des tests
Objet :  Utiliser un diagramme pour documenter et expliquer la réalisation d'une implémentation de test. 

Si vous avez accès à un outil UML de modélisation ou de dessin, vous souhaiterez peut-être créer un diagramme du modèle d'implémentation de test représentant les éléments clés du logiciel de test automatisé. Vous pouvez aussi effectuer de la même manière un diagramme des aspects cruciaux de l'architecture d'automatisation des tests.

Une autre approche consiste à dessiner ces diagrammes sur un tableau blanc que l'équipe du test peut voir facilement.

Précision de la structure de la suite de tests
Objet :  Effectuer les ajustements nécessaires pour maintenir l'intégrité de l'implémentation du test. 

Au fur et à mesure de la progression du projet, les suites de tests sont susceptibles de changer : de nouveaux scripts de test seront ajoutés et d'anciens scripts de test mis à jour, reclassés ou supprimés. Ces changements s'intègrent naturellement à la maintenance des suites de tests et vous devez les intégrer plutôt que les éviter.

Si vous n'effectuez pas une maintenance active des suites de tests, elles se dégraderont rapidement et ne pourront plus être utilisées. Si une suite de tests est abandonnée pendant plusieurs versions, il faut parfois des efforts considérables pour la remettre en état, et il peut être plus facile de l'abandonner complètement et d'en créer une nouvelle. Voir la section Plus d'informations du tableau d'en-tête de cette page pour plus de conseils sur la maintenance des suites de tests automatisées.

Maintien des relations de traçabilité
Objet :  Permettre à l'analyse et à l'évaluation de l'impact d'être réalisés sur les éléments tracés. 

Utilisez les exigences de traçabilité mentionnées dans le plan de test pour mettre à jour les relations de traçabilité.

Evaluation et vérification de vos résultats
Objet :  Vérifier que la tâche a été correctement réalisée et que les produits qui en résultent sont acceptables. 

Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez déterminer si votre travail est d'une qualité correcte et s'il est suffisamment complet pour que les membres de l'équipe puissent l'utiliser comme entrée pour leur propre travail. A chaque fois que cela est possible, utilisez les listes de contrôle fournies dans le processus RUP pour vérifier que la qualité et l'achèvement sont "suffisamment bons".

Faites en sorte que les personnes qui effectuent des tâches en aval qui se basent sur votre travail en tant qu'entrée prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux produits d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée revoie votre travail sur cette base.

Essayez de vous rappeler que le processus RUP est un processus itératif de livraison et que, dans la plupart des cas, les produits évoluent avec le temps. A ce titre, il n'est pas habituellement nécessaire, et c'est même souvent contre-productif, de concevoir complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Cela vient du fait qu'il y a une grande probabilité pour que la situation qui entoure le produit change et que les hypothèses émises lors de la création du produit s'avèrent incorrectes, avant même l'utilisation du produit, occasionnant une perte d'efforts et un retravail coûteux. Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique en tant que livrable du projet, vous pouvez envisager d'utiliser des ressources administratives pour réaliser les tâches de présentation.



Plus d'informations