La phase d’exécution des tests :
Avant même d’avoir un bug, il faut le provoquer. Pour cela, on exécute des cas de tests sur notre logiciel, certains de ces cas sont en « échec ». C’est dans ces cas en « échecs » que l’on trouve des bugs. On appelle cette partie l’exécution des tests. Suite à ces tests en échec (ou « failed ») on arrive à une partie plus difficilement automatisable (et donc avec plus de valeur ajoutée !) qui est une partie d’analyse du cas.
A noter : lorsque le logiciel est déjà en production, de nombreux bugs sont remontés par des utilisateurs. Ils sont alors reproduits afin de pouvoir accéder aux phases suivantes. Un bug non reproduit ne peut malheureusement pas être corrigé (plus on a d’informations, plus on a de chances de reproduire un bug et donc de corriger votre problème sur un logiciel !).
La phase d’analyse du test :
Il faut alors répondre à cette question : Pourquoi est-il en échec ? Les raisons peuvent être multiples, en voici quelques exemples :
- A cause de l’application (Le cas le plus instinctif)
- A cause du test en lui-même qui peut ne plus être à jour ou avoir une faille (dans ce cas on a un « bug » non lié à l’application). A titre personnel, pour ce type de bug je mets à jour directement le cas puis le ré-exécute sans passer par les étapes suivantes.
- A cause d’un flou dans les spécifications (il faut alors remonter un « bug » sur ces spécifications et demander à avoir plus d’informations)
- A cause de l’environnement ou d’instabilités (dans ce cas il faut ré-exécuter le cas et on a donc perdu du temps d’exécution puis d’analyse, c’est pourquoi une bonne stabilité des environnements et des cas de tests est très important)
- Le matériel utilisé (est-ce que ce bug ne se produit que sur certains smartphones ? certains OS (ou version d’OS)…)
Après avoir trouvé ces bugs il faut alors les classifier (une faute d’orthographe dans les CGU* est moins problématique qu’un crash applicatif lors de l’envoi d’un mail). On se retrouve alors à une nouvelle phase de gestion, phase non automatisable (à ma connaissance) et donc à forte valeur ajoutée, la phase de catégorisation du bug.
La phase de catégorisation du bug :
Comme déjà vu dans mon post sur le logiciel sans bug, ne pas avoir de bugs dans une application est quasiment impossible et surtout contre-productif. Néanmoins certains « bugs » sont inacceptables d’un point de vue utilisateur.
A chaque fois que j’envoie un mail mon application mail Android crash et en plus ce dernier n’est pas toujours envoyé est un bug très problématique pour une application mail, surtout s’il se produit sur un grand nombre de téléphones.
Il faut donc catégoriser ces « bugs ». Pour cela on va utiliser les informations collectées lors de la phase d’analyse.
En général on classe les « bugs » en 3 catégories de criticité qui sont :
- Mineur : Bug non gênant
- Majeur : Bug gênant mais non bloquant
- Critique : Bug empêchant un usage correct de l’application Comment catégoriser ces « bugs » en fonction des données collectées ?
En général on utilise un tableau d’impact et de probabilité d’occurrence de ce bug (même si ce tableau n’est pas écrit sur papier). Le principe est simple, un bug très impactant peut être acceptable s’il ne produit quasiment jamais, par contre un bug moins impactant qui se produit tout le temps (devoir lancer 2 fois son application par exemple) est plus gênant d’un point de vue utilisateur.
Voici un exemple de tableau (ce tableau peut être différent en fonction des projets) :
Prenons 2 exemples, toujours sur notre application mail :
Premier exemple : Mon application mail doit toujours être démarrée 2 fois car elle ne se lance pas vraiment au premier lancement. On a alors un « bug » à très forte probabilité avec un impact faible. On a donc un bug Majeur (voir critique si on considère l’impact comme Moyen)
Second exemple : Une faute d’orthographe dans les CGU : Probabilité très forte, impact très faible (peu de personnes les lise et cela n’impacte pas l’utilisation de l’application), on a donc un bug « mineur »
Suite à ces phases, le bug est en attente de correction et le testeur n’intervient qu’au moment où il doit le retester après correction.
La Phase de correction :
Cette phase n’est généralement pas une phase sur laquelle le testeur travaille, par contre elle dépend beaucoup du travail effectué avant. Les bugs critiques sont généralement traités en priorité, puis les bugs majeurs et enfin les bugs mineurs.
Une application peut sortir avec des bugs mineurs connus. Certaines applications sortent avec quelques bugs Majeurs, par contre sortir une application avec des bugs critiques connus est, de mon point de vue, impossible (ou alors le bug n’est pas vraiment critique).
La phase de correction ne nécessite pas forcément de développement. Si le bug est dû à un flou dans les spécifications, alors la correction est une modification des spécifications.
La phase de retest :
Lorsque le bug est corrigé il est envoyé en phase de retest. Le rôle du testeur est alors de valider que le bug précédemment remonté est corrigé et de s’assurer que cette correction n’a pas engendré de bugs plus impactant (on utilise alors des tests de régression).
La phase de clôture du bug :
Lorsque le test est corrigé et validé on le clos. C’est la fin de vie de ce bug, il ne servira alors à faire des statistiques, des bilans ou tout autre objet de communication.
CGU : Conditions Générales d’Utilisation
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
