Rassemblez les rapports
Les rapports servent de base pour la priorisation des défauts à venir. Après la compilation des rapports d'incidents et d'évolution, les parties prenantes examinent les défauts signalés et les suggestions d'amélioration.
Ces documents fournissent des informations détaillées sur les problèmes rencontrés, leur gravité et leur impact potentiel sur l'utilisateur final. Ces éléments sont essentiels pour évaluer les priorités et déterminer quelles actions doivent être prises en premier pour garantir la meilleure expérience possible pour les utilisateurs.
Une fois les rapports rassemblés, une analyse plus approfondie peut être effectuée pour identifier les tendances, les schémas récurrents et les domaines spécifiques nécessitant une attention particulière. Cette analyse contribue à établir une compréhension holistique des forces et des faiblesses du produit, ainsi que des opportunités d'optimisation.
Lorsque vous rassemblez les rapports, il est important de faire un état des lieux quant au nombre de défauts ouverts ou qui ont été ouverts tout au long de la campagne de test. Cela fournit une mesure claire de l'étendue des problèmes identifiés et donne une idée de l'ampleur des efforts nécessaires pour atteindre les objectifs de qualité. Cette évaluation quantitative est précieuse pour évaluer l'impact global de la campagne de test et guider les étapes ultérieures, qu'il s'agisse de corriger les défauts, de planifier des améliorations futures ou de prioriser les développements en cours.
En résumé, les rapports d'incidents et d'évolution ne sont pas simplement des documents techniques, mais des outils de communication puissants pour partager des informations clés avec les parties prenantes. Le rassemblement de ces rapports permet de mettre en évidence les problèmes critiques et les opportunités d'amélioration, fournissant ainsi des données essentielles pour la prise de décision éclairée et l'amélioration continue du produit ou du système testé.
Priorisez les défauts trouvés
Comme nous l’avons vu précédemment dans la section Analysez les erreurs, la priorisation des défauts trouvés constitue une étape cruciale dans la gestion efficace d'une campagne de test qualité. Elle doit être une démarche collaborative impliquant les parties prenantes clés, y compris les équipes de développement, de test et de gestion de projet.
Lorsqu'une campagne de test génère une multitude de défauts, il devient essentiel de hiérarchiser ces problèmes afin de focaliser les ressources et les efforts sur ceux qui ont le plus grand impact sur la qualité et la fonctionnalité du produit. Une approche basée sur des critères objectifs et une évaluation minutieuse permet de s'assurer que les ressources sont allouées de manière optimale pour résoudre les problèmes qui ont le plus grand impact sur la qualité et la performance du produit. Une telle approche permet aussi de maximiser l'efficacité des équipes de développement et de garantir que les corrections les plus importantes sont traitées en premier, contribuant ainsi à la réussite globale du projet.
Dans l’exemple ci-dessous, le champ Priority vous permet de donner une estimation de priorité au problème identifié. Dans la description du problème, vous pouvez expliquer pourquoi vous avez choisi le degré de priorité en question.
Le chiffrage des degrés d'importance des bugs se fait généralement à l'aide d'une échelle ou d'un système de notation. Voici un exemple courant d'échelle de priorité utilisée pour classer les bugs :
Bloquant (Criticité critique) : ce niveau est réservé aux problèmes qui empêchent complètement le fonctionnement du produit ou système, ou d’une fonctionnalité du produit. Ils sont de la plus haute priorité car ils rendent le produit inutilisable ou entraînent des conséquences graves.
Majeur (Haute criticité) : les bugs de cette catégorie ont un impact significatif sur la fonctionnalité ou la performance du produit, mais ne l'empêchent pas de fonctionner complètement. Ils peuvent affecter des tâches essentielles ou des utilisateurs spécifiques.
Mineur (Criticité moyenne) : les problèmes mineurs ont un impact léger sur le produit et ne causent pas de perturbations majeures. Ils peuvent inclure des erreurs cosmétiques ou des fonctionnalités non critiques.
Trivial (Basse criticité) : les problèmes triviaux ont le moins d'impact sur le produit et sont généralement des problèmes esthétiques qui n'affectent pas significativement la fonctionnalité ou l'expérience utilisateur.
En attribuant un degré d'importance à chaque bug en fonction de cette échelle, les équipes peuvent rapidement évaluer la gravité de chaque problème. Cela permet de déterminer l'ordre dans lequel les bugs seront résolus et de s'assurer que les ressources sont consacrées en priorité aux problèmes les plus critiques.
Vérifiez une correction apportée
Après avoir réalisé une campagne de test et identifié des anomalies à travers des rapports d'incidents, la collaboration entre les équipes de développement et de test continue dans la phase cruciale de vérification des corrections.
Une fois que les développeurs ont apporté des modifications en réponse aux problèmes signalés, il incombe aux équipes de test, c’est-à-dire vous, de s'assurer que les corrections ont été efficacement implémentées et que le produit est revenu à un état de fonctionnement optimal.
La première étape de cette vérification consiste à consulter les retours reçus concernant les corrections apportées. Ces retours fournissent des informations essentielles sur les changements qui ont été effectués et les délais prévus pour les implémenter. Ceci permet de planifier efficacement les activités de vérification et de s'aligner sur les attentes de toutes les parties prenantes.
Une fois les modifications apportées, les tests initiaux doivent être exécutés à nouveau. Il est crucial de vérifier que le défaut signalé a été corrigé conformément aux spécifications et que les fonctionnalités touchées par la correction fonctionnent correctement. Cependant, la vérification ne se limite pas à la simple résolution du problème initial. Il faut également s'assurer qu'aucune régression n'a été introduite suite à cette correction. Les tests doivent donc être étendus pour englober les zones potentiellement affectées par la modification. Vous devez donc exécuter à nouveau tous les tests que vous avez automatisés afin de vérifier qu’il n’y a pas d’autre problème. Si vous n’avez pas assez automatisé, vous devez réaliser à la main les tests les plus critiques.
Lorsqu'une correction est validée et qu'aucune régression n'est détectée, l'incident peut être considéré comme résolu. Le rapport de bug associé peut alors être clôturé, signalant ainsi la résolution réussie du problème. Cependant, si la correction ne résout pas le défaut signalé ou si de nouvelles régressions sont identifiées, il est crucial de fournir un retour détaillé à l'équipe de développement. Ce retour doit inclure des informations précises sur les problèmes persistants ou les nouvelles anomalies, ainsi que les conditions sous lesquelles elles ont été observées.
Cette boucle de vérification, de retour et de collaboration continue jusqu'à ce que toutes les corrections aient été correctement implémentées et validées. La communication transparente entre les équipes de développement et de test est essentielle à chaque étape du processus, garantissant que les problèmes sont résolus de manière satisfaisante et que le produit atteint les normes de qualité requises. La vérification d'une correction apportée à partir d'un rapport d'incident représente donc une étape clé dans l'amélioration de la qualité et de la performance du produit, en mettant l'accent sur la collaboration et l'excellence.
À vous de jouer !
Vous voici dans le dernier "À vous de jouer". On ne pouvait pas vous laisser partir sans avoir rédigé votre propre bilan de campagne !
Vous devez donc rédiger le bilan de campagne de la fonctionnalité du formulaire du projet Tech&Buy, à l'aide de ce template.
Aidez-vous de tout ce que vous avez réalisé dans le cours : les tests, les anomalies trouvées, et donnez votre avis sur cette campagne.
N’hésitez pas à reprendre les sections “À vous de jouer” pour retrouver tous les tests réalisés.
N’oubliez pas de donner votre avis sur la maturité du projet. Avez-vous confiance dans cette version ? Est-ce que les tests réalisés sont suffisants ? Qu’auriez-vous ajouté ?
Consultez la suggestion de corrigé.
En résumé
L'analyse de l'impact et de la criticité des erreurs est cruciale pour évaluer l'effet potentiel d'un échec de test sur l'application, les utilisateurs et l'entreprise.
Cette évaluation aide à prioriser les problèmes en fonction de leur gravité, de leur fréquence, de l'impact sur les utilisateurs, de la sécurité, de l'image de l'entreprise, etc. Elle guide les actions correctives et maintient la qualité et la stabilité du produit final.
Les rapports d'incidents et d'évolution jouent un rôle essentiel en tant que moyens de communication pour partager des informations critiques sur la qualité et la performance du produit testé.
Vérifiez toutes les corrections qui ont été apportées mais n’oubliez pas de réaliser les tests de non-régression avant de clôturer un rapport d’incident.
Félicitations, vous avez fini le cours ! Avant de nous quitter, je vous ai préparé un dernier petit quiz pour tester vos connaissances sur cette troisième et dernière partie.
