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 :
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.
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.
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) ?
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.
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.
|
|