Tâche: Définition des besoins en évaluation et en traçabilité
Cette tâche explique comment définir les exigences de l'évaluation et de la traçabilité, ainsi que la stratégie globale qui sera adoptée.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Etapes
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 :

Niveau de qualité acceptable Haut de la page

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.

Intégration de processus et d'outils Haut de la page

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 :

Analyse de la couverture de test Haut de la page

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.

Analyse des résultats de test Haut de la page

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.

Analyse des erreurs Haut de la page

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.



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