Tâche: Définir l'approche de test
Cette tâche explique comment définir la stratégie de test et les techniques spécifiques à utiliser, et présente un aperçu de l'architecture d'automatisation des tests.
Objet

Les différents objectifs de cette tâche sont les suivants :

  • Identifier chaque technique spécifique qui sera utilisée pour l'exécution des tests souhaités.
  • Présenter le fonctionnement de chaque technique, y compris les types de tests pris en charge.
  • Définir une architecture candidate pour le système d'automatisation des tests.
Relations
Etapes
Examen des motivateurs de test et des éléments de test
Objet :  Connaître l'influence de la mission, des motivateurs de test et des éléments de test sur l'approche de l'effort de test suivant. 

Dans le contexte de la mission d'évaluation, examinez le plan de test de l'itération et étudiez les motivateurs de test identifiés pour l'effort de test suivant. Il peut être nécessaire d'effectuer des recherches supplémentaires au niveau du motivateur (en règle générale, le plan d'itération contient une méthode de recherche d'informations supplémentaires).

Pour chaque motivateur, recherchez l'approche de test et les techniques associées susceptibles d'être requises. Examinez également le plan de test de l'itération et étudiez les éléments de test. Chaque élément de test cible doit être considéré en relation avec chaque motivateur ; l'approche et les techniques doivent être adaptées en conséquence. Si vous ne trouvez pas un grand nombre d'informations sur les éléments de test ou si vous n'êtes pas familiarisé avec ceux-ci, il peut être utile que vous discutiez des éléments cible avec l'équipe de développement (en commençant par l'architecte du logiciel et les responsables de l'équipe de développement).

Veillez surtout à identifier le nombre minimal de techniques nécessaires à la réussite de la mission d'évaluation et des motivateurs. Privilégiez les techniques qui peuvent répondre à plusieurs aspects à la fois des tests requis. Prenez note des autres techniques potentielles qui vous semblent intéressantes à explorer, mais considérez-les comme facultatives et non essentielles.

Examen de l'architecture logicielle
Objet :  Prendre en compte l'influence de l'architecture logicielle sur l'approche de test. 

Etudiez l'architecture logicielle pour bien comprendre ses éléments et mécanismes clés, ses vues principales, entre autres. Le document d'architecture du logiciel fournit généralement de bonnes informations et un bon niveau de détails, ce qui facilite leur utilisation au sein d'une approche de test. Pour clarifier ces informations ou en l'absence de ce document, discutez de l'architecture avec l'équipe de développement (adressez-vous directement à l'architecte du logiciel ou à l'un des responsables de l'équipe de développement).

Limitez-vous à identifier et à discuter des mécanismes clés, et à bien comprendre ces aspects du système. Chaque mécanisme et chaque fonction clé de l'architecture présente sans doute des défis ou des contraintes applicables à l'effort de test. Par exemple, une architecture répartie peut nécessiter la constitution de sous-groupes au sein de l'équipe de test, chacun d'entre eux étant chargé d'un niveau architectural.

Vous pouvez souvent utiliser une stratégie créative d'exécution et d'implémentation de tests pour relever ces défis, mais vous devrez peut-être demander à l'équipe de développement de modifier le logiciel à des fins de test, comme indiqué dans l'Activité : Définition des éléments de testabilité.

Prise en compte du caractère général et détaillé de l'approche de test
Objet :  Evaluer l'état d'achèvement de l'approche de test (caractère général et détaillé). 

Avec toutes les informations dont vous disposez désormais sur les exigences de l'approche de test, prenez du recul et envisagez l'approche de test avec un peu de hauteur. Quels éléments ne sont pas inclus dans l'approche de test alors qu'ils le devraient ? Certaines questions à explorer sont-elles absentes des informations recueillies ?

Sur la base de votre expérience, révisez les exigences de l'approche de test en leur attribuant un caractère général et détaillé adapté à cette étape du cycle de vie du projet. Etudiez d'autres exigences qui permettent de compléter l'approche.

Identification des techniques de test existantes à réutiliser
Objet :  Réutiliser ou adapter des techniques de test existantes et dont l'efficacité a été prouvée, en cas de besoin. 

A partir de votre propre expérience ou des informations auxquelles vous avez accès, identifiez les techniques existantes susceptibles de répondre aux exigences de l'approche de test ou pouvant être adaptées pour y répondre.

Identification d'autres techniques
Objet :  Identifier les techniques requises dans le cadre d'une approche de test complète. 

Il n'est pas vraiment utile de parler d'une approche de test "complète" : en effet, il existe toujours d'autres techniques que vous pourriez essayer si vous aviez le temps et les ressources correspondantes.

Toutefois, il est important qu'elle soit suffisante et bien élaborée afin que l'évaluation puisse percevoir efficacement la qualité testée. Cette approche doit donc évaluer un nombre suffisant d'aspects de qualité, risque ou dimensions de qualité pour que l'équipe projet puisse évaluer la qualité perçue avec un niveau de confiance justifié.

Définition de techniques
Objet :  Présenter le fonctionnement de chaque technique, y compris l'objectif des tests qu'elle aide à réaliser. 

Présentez le fonctionnement de chaque technique. Indiquez le type de test concerné, son objectif et son étendue, les méthodes d'implémentation et d'évaluation utilisées, les oracles de test et les exigences de la technique en termes d'automatisation.

Dans un grand nombre de cas, vous réutilisez une même technique d'un projet à l'autre. Vous pouvez alors simplement établir une définition de la technique ou copier la définition existante et la revoir en fonction de vos besoins.

Pour chaque technique existante ou requise, vous devez :

Définition des objectifs et de l'étendue Haut de la page

Un grand nombre de techniques prend en charge plusieurs types de tests ; prenez le temps d'identifier les tests pris en charge par cette technique. Cela permet d'identifier l'étendue de l'effort requis s'il s'agit d'une définition initiale pour cette technique.

Recherchez les valeurs et les objectifs sous-jacents de cette technique.

Description de la méthode d'implémentation Haut de la page

Définissez la méthode d'implémentation de la technique. Il n'est pas suffisant d'indiquer "Nous effectuons des tests de performances système" ; vous devez bien réfléchir aux méthodes à mettre en oeuvre pour y parvenir.

Certaines techniques que vous aimeriez utiliser seraient très onéreuses à l'emploi. Grâce à la brève description de la méthode d'implémentation de cette technique, vous pouvez donner un sens global à la logistique impliquée et à la pertinence de poursuivre l'utilisation de cette technique.

Identification de la méthode d'évaluation appropriée Haut de la page

Déterminez la façon dont vous souhaitez observer et évaluer les résultats de chaque test implémenté à l'aide de cette technique. Réfléchissez aux différents Oracles de test disponibles (existe-t-il un seul oracle ou différentes méthodes de détermination du résultat de chaque test) ?

Identification du niveau d'automatisation applicable Haut de la page

L'automatisation peut jouer un rôle important dans de nombreuses techniques de test. Dans certains cas, elle peut être moins sophistiquée et offre alors un simple support pour tests manuels.

Réfléchissez à la façon dont le travail réalisé grâce à cette technique pourrait plus efficacement être implémenté et géré. Considérez toutes les options possibles sans vous censurer.

Identification des outils applicables Haut de la page

Identifiez les outils appropriés à utiliser avec cette technique de test. Pour cela, utilisez le travail de l'étape précédente (identification des différentes utilisations d'automatisation).

