Comprendre les objectifs de l'itération
Objectif :
|
Appréhender l'étendue et les objectifs du plan d'itération.
|
Examinez le plan d'itération et identifiez son étendue et ses objectifs.
Il est conseillé de compléter cet examen par des discussions informelles avec le personnel chargé du projet
(responsable de projet, architecte logiciel et décideur côté client) ; ces réunions permettent souvent d'expliciter
certains points abordés dans le plan. La participation aux réunions de lancement d'itération permet également de
rassembler des informations utiles.
|
Examiner les options de la portée de l'effort d'évaluation
Objectif :
|
Comprendre les attentes des parties prenantes afin de déterminer l'étendue de l'effort d'évaluation.
|
La mission représente le principe qui guide l'effort de test pendant une période donnée. Les ressources de test sont
généralement limitées ; par conséquent, l'objectif consiste à obtenir un équilibre entre les contraintes de ressources
de test et les besoins de validation de la qualité induits par l'effort de développement d'applications.
Appréhender les attentes stratégiques de l'équipe de développement d'applications. Vous devez principalement recueillir
les attentes du responsable de projet, de l'architecte logiciel et des analystes système.
|
Présenter les options aux parties prenantes
Objectif :
|
Obtenir un retour d'informations des parties prenantes sur les objectifs et l'étendue de l'effort de
test.
|
Il n'est pas très utile de traiter les objectifs et l'étendue en dehors du reste de l'équipe chargée du projet. RUP
préconise d'octroyer la propriété de la qualité du produit à l'équipe, et à ce titre vous devez adjoindre les parties
prenantes concernées issues du reste de l'équipe lorsque vous déterminez ce qu'il est important de tester. Vous devez
considérer les membres de l'équipe qui remplissent les rôles suivants comme d'importantes parties prenantes :
responsable de projet, architecte, analyste système, intégrateur.
Dans certains cas, la présentation doit être formelle, les parties prenantes agissant en tant que comité d'audit ; elle
nécessite une longue préparation préalable. Dans d'autres cas, des déjeuners informels peuvent être adaptés, ou une
entrevue avec chacune des parties prenantes. Chacune de ces approches présente des avantages et des inconvénients :
choisissez simplement en fonction de vos besoins dans le contexte de l'environnement du projet actuel.
|
Formuler la déclaration de mission
Objectif :
|
Identifier clairement l'essence des tests pour l'itération en cours.
|
Les déclarations de mission fournissent des éclaircissements utiles aux équipes, spécialement dans les situations dans
lesquelles l'équipe a plusieurs choix possibles. Les équipes de test sans mission d'évaluation considèrent souvent
qu'elles "effectuent simplement des tests" : cela n'apporte pas beaucoup d'éléments lorsque des choix difficiles
doivent être faits en tenant compte de contraintes de temps ou de ressources. Une déclaration de mission distille
l'essence de l'objectif de travail en cours et fournit un "mantra" permettant à l'équipe de se concentrer sur
l'essentiel.
Formulez une déclaration de mission pouvant être utilisée par l'équipe de test. Elle ne doit pas être trop complexe, ni
contenir trop d'idées conflictuelles : les meilleures déclarations de mission sont simples, brèves et dans la plupart
des situations impliquant une prise de décision, elles facilitent le choix de l'option fait par l'équipe.
Voici quelques idées de déclarations de missions à adopter pour vos itérations :
-
identifier le plus grand nombre possible de bogues
-
détecter rapidement les problèmes importants
-
évaluer les risques qualité perçus
-
donner un avis en matière de risques projet
-
renseigner sur la qualité apparente
-
certifier une norme
-
vérifier une spécification (exigences, conception ou réclamations)
-
garantir la satisfaction des parties prenantes
-
remplir les mandats de processus
En examinant cette liste, vous pouvez constater que de nombreuses missions sont mutuellement exclusives. Par exemple,
si ma mission est de "détecter rapidement les problèmes importants", je ne serai sans doute pas capable de "vérifier
une spécification" : Pour mener à bien une mission, il faut souvent en refuser d'autres et adopter une approche de test
différente.
Les équipes de test qui tentent de satisfaire un trop grand nombre de missions d'évaluation rencontrent fréquemment des
situations de conflit dans leur travail. Il est également recommandé de choisir ou de reconsidérer votre mission
d'évaluation dans chaque itération : il est naturel que la mission évolue dans la durée en fonction du contexte de
travail.
|
Identifier les résultats attendus de test
Objectif :
|
Spécifier la valeur à retirer de l'effort de test.
|
Certains produits sont des résultats importants pour une ou plusieurs parties prenantes : d'autres produits
représentent des parties nécessaires de l'effort de test et bien qu'ils sont importants pour l'équipe de test, ils
présentent peu d'intérêt pour ces mêmes parties prenantes.
Indiquez approximativement le nombre minimal d'éléments livrables pour l'effort de test. Ne dressez pas la liste de
tous les produits, mais indiquez uniquement ceux qui présentent un intérêt direct et tangible pour les parties
prenantes et ceux qui serviront à mesurer l'efficacité de l'effort de test. Vous pouvez modifier la liste initiale pour
vous adapter aux besoins manifestés par les parties prenantes, mais vous devez dans ce cas veiller à ce que les
éléments livrables restent utiles et facilement gérables.
|
Obtenir l'accord des parties prenantes
Objectif :
|
Négocier avec toutes les parties prenantes pour obtenir un accord sur la mission la plus adaptée à
l'itération.
|
Comme pour l'étape précédente Présenter les options aux parties prenantes, vous devez
obtenir l'accord de ces parties prenantes sur l'adaptation de la mission d'évaluation et du support associé à
l'itération.
Là aussi, indiquez approximativement la façon dont vous envisagez de présenter la mission et d'obtenir les accords
requis. Choisissez celle qui répond le mieux à vos besoins dans le contexte de l'environnement de projet actuel.
|
Evaluer et vérifier vos résultats
Objectif :
|
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 évaluer si votre travail est d'une
qualité correcte et qu'il est assez complet pour être utile aux membres de l'équipe qui en feront un usage ultérieur
comme entrée pour leur propre travail. Si possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que
la qualité et l'exhaustivité sont "satisfaisantes".
Faites en sorte que les personnes qui effectuent les 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 de livraison itératif et que dans de nombreux cas, les produits
évoluent au fil du temps. A ce titre, il n'est généralement pas 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.
Ceci parce 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 ainsi
une perte d'efforts et une coûteuse reprise. 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 résultat d'un projet, vous pouvez envisager d'utiliser une ressource
administrative pour réaliser les tâches de présentation.
|
|