Inconvénient de ne pas avoir de système formel de retour d’information sur l’analyse des défauts
An INFJ personality wielding brevity in speech and writing.
Notre équipe s’apprêtait à présenter un rapport de conseil sur les lacunes de 56 pages que notre équipe d’ingénieurs a préparé pour notre client, un détaillant mondial de commerce électronique
Un peu d’histoire :
Ce client était tombé par hasard sur notre site, avait répondu au quiz de maturité QA et nous avait laissé les coordonnées pour que nous puissions le contacter. À partir de leur réponse au quiz, nous avons obtenu une compréhension de haut niveau de leurs lacunes en matière de qualité des produits dans le système et de l’état des processus de test de leurs équipes réparties géographiquement.
Après les réunions initiales, les sessions de transfert de connaissances sur la portée des produits, les consultants de Zuci ont préconisé d’adopter une approche holistique de la qualité des produits. Par holistique, nous entendons – la qualité des produits ne se limite pas aux équipes d’assurance qualité. La qualité est une responsabilité partagée et les équipes doivent aborder la création de produits, l’écriture de lignes de code et d’autres activités dans un esprit de qualité.
Lorsqu’une telle culture de la qualité est établie, l’excellence en ingénierie devient alors une habitude et non un acte.
Ainsi, au cours des premières semaines de la consultation, une équipe de 5 membres aux profils variés a examiné les pratiques d’ingénierie, les processus d’ingénierie de test et les complications qui entravent l’efficacité de l’assurance qualité et les versions sans défaut.
Des constatations, des examens et des recommandations ont été faits dans les processus d’ingénierie logicielle, tels que :
- Processus agile d’ingénierie
- Mise en œuvre et utilisation de DevOps
- Changer les pratiques de gestion au sein de l’organisation
En jetant un rapide coup d’œil au rapport, j’ai trouvé le “absence de système formel de retour d’information sur l’analyse des défauts” dans la section d’observation intéressante. Je voulais choisir ce sujet avec notre responsable des tests, Madanika Rani, et voir ce qu’elle a à offrir sur le sujet.
Je lui ai demandé, “que fait un système de rétroaction d’analyse de défauts ?”
Madanika :Le système d’analyse des retours d’informations sur les défauts aide les équipes de test à analyser les défauts, à identifier leur cause profonde et à prendre des mesures pour minimiser ou arrêter ces défauts.
Une fuite de défauts vers la production peut se produire pour l’une des raisons suivantes :
- Minimisation de la couverture de régression
- Négliger les scénarios de cas extrêmes en raison de certaines configurations
- Parties prenantes possédant une connaissance minimale ou superficielle de l’application
- Minimiser la couverture des tests pour respecter les délais
Concernant l’implication des testeurs dans le STLC pour l’identification des défauts, ajoute-t-elle, la recherche de bogues doit être effectuée dès la phase de test unitaire, la méthodologie agile étant à la tête du développement logiciel.
Un instantané d’un système de rétroaction d’analyse des défauts :
Alors, quels sont les inconvénients de ne pas avoir de système formel de retour d’information sur l’analyse des défauts ?
- Les développeurs rencontrent plus de difficultés à maintenir la qualité du produit car ils n’ont pas de connaissances explicites sur les domaines que les défauts auront un impact. Il y a des chances qu’ils trouvent une solution temporaire au problème qui reviendra plus tard.
- Les développeurs n’auront aucune référence aux problèmes précédents qui se sont produits et à la résolution fournie pour les résoudre.
- Les développeurs ne pourront pas empêcher les autres zones de l’application d’un problème ou de son impact en l’absence de la cause première du problème Cela se produit lorsqu’un nouveau membre de l’équipe ou une personne sans connaissance approfondie du produit se joint.
- Il devient difficile de réduire la réapparition d’un problème. La répétition du problème ne se produit que lorsqu’il n’a pas été analysé correctement plus tôt et qu’il n’a pas de solution permanente au problème.
- Augmente les retouches nécessaires pour résoudre tout problème. Lorsqu’un défaut est relevé, nous n’avons pas accès à l’arrière-plan du tissu, ce qui oblige à analyser le problème dès le départ.
- La reprise nécessite plus de temps pour analyser et résoudre le défaut, et consomme également énormément de ressources.
- Une mauvaise communication est inévitable entre les équipes de développement, les équipes de test et les responsables lorsque les systèmes d’analyse des commentaires ne sont pas en place.
- La durée globale du cycle de vie des tests logiciels (STLC) est allongée car il faut beaucoup de temps pour résoudre les défauts et leur récurrence
- Les développeurs et les testeurs ont du mal à trouver les bogues le plus tôt possible dans le cycle de développement.
- Les équipes utilisent plusieurs outils pour le suivi des défauts. Sans un bon système de retour d’informations sur les défauts, la migration des plates-formes et l’intégration entre elles deviennent un énorme défi. Ainsi, cela entraîne une perte de description/solution de contournement des problèmes du point de vue du développeur/testeur/de la vue métier/des commentaires des utilisateurs.
- Il n’est pas très facile de suivre les problèmes non techniques/environnementaux sans systèmes de boucle de rétroaction appropriés.
- Les bogues ne peuvent pas être corrigés facilement sans un système qui capture des détails sur l’historique précédent des dépendances d’équipe, etc.
- En l’absence d’un bon système de retour d’informations sur les défauts, nous passerons en revue certains détails des activités qui sont stockés dans le cerveau des équipes.
- Les équipes courent le risque d’une traçabilité réduite et de ne pas être en mesure de fournir des métriques précieuses
- Le système de retour d’informations sur les défauts agit comme un référentiel permettant aux membres de l’équipe de résoudre les problèmes. Lorsqu’ils en sont privés, les développeurs
- Sans un historique approprié ou la connaissance d’un problème, le signalement devient discutable
- L’apprentissage prend du retard lorsque le développeur/testeur n’a pas la possibilité d’examiner les commentaires des défauts résolus.
- La livraison du projet dans les limites du budget est difficile car nous avons des bogues redondants et un temps de résolution élevé.
- Les plaintes des utilisateurs finaux seront élevées et CX diminuera
- Le processus manuel de collecte de données devient fastidieux en plus des tâches quotidiennes
- Les commentaires/idées de l’automatisation sont dispersés et les équipes ne seront pas en mesure de résoudre facilement les problèmes redondants et les problèmes plus prioritaires.
- Impossible de suivre un fond de défaut et si quelqu’un a travaillé dessus, à moins d’avoir le système d’analyse des retours de défaut.
- Se rapprocher de l’objectif zéro défaut ou moins de défauts est difficile
- Il est difficile de catégoriser les défauts ou de les rendre traçables à travers les révisions
- RISQUE accru lorsque le développeur/testeur gère un problème sans aucun historique de problème ni aucune connaissance à ce sujet.
- Visibilité réduite pour les autres personnes travaillant en équipe.
- Ralentit la décision des développeurs de se déconnecter car ils ne sont pas très confiants quant à la résolution du problème qu’ils ont fournie, cela s’est produit plus tôt jusqu’à ce que le client accepte la solution
- Retarde le processus de récupération des rappels de produits car les testeurs n’ont pas de vidage de l’historique des défauts.
- Manque de circulation de l’information entre les équipes
- Minimise les mesures prises pour contrôler les défauts qui affectent une fonctionnalité importante.
Un système efficace de retour d’information sur l’analyse des défauts est plus important pour les équipes présentant des défauts de production importants malgré des pratiques de test équitables.
Les développeurs/testeurs ne peuvent pas stocker autant d’informations sur les bogues dans leur esprit, et cela n’aide pas non plus d’avoir toutes ces informations dans des silos.
Donc, avoir une liste de contrôle pour l’analyse des défauts qui comprend “Étapes à reproduire incluses”, “Captures d’écran incluses”, “Version logicielle ajoutée”, “Dump de mémoire ajouté”, “Log ajouté”, “Détecté dans la version”, “Version source”, ” Release Version », etc. aide à la gestion des défauts et à la création de rapports.
Vous souhaitez lire le rapport de Gap Consulting ? Envoyez-nous un « bonjour » à sales@zucisystems.com