Tenez compte d'une large gamme de catégories d'outils ; votre liste d'outils potentiels ne doit pas se limiter aux outils d'automatisation de l'exécution de tests. Outre les outils qui permettent d'automatiser l'exécution des tests, pensez aux outils qui augmentent la productivité de l'équipe de test en diminuant le nombre de tâches répétitives, laborieuses (comme par exemple la gestion des données de test, l'analyse des résultats de test, les outils de génération de rapports sur les incidents et les demandes de modification, etc. ).

Présentation d'un aperçu de l'architecture d'automatisation des tests
Objet :  Définir une architecture candidate pour le système d'automatisation des tests. 

Sur la base de votre expérience de systèmes ou de domaines d'incidents semblables, commencez à définir une architecture candidate pour le système d'automatisation des tests.

Il est recommandé de revoir les informations relatives au développement d'architectures logicielles ; elles vous aideront à exécuter cette tâche.

Définition de la stratégie de gestion de la configuration des actifs de test
Objet :  Prendre en compte les exigences de test pour la gestion de la configuration. 

Comme pour beaucoup de produits créés au cours d'un projet de développement logiciel, les actifs de test sont candidates à la gestion de la configuration et au contrôle de version.

Les exigences spécifiques peuvent avoir une complexité variable : cela peut aller de la décision d'utiliser la sauvegarde de base et les services de reprise au support de développement parallèle de scripts de tests automatisés sur plusieurs sites pour différentes versions de la même application.

Réfléchissez à vos exigences de gestion de la configuration et commencez à présenter les besoins logistiques probables pour la satisfaction de ces exigences.

Etude de la disponibilité des actifs réutilisables
Objet :  Réduire le risque et l'effort en réutilisant des actifs existants et ayant prouvé leur efficacité. 

Il arrive parfois que le fait de créer des actifs de toutes pièces ait un sens, parfois non. Tentez de trouver un bon équilibre entre une philosophie de liberté de création et une politique rigide et bureaucratique de création de nouveaux produits.

Une approche est dans certains cas meilleure qu'une autre, et vous devez être suffisamment souple pour pouvoir bénéficier des avantages de chaque méthode.

Enregistrement des informations recueillies
Objet :  Enregistrer les informations importantes sur l'approche de test. 

En fonction du nombre de facteurs concernés (comme par exemple la taille de l'équipe et la culture de l'organisation), les méthodes d'enregistrement des décisions prises sur l'approche de test seront plus ou moins adaptées.

D'une façon générale, il existe deux publics à prendre en compte : l'équipe de gestion qui souhaite revoir ces informations à des fins d'approbation et qui a besoin de connaître les implications logistiques de l'approche, et l'équipe de test qui souhaite utiliser l'approche de test comme guide dans le cadre des tâches à entreprendre. Tentez de trouver un bon compromis afin de répondre à ces deux exigences, peut-être à l'aide d'un Intranet de gestion de projets.

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 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 et qui se basent sur votre travail comme 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 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 former 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 un nouveau travail et une perte d'efforts. 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 comme livrable de projet, vous pouvez envisager d'utiliser une ressource d'administration pour réaliser les tâches de présentation.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations