- Nom
- Nom de l'état suivant dans le workflow une fois que cette action aura été effectuée sur l'incident. Par exemple, dans le workflow
par défaut, quand un incident Non Vérifié est validé comme anomalie, Issue Manager fait passer l'incident à l'état suivant, Prêt pour Dév.
- Code Cause
- Mot-clé facultatif indiquant le motif du passage de l'état actuel au nouvel état quand l'action est prise. Sélectionnez l'option
appropriée :
- Aucun Changement
- Aucun Changement indique que le mot-clé est conservé lors du passage de l'incident au nouvel état. Le mot-clé apparaîtra dans
le champ Code Cause de la page Détails de l'incident. Par exemple, le workflow suivant montre que, lorsqu'un développeur déclare
avoir corrigé une anomalie, celle-ci passe à l'état Prêt pour QA avec un code de cause Corrigé. Si un ingénieur QA valide
la déclaration, l'anomalie passe à l'état Fermé en conservant le code de cause Corrigé. N'importe quel utilisateur qui parcourt
les anomalies peut voir pourquoi l'anomalie est fermée, il lui suffit de lire le code de cause.
- Effacer
- Indique que le code de cause de l'état actuel sera supprimé lors du passage de l'anomalie vers un nouvel état. Effacer est
un choix judicieux lorsqu'une anomalie est renvoyée vers un état antérieur dans le workflow. Par exemple, lorsqu'un développeur
déclare avoir corrigé une anomalie, celle-ci passe à l'état Prêt pour QA avec un code de cause Corrigé. Toutefois, si la correction est rejetée, l'anomalie est renvoyée au Développement (Prêt pour Dév) et le code de cause Corrigé est supprimé, puisque la déclaration est contestée. Quand vous choisissez Effacer, le workflow affiche EFFACER dans le champ Code Cause ; toutefois, l'utilisateur verra un champ Code Cause vierge dans la page Détails de l'incident.
- Valorisé à
-
indique que vous pouvez associer un code de cause à cette action. Saisissez un mot-clé de 20 caractères maximum. Nous recommandons
de tout écrire en majuscules. Utilisez Fixé à pour préciser un code de cause quand une action fait passer un incident à un nouvel état qui exige un code de cause. En général,
vous devriez affecter des codes de cause à toutes les actions prises par les développeurs.
Par exemple, dans le workflow par défaut, l'action Corrigé sur l'état Prêt pour Dév envoie l'incident vers l'état Prêt pour QA en lui affectant le code de cause Corrigé. Traduit en interactions humaines, cela signifie que lorsqu'un développeur déclare qu'une anomalie a été corrigée, il passe
la main à un ingénieur QA qui peut alors facilement consulter la page Détails de l'incident pour y découvrir les raisons de la présence de cette anomalie dans sa boîte de réception (il est possible que l'anomalie
s'y trouve parce que le développeur ne peut pas la corriger ou parce que le logiciel fonctionne comme prévu).
Si vous n'utilisez pas de codes de cause
Les codes de cause sont des mots-clés facultatifs susceptibles de limiter le nombre d'états de votre workflow. Par exemple,
au lieu de définir plusieurs états de fermeture (Pas une Anomalie, Non Reproductible, Non Repro et Doublon), un seul état terminal suffit quand l'utilisation de codes de cause permet d'expliquer les raisons pour lesquelles l'état
Fermé est affecté à l'anomalie. Si vous choisissez de vous passer des codes de cause, vous devrez probablement définir plusieurs
états terminaux. Pour définir un état comme terminal, sélectionnez la case d'option Aucun (État Terminal) affiché parmi les choix dans le champ Propriétaire de l'État de la boîte de dialogue Propriétés de l'État.