En matière de maintenance d’application mobile, on sait bien que le temps est compté.
Car vous, entrepreneurs, chefs de projet ou product owners, vous avez souvent un planning très chargé.
Alors, prendre du temps pour envoyer un compte-rendu d’anomalies détaillé vous semble fastidieux ? Peut-être… Avantageux ? Sûrement.
Dans tous les cas, soyez-en convaincu, c’est loin d’être une perte de temps.
Pourquoi ?
Parce que le temps que vous allez consacrer à analyser les contours de la problématique (contexte, outils, cible impactée, etc.) va rendre le processus de résolution plus efficace et plus rapide pour le développeur qui s’en occupera.
Et lorsqu’on connaît le coût/horaire d’un développeur en Tierce Maintenance Applicative, il est raisonnable de réduire les interventions au juste nécessaire.
Comment ? Découvrons-le dans cet article.
Étape 1 : Reproduire l’anomalie pour faciliter le travail de maintenance de votre application mobile
C’est en effet un enjeu majeur de la qualification.
L’idée est de permettre au développeur de réunir toutes les conditions nécessaires afin qu’il puisse reproduire le bug. Car pas de reproduction de bug, peu de chance de résolution.
La règle d’or est donc : une anomalie peut être corrigée uniquement si elle est reproduite.
Pourquoi ?
Parce que si le bug ne peut pas être reproduit, il y a de grandes chances pour que ce ne soit pas un bug. Peut-être est-ce simplement une erreur d’utilisation ou un dysfonctionnement lié à un problème d’environnement ?
Si le bug est reproduit, noter les étapes de reproduction est indispensable :
- pour le développeur dans la démarche de résolution de l’anomalie ;
- pour le testeur qui pourra constater sa disparition (ou pas) après l’intégration du correctif.
Le processus de résolution d’une anomalie nécessite donc de collecter toutes les informations pour reproduire le bug.
Il est important de prendre le temps de réunir ces informations de manière rigoureuse.
Cela vous épargnera les aller-retours chronophages mais nécessaires pour clarifier ce qui reste confus pour les développeurs.
Étape 2 : Évaluer la criticité des anomalies
Ensuite, une fois le bug avéré, il s’agit de le qualifier. C’est-à-dire l’identifier, savoir combien d’utilisateurs sont touchés et de quelles manières, afin d’en déterminer la sévérité.
Pour cela, en matière de maintenance d’application mobile, on qualifie les anomalies selon 3 niveaux de gravité :
- Mineur : la fonctionnalité n’est pas tout-à-fait conforme à ce qui était prévu ;
- Majeur : la fonctionnalité n’est pas conforme à ce qui était prévu, mais un contournement est possible ;
- Bloquant : la fonctionnalité ne peut pas être utilisée.
Étape 3 : Prioriser les interventions de maintenance de votre application mobile
On peut vivre avec un bug mineur. Exemple : « ma vidéo streamée ne fonctionne pas sur mon Wiko sous Android 2.1. »
En revanche, on ne peut pas accepter un bug qui touche une grande partie des utilisateurs : c’est ce que l’on appelle une « core feature ».
Avec ces éléments en main, il vous sera plus facile d’estimer rapidement quand un bug doit être corrigé : Tout-de-suite, cette semaine, ça peut attendre la prochaine release.
Sachez que lorsqu’un lot de tickets d’anomalies arrive chez votre prestataire, les « bloquants » seront évidemment traités en priorité.
Notez qu’à première vue, on pourrait penser que les bugs doivent être traités par ordre de gravité (bloquant > majeur > mineur ) mais, selon le contexte, il arrive qu’un bug mineur puisse passer avant un bug majeur.
Par exemple, si dans un texte, il y a une faute de frappe, objectivement, c’est un bug mineur.
Cependant, si vous donnez une présentation de l’appli le lendemain devant des clients, ce bug mineur doit être corrigé dès que possible. Sa résolution peut donc passer avant celle d’un bug majeur.
Étape 4 : Estimer la fréquence d’apparition du bug
Le nombre d’occurrences est également une donnée importante à communiquer au prestataire en charge de la maintenance de votre application mobile, dans la mesure où cette information cible la quantité d’utilisateurs impactés :
- De nombreux utilisateurs ou tous les utilisateurs sont touchés ;
- Quelques utilisateurs ont remonté le problème ;
- Il s’agit d’un phénomène isolé.
Ces estimations sont relatives et dépendent du contexte. Bien sûr, chaque business a sa propre échelle. Il est donc important que vous nous fassiez connaitre la vôtre.
Étape 5 : Transmettre le rapport de bug
Si vous avez déjà reproduit et noté les étapes de reproduction de l’anomalie, welldone !
Il s’agit maintenant de le communiquer d’une manière efficace à l’équipe en charge de la maintenance de votre application mobile.
Pour cela, utiliser un outil tel que Mantis est utile, mais pas indispensable. En effet, quel que soit l’outil utilisé (Mantis, Jira, l’email, Slack, le téléphone…), c’est essentiellement la rigueur du processus qui importe.
L’objectif est de rassembler toutes les informations de contexte et les étapes pour reproduire l’anomalie dans un unique rapport, de façon ordonnée.
Dans l’idéal, voici ce que serait une liste d’informations de contexte à rassembler ; gardez simplement à l’esprit que ces informations diffèrent selon les domaines d’activité :
- L’utilisateur : de qui s’agit-il ? Est-ce un client, un administrateur d’interface,… ?
- Le nom de l’utilisateur
- Le système d’exploitation utilisé et sa version
- La version de l’application installée
- La marque et le modèle du téléphone ou de la tablette
- Une description de ce qui s’est passé (étapes par étapes)
- Une description de ce qui aurait dû se passer
Enfin, des détails complémentaires peuvent permettre au développeur de constater et comprendre plus vite le problème. Pour cela, n’hésitez pas à insérer dans le rapport :
- Des visuels, des captures d’écran,
- Une capture vidéo,
- Un jeu de données,
- Des exemples,
- Etc.
Le traitement de l’information est primordial pour la compréhension. N’oublions pas qu’entre émettre et recevoir une information, tout un monde d’interprétation se dresse entre celui qui donne et celui qui reçoit. Un titre clair par exemple sera plus compréhensible qu’un titre suggéré :
- Formulation implicite (= suggérée) : “Bandeau KO”
- Formulation explicite (= claire) : “Le bandeau d’étape n’est plus visible”
Étape 6 : Distinguer anomalie et évolution
Dernier point et qui n’est pas le moins important.
Veillez à bien différencier le rapport d’anomalies de la demande d’évolutions. Peut-être avez-vous déjà entendu un développeur dire : « Ce n’est pas un bug (anomalie), c’est une feature (évolution)» ? C’est une petite blague utilisée à l’origine pour se moquer des éditeurs de logiciels réticents à reconnaitre des erreurs dans leur produit.
Mais dans l’exemple qui suit, c’est plutôt le contraire : vous remontez un bug qui n’en est pas un.
Voici l’exemple d’un « bug » que nous remonte un client : « Il y a un bug sur notre appli : quand on clique sur le bouton “xxx”, une pop-up apparaît et seule une toute petite partie de l’écran de cette pop-up est scrollable, ce qui nuit à la lisibilité. »
En effet, c’est un problème, mais il ne s’agit pas d’un bug ; car cette partie scrollable a été définie comme telle dans le cahier des charges. Il s’agit donc d’une demande d’évolution de l’appli pour faciliter l’expérience utilisateur.
Cela signifie que la demande que vous adressez au développeur ne concerne pas un dysfonctionnement de l’app, mais plutôt un changement de périmètre de l’app.
On parle alors de maintenance évolutive.
En conclusion…
La maintenance d’une application mobile et la remontée d’anomalies nécessitent, vous l’aurez compris, beaucoup de précision et d’attention dans la rédaction d’un rapport de bug.
Cela requiert de prendre le temps de rédiger ce rapport car il permettra au développeur de mieux comprendre le contexte, les cas d’utilisation, l’environnement, les outils. Ainsi, il lui sera plus facile de cerner le problème.
Il s’agit d’un véritable travail d’investigation, d’une enquête minutieuse dont le succès repose en partie sur votre collecte d’informations .
Ce travail permettra de garantir la qualité de l’app et de maintenir la satisfaction de ses utilisateurs, tout au long de son cycle de vie.
Alors, ce temps : convaincu de le prendre ? 😊
Par Valérie Criton, Chef de projet, Équipe TMA
Vous souhaitez en savoir plus ?
Prenons rendez-vous pour échanger autour d’un café… et en attendant, découvrez notre configurateur en libre accès pour cadrer votre projet !