Rien ne marche !
Le traitement des tickets de bugs du dépôt à la résolution, comment bien se comprendre ?
Vous avez un contrat de maintenance pour votre site web et le bug que vous avez remonté n’est toujours pas résolu depuis plusieurs jours.
→ Vous êtes énervé : « URGENT rien ne marche »
→ Le développeur a cherché, n’a pas trouvé, ne sait pas quoi vérifier, il est énervé et répond : « TOUT fonctionne » ou simplement rien du tout.
→ Résultat : tout le monde s’énerve…Le bug n’est toujours pas résolu.
Il est important de rappeler que dans un projet informatique toutes les parties ont intérêt à ce que les applications marchent bien.
Alors voici un petit manuel pour que tout se passe bien et que les anomalies puissent être résolues rapidement.
L’utilisation d’un outil de suivi de tickets est indispensable
Lorsqu’un bug est identifié, il doit être déposé sur un outil de bug tracking qui avertit l’équipe de maintenance, et non envoyé par mail (exemples d'outils : Mantis, Redmine, Jira).
Le dépôt sur l’outil de ticket permet d’avertir l’ensemble de l’équipe affectée au projet. Le chef de projet affecte le bug à la personne qui sera la plus à même de le résoudre.
Toute l’équipe a le même niveau d’informations. Il n’y a pas de perte d’informations liées à des absences ou des mails noyés. L’historique, le lien entre les informations et la chronologie des échanges sont sauvegardés.
S’il s’agit d’une action urgente, le chef de projet est généralement joignable par téléphone.
Le développeur doit pouvoir reproduire le bug pour pouvoir le résoudre
Une fois qu’il a reproduit l’erreur, il cherche la cause de l’anomalie. En fonction du « diagnostic », il trouve une solution et corrige le bug en adaptant les développements.
Un ticket n’est pas résolu quand : le développeur ne comprend pas la demande …parce qu’il n’a pas identifié la page concernée et n’arrive pas reproduire l’action.
Les informations contenues dans le ticket sont donc cruciales.
Le dépôt du ticket est indispensable même si des réunions de clarification sont organisées
La rédaction d’un ticket ne doit pas être fastidieuse. Les informations que vous devrez fournir sont :
Le Titre : nom du service + action défaillante
Exemple : moteur de recherche du site, les résultats ne s’affichent pas après une recherche
La Description de l'anomalie : la description doit indiquer
- l’URL de la page
- le (s) Utilisateur (s) test(s)
- l’action effectuée
- les résultats de l’application
- les résultats attendus
Exemple de descriptif pour un bug dans un moteur de recherche :
« sur la page d’accueil, en tant qu’utilisateur non connecté, j’effectue une recherche par mot clé (mot clé utilisé : web) et rien ne s’affiche dans les résultats. Hors il existe au moins deux articles en ligne qui sont concernés : indication des exemples de liens des pages qui devraient remonter dans les résultats de recherche »
Vous pouvez si possible ajouter une capture d'écran avec l'adresse de la page.
La qualification du bug :
Bloquant : vous ne pouvez plus utiliser votre application,
Majeur : une fonctionnalité principale a été affectée et perturbe l’utilisation courante,
Mineur : une fonctionnalité secondaire a été affectée,
Les temps d’interventions par catégorie sont définis dans les conditions de marché.
Dans certains cas, il est assez difficile de bien décrire l'anomalie. Si c'est le cas, un point téléphonique rapide avec votre référent projet est nécessaire. Il précisera les éléments complémentaires dans "les notes" du ticket.
Lors de la résolution, l'équipe de maintenance doit indiquer la procédure de vérification de bon fonctionnement
Lors de la résolution du bug, le développeur ou le chef de projet indique la procédure de test qui permet de vérifier que le dysfonctionnement est corrigé.
Dans la plupart des cas, on doit retrouver les éléments mis en avant dans le ticket, c'est à dire :
- l’URL de la page corrigée
- le (s) Utilisateur (s) test(s)
- l’action effectuée
- les résultats de l’application
- les résultats attendus
Les travaux peuvent être présentés en comité de suivi.
Dernière étape : la fermeture du ticket
Lorsque le ticket a été résolu, le statut est indiqué "résolu" par l'équipe de maintenance. Il convient généralement de "fermer" le ticket.
Souvent cet état "fermé" n'est pas renseigné. Pourtant, il s'agit d'une marque indiquant que le Client valide la bonne livraison des corrections apportées.
Besoin d'un accompagnement pour votre projet applicatif ? N'hésitez pas à nous contacter.