Identifier les exigences d'évaluation et de traçabilité
Objectif :
|
Comprendre les livrables du processus d'évaluation du logiciel et recueillir les exigences associées.
|
Effectuez une revue du plan d'itération et identifiez les exigences d'évaluation propres à cette part du travail.
Demandez aux parties prenantes leurs exigences en matière d'évaluation et de traçabilité.
Vous devez également tenir compte du fait que l'effort de test sera formellement audité au cours de l'exécution des
tests ou à la fin des tests. Pour les besoins de cet audit, vous devrez peut-être conserver la documentation et les
enregistrements qui constituent la preuve qu'un nombre suffisant de tests a été réalisé.
|
Tenir compte des contraintes
Objectif :
|
Identifier les contraintes qui affecteront la possibilité ou la nécessité d'implémenter les
exigences.
|
En règle générale il existe une liste sans fin de "désirs" que vous pouvez être tenté de considérer comme des exigences
de traçabilité et de stratégie d'évaluation, mais il est important de vous concentrer sur les "besoins" les plus
importants qui a) fournissent des informations essentielles à l'équipe du projet et qui b) peuvent être réellement
tracés et mesurés. Il est peu probable que vous disposiez de suffisamment de ressources pour traiter d'autres exigences
que celles qui sont essentielles.
Sous-rubriques :
Il est important d'identifier le niveau de qualité considéré comme suffisamment bon et de développer une stratégie
d'évaluation appropriée. Il arrive souvent que les dimensions et les niveaux de qualité fluctuent aux yeux des parties
prenantes au cours du cycle de vie du projet.
Révisez le plan qualité, le plan de développement logiciel et interrogez les parties prenantes elles-mêmes afin de
déterminer le niveau de qualité acceptable à leurs yeux.
Même si vous rêvez d'un monde dans lequel, sans effort, la traçabilité et l'évaluation s'effectueraient à un faible
niveau de granularité, la réalité est bien différente : il est difficile et généralement onéreux d'implémenter de
telles approches. Si vous possédez des outils sophistiqués, la gestion d'approches de traçabilité à faible niveau de
granularité reste difficile et consommatrice de temps ; sans outils, elle est pratiquement impossible à réaliser. Le
processus de génie logiciel lui-même apporte des contraintes de traçabilité : par exemple, si la traçabilité des tests
aux exigences qui les ont motivés est requise, mais que les exigences elles-mêmes ne sont pas gérées avec soin, il peut
s'avérer impossible d'implémenter cette traçabilité.
En tenant compte des contraintes et des limitations des processus et des outils de génie logiciel, choisissez une
approche de traçabilité et d'évaluation.
|
Envisager les stratégies possibles
Objectif :
|
Identifier et présenter une ou plusieurs stratégies qui faciliteront le processus d'évaluation requis.
|
Maintenant que vous avez une meilleure connaissance des exigences en matière d'évaluation et de traçabilité, ainsi que
des contraintes induites par le niveau de qualité souhaité et par la disponibilité des outils et des processus de
support, vous devez envisager les stratégies d'évaluation potentielles à utiliser. Pour obtenir une description plus
détaillée des stratégies possibles, nous vous suggérons de lire l'article de Cem Kaner intitulé "Measurement of the Extent of Testing", daté
d'octobre 2000. (Télécharger Adobe Reader)
Sous-rubriques :
Il existe différentes approches traitant de la couverture de test, et aucune mesure ne fournit à elle seule toutes les
informations nécessaires à l'évaluation de l'étendue de l'effort de test. Il est à noter que différentes stratégies de
couverture nécessitent un effort d'implémentation plus ou moins élevé, et qu'au sein d'une catégorie de mesure
spécifique, il existera toujours un niveau d'analyse de couverture au-delà duquel l'enregistrement de données plus
détaillées devient onéreux.
Voici quelques catégories de mesure de couverture de test : exigences, code source, réclamations produit et normes. Il
est recommandé de prévoir plusieurs catégories de couverture dans votre stratégie d'évaluation de test. Dans la plupart
des cas, la couverture de test se réfère à la planification et à l'implémentation de tests spécifiques en première
instance. Toutefois, les mesures de couverture de test et leurs analyses sont également utiles à prendre en compte en
les associant aux résultats des tests ou à l'analyse des erreurs.
Une méthode simple consiste à faire référence au nombre de résultats positifs ou négatifs (pourcentage du nombre total
de tests exécutés). Nous partageons l'avis de nombreux spécialistes des tests qui consiste à dire qu'il s'agit là d'une
méthode simpliste et incomplète d'analyse des résultats de tests.
Nous recommandons une analyse des résultats de tests en termes de tendance relative sur de longues périodes. Lors de
chaque cycle de tests, examinez la répartition des échecs de tests pour différentes dimensions telles que le domaine
fonctionnel testé, le type de risque exploré, la complexité relative des tests et les ressources consacrées à chaque
domaine fonctionnel.
Alors que les erreurs elles-mêmes sont objectivement liées aux résultats de l'effort de test, l'analyse des données
d'erreur ne fournit aucune information utile sur le déroulement de l'effort de test ou sur l'état d'achèvement de cet
effort. Toutefois, certaines équipes de test et certains chefs de projet utilisent à tort le nombre d'erreurs en cours
pour mesurer le déroulement des tests ou la qualité du logiciel développé. Il nous semble que cette approche n'a pas de
sens.
Nous privilégions l'analyse de la tendance relative des erreurs sur la durée, ce qui constitue une mesure d'une
relative stabilité. Par exemple, supposons que l'effort de test soit relativement constant : vous vous attendez en
général à voir le nouveau taux de détection d'erreurs mesuré régulièrement représenter une "courbe en forme de cloche"
sur toute la durée de l'itération ; un taux de détection croissant qui parvient à son point culminant puis diminue
progressivement jusqu'à la fin de l'itération. Toutefois, vous devez fournir ces informations en les associant à
l'analyse d'autres mesures d'erreurs telles que les taux de résolution d'incidents (avec analyse du type de
résolution), la répartition des erreurs par niveau de gravité et par domaine fonctionnel.
Si vous disposez d'outils sophistiqués, vous pouvez assez facilement effectuer des analyses complexes d'erreurs ; dans
le cas contraire, cela est beaucoup plus difficile.
|
Discuter des stratégies possibles avec les parties prenantes
Objectif :
|
Recueillir les appréciations en retour des parties prenantes et modifier les stratégies en
conséquence.
|
Présentez les stratégies possibles aux différentes parties prenantes. Elles forment généralement un groupe composé des
rôles suivants : chef de projet, architecte du logiciel, responsable du développement, analyste système, responsable
des modifications de configuration, responsable du déploiement et représentant du client. Chacun de ces postes joue un
rôle dans la façon dont la qualité est évaluée.
En fonction de la culture du projet, vous devez choisir une forme appropriée pour présenter les stratégies possibles.
Cela peut aller des réunions informelles aux présentations formelles ou ateliers.
|
Définir et convenir de la stratégie d'évaluation
Objectif :
|
Obtenir l'accord des parties prenantes sur la stratégie à utiliser.
|
Grâce au retour d'informations obtenu lors des discussions, affinez la stratégie d'évaluation de telle sorte qu'elle
réponde aux besoins de toutes les parties prenantes.
Présentez la stratégie d'évaluation en vue d'obtenir un accord final et une approbation.
|
Définir les exigences en matières d'outils
Objectif :
|
Définir les exigences de configuration des outils pour le processus d'évaluation.
|
Comme mentionné précédemment, vous pouvez assez facilement effectuer des analyses complexes si vous disposez d'outils
sophistiqués ; sinon, cela est beaucoup plus difficile.
Pour les catégories suivantes, déterminez les outils requis : couverture et traçabilité, analyse des erreurs.
|
Evaluer et vérifier vos résultats
Objectif :
|
Vérifier que la tâche a été correctement réalisée et que les produits en résultant 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. A chaque fois que cela est 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.
|
|