Objet :
|
Entrer des informations de demande de changement dans un outil de suivi à des fins d'évaluation, de gestion
et de résolution d'incidents.
|
Les différences relevées indiquent des défauts potentiels dans les éléments de test cible et doivent être entrées dans
un système de suivi sous la forme d'incidents ou de demandes de changement, avec mention des actions correctives à
exécuter.
Sous-rubriques :
Vérifiez que des données précises sont disponibles. Rassemblez ces informations et rattachez-les directement aux
demandes de changement ou indiquez où elles peuvent être obtenues.
Chaque fois que vous le pouvez, vérifiez si le problème risque de se reproduire. Les problèmes qui risquent de se
reproduire attirent l'attention des développeurs et ont donc plus de chances d'être résolus. En revanche, un problème
isolé frustre l'équipe de développement et gaspille de précieuses ressources de programmation dans des recherches
stériles. Il est conseillé de consigner ces incidents malgré tout, mais de bien marquer la différence entre les
incidents qui risquent de se reproduire et les autres.
Il est important que les demandes de changement soient claires, et tout particulièrement leur titre. Assurez-vous que
le titre est concis et qu'il présente clairement le thème traité. Un titre bref facilite la lecture des listes
récapitulatives de défauts et les discussions au cours des réunions sur l'état d'avancement CCB.
Il est également important que la description détaillée de la demande de changement ne comporte aucune ambiguïté et
puisse être facilement interprétée. Consignez les demandes de changement dès que possible, mais prenez le temps d'y
revenir et d'apporter des améliorations aux descriptions avant que celles-ci ne soient consultées par l'équipe de
développement.
Indiquez le plus grand nombre possible de solutions potentielles. Si une ambiguïté figurait encore dans la description,
cela permet de l'éclaircir. Cela augmente également la probabilité d'une solution proche de vos indications. Par
ailleurs, cela illustre le fait que l'équipe de test n'a pas uniquement pour but de détecter les incidents, mais
également d'identifier les solutions appropriées.
Vous pouvez inclure des captures d'écrans, des fichiers de données de test, des scripts de tests automatisés, des
résultats d'utilitaires de diagnostic et toute autre information susceptible d'aider les développeurs à isoler et à
corriger le problème.
Fournissez à l'équipe de gestion et à l'équipe de développement une indication du niveau de gravité de l'incident. Dans
les très grandes équipes, la priorité de résolution est généralement laissée à l'appréciation de l'équipe de gestion.
Toutefois, vous pouvez autoriser d'autres personnes à indiquer la priorité de résolution qu'ils souhaitent et en tenir
compte par la suite. En règle générale, il est recommandé d'affecter par défaut aux demandes de changement une priorité
de résolution moyenne, puis d'augmenter ou de diminuer cette valeur au cas par cas, selon les besoins.
Il se peut que vous ayez besoin de faire la distinction entre l'impact qu'aura la demande de changement sur
l'environnement de production et l'impact qu'elle aura sur l'effort de test si elle n'est prise en compte ; l'équipe de
gestion a tout autant besoin de connaître l'impact d'un incident sur l'effort de test que d'avoir conscience de la
gravité pour les utilisateurs.
Il est parfois difficile de comprendre à l'avance pour quelles raisons vous avez besoin de ces deux informations. Il
peut arriver qu'un incident soit réellement grave (comme dans le cas d'une panne système par exemple), mais que les
actions à entreprendre soient peu susceptibles de se reproduire. Dans ce cas, l'équipe peut indiquer un niveau de
gravité élevé tout en affectant une priorité de résolution très faible.
Les incidents sont souvent l'occasion de mentionner le vieil adage selon lequel "Il n'y a pas de fumée sans feu" :
lorsque vous identifiez et consignez une demande de changement, il arrive souvent que d'autres questions se présentent.
Ne cédez pas à la tentation d'ajouter tout simplement ces dernières à la demande de changement en cours : si elles sont
directement liées et facilitent la résolution de l'incident en cours de traitement, cela ne posera pas de problème,
mais si elles ne sont pas liées, le fait de les mentionner dans une demande de changement existante risque de poser
certains problèmes (non déclenchement de leur traitement, absence d'affectation de la priorité requise, voire impact
sur la vitesse de traitement d'autres incidents).
|