Menu

Qu'est-ce que la dette technique et pourquoi les testeurs d'assurance qualité devraient-ils s'en préoccuper?

  • Principal
  • Test Agile
  • Qu'est-ce que la dette technique et pourquoi les testeurs d'assurance qualité devraient-ils s'en préoccuper?

what is technical debt

Essayez Notre Instrument Pour Éliminer Les Problèmes

Dette technique est une idée métaphorique qui soutient que tout comme on peut rencontrer des problèmes d'endettement en finance, les organisations de logiciels rencontrent quelque chose de similaire dans l'accumulation de travail inachevé au cours des projets précédents et des versions / sprints de versions.

Qu'est-ce que la dette technique?

Il représente l'effort nécessaire pour résoudre les problèmes / défauts qui restent dans le code lorsqu'une application est publiée. En termes simples, c'est la différence (en termes de bugs) entre ce qui est attendu et ce qui est livré.

Lorsqu'une équipe de développement est occupée à travailler sur un projet et à corriger des bogues malheureusement, de nombreux nouveaux bogues apparaissent. Hors de ceux-ci, certains sont fixes et certains sont différés pour une version ultérieure. Lorsque ces différences de problèmes augmentent, à un moment donné, il devient vraiment difficile de publier le produit à temps sans aucun problème. C'est la pire conséquence de Dette technique s’il n’est pas abordé à temps.

Dans cet article, vous apprendrez ce qu'est la dette technique, pourquoi l'équipe QA devrait s'en préoccuper et surtout comment la gérer.

qu

image la source

Ward Cunningham , le fondateur du logiciel wiki, conçu de cette idée dans les années 1990, établissant des parallèles avec l'impact des créances irrécouvrables sur le secteur financier, faisant littéralement allusion à l'expérience désagréable d'avoir à payer des intérêts excessifs après un défaut de paiement.

quel est le système d'exploitation le plus récent

Le défi de l'augmentation de la dette technologique par sprint peut être visualisé dans la figure 1.

Il faut cependant mentionner ici qu'il existe une légère différence dans la signification de la dette technique (également connue sous le nom de dette de code ou dette de conception) par rapport à son analogie correspondante dans le monde de la finance - la première ressemble plus à une idée abstraite , sans équations mathématiques pour visualiser comment l'intérêt s'accumule réellement.

dette technique croissante

Fig. 1: Visualisation de l'augmentation évolutive de la dette technologique à travers les sprints

Ce que vous apprendrez:

Pourquoi les équipes QA souffrent le plus de la dette technique

Au cours d'un cycle typique de conception et de développement de logiciels, plusieurs éléments peuvent conduire à un ' dette technique ”Comme situation– documentation incorrecte , tests inadéquats et correction de bugs, manque de coordination entre équipes, héritage code et refactoring retardé , absence de Intégration continue et d'autres facteurs incontrôlables.

Par exemple, il a été observé que les efforts de duplication de code peuvent conduire à n'importe quoi entre 25 à 35% travail supplémentaire.

exécuter les fichiers .jar windows 10

Cependant, nulle part les les défis dus à la dette technique sont plus évidents que dans les tests d'assurance qualité où les équipes de test doivent respecter des délais inattendus et que tout peut être perdu.

Combien de fois vos testeurs ont-ils été confrontés à des dilemmes au dernier moment lorsque, de manière inattendue, le responsable de la livraison est venu leur dire: «Équipe! Nous devons déployer notre produit dans une semaine, désolé de ne pas pouvoir communiquer cela à temps. Veuillez terminer de toute urgence toutes les tâches de test afin que nous puissions être prêts avec la démo. '

Fondamentalement, tout test raté ou approche «résolvez-le plus tard» peut conduire à un problème de type dette technologique. Manque de couverture de test , des user stories surdimensionnées, des sprints courts et d'autres exemples de «raccourcis» dus à la pression de livraison jouent un rôle majeur dans l'accumulation de la dette technique dans la pratique de l'assurance qualité.

Un exemple du monde réel

Un détaillant en ligne basé aux États-Unis avec une présence significative sur plusieurs sites Web et applications mobiles s'est retrouvé dans un véritable défi de «dette technique» lorsque la complexité du maillage de test a commencé à s'accroître à chaque nouvelle sprint .

Cela s'est produit en raison de l'augmentation soudaine du nombre d'appareils mobiles à tester, de plusieurs langues à prendre en charge et de plus d'une demi-douzaine de sites de réseaux sociaux à exploiter.

Avec une couverture d'automatisation inférieure à 40%, le défi de la dette technologique se présenterait de la manière suivante:

  • Consommation de temps excessive lors des tests de mise en production - Le nombre de navigateurs, d'appareils et de scripts augmentant à chaque sprint de test, le cycle de publication continuerait à être retardé, entraînant une perte de temps de mise sur le marché.
  • Le coût croissant de l'embauche - Le nombre de testeurs nécessaires pour soutenir le projet a presque doublé, ce qui s'est traduit par des coûts supplémentaires de 500 000 $
  • Complexité du projet - Avec la complexité croissante du projet, le suivi des cas de test et des bogues devenait un défi
  • Trop de temps perdu à chasser les faux positifs - Encore une fois, une conséquence de la complexité croissante des projets.
  • Augmentation de l'effort de développement de tests jusqu'à 60% - Ça va avec le territoire

Gestion de la dette technologique dans les pratiques d'assurance qualité

La plupart des responsables de l'assurance qualité considèrent impulsivement la dette technologique comme la conséquence raisonnable de la concentration de toute votre énergie sur le seul sprint actuel, ce qui conduit à atteindre la couverture de test d'une manière ou d'une autre par des moyens manuels, et ignore complètement l'automatisation.

Ceci est connu comme le approche rapide et sale qui a été couvert dans un blog par Martin Fowler, l'auteur du quadrant de la dette technique .

Les principes agiles nous dictent de visualiser le problème de la dette technologique comme une incapacité à respecter et à respecter Benchmarks d'AQ .

En réalité, basé sur une enquête par le National Institute of Standards and Technology (NIST), l'insuffisance des outils et méthodes de test coûte chaque année à l'économie américaine entre 22,2 $ et 59,5 milliards de dollars , avec environ la moitié de cet argent dépensé en tests supplémentaires par les développeurs de logiciels et environ la moitié par les utilisateurs de logiciels pour éviter les échecs.

Au lieu de réagir aux pannes au fur et à mesure de l'incident, une approche proactive consisterait à identifier les défauts après chaque activité ou tâche qui peut être mesurée. Vous pouvez tout faire manuellement, mais étant donné les milliers de scénarios de cas de test pour un projet moyen, le contrôle des tests automatisés est une nécessité.

Clairement, tests efficaces peut vous aider à gagner du terrain dans la guerre contre la dette technique. Alors, qu'est-ce que cela signifie fondamentalement? Cela signifie à quel point votre système est bien équipé pour identifier les défauts dans l'application globale.

l

Comme le montre l'équation ci-dessus, l'efficacité du cas de test peut théoriquement approcher même 100% si le nombre de défauts constatés par le client (c'est-à-dire les défauts de post-production) avait été mappé précisément au nombre de défauts détectés à chaque étape de la couverture des tests.

Afin de disposer d'un banc d'essai bien conçu capable de mesurer avec précision les défauts dès leur apparition, l'automatisation est une condition préalable.

Automatisation des tests vous aide à minimiser le nombre de scripts exécutés en rapportant les résultats et en les comparant aux exécutions de test précédentes. La méthode ou le processus utilisé pour exécuter l'automatisation est appelé un test automatisation cadre .

Des exemples typiques seraient des outils disponibles dans le commerce ou gratuits tels que Selenium, MonkeyTalk, les robots , Borland SilkCentral, HP Quality Center et IBM Rational Rose .

Dans le passé, l'assurance qualité / tests était souvent considérée par les organisations et leurs équipes logicielles comme une activité de soutien à des livrables commerciaux plus importants, et non comme une pratique disciplinée à part entière qui nécessiterait une concentration de base et dédiée. En fait, une approche non fondamentale de l'AQ / des tests est précisément ce qui a conduit au défi permanent de la dette technique en premier lieu.

Compte tenu du rythme rapide d'évolution des compétences en AQ / tests qui s'est produit au cours de la dernière décennie, les organisations ont vraiment du mal à mettre à niveau leurs compétences et leurs compétences aux niveaux minimums souhaités selon les références actuelles de l'industrie.

En fait, il y a une tendance croissante de l'industrie à se contenter de rien de moins que les professionnels les plus chevronnés de l'automatisation des tests - un peu comme les commandos d'élite des tests / QA; ils sont connus comme ingénieurs logiciels en test ( Puisque ) et développeurs de logiciels en test ( SDiT ). Ces professionnels sont très demandés en raison de leur vaste expérience dans une verticale choisie (par exemple le commerce électronique) ou une catégorie professionnelle particulière.

La plupart des entreprises de développement de logiciels et de produits, à l'heure actuelle, ont du mal à trouver les ressources techniques qualifiées souhaitées face à des délais de livraison plus courts. La solution à ce défi consiste à établir un partenariat avec un acteur d'automatisation de l'assurance qualité offshore capable de remédier à votre pénurie de compétences avec le bon pool de ressources SDiT / SEiT.

Parmi les autres attributs souhaités d'un acteur de l'externalisation dans le domaine de l'assurance qualité / des tests, qui se révèlent utiles, citons une approche agile et disciplinée de l'exécution de projet, une expérience suffisante du secteur, y compris un accès pratique à des cadres d'automatisation et des cas de test réutilisables, et enfin et non des moindres, une intention claire. et la capacité de relever les défis des équipes éloignées et les conflits culturels afin que le client ne soit pas surchargé de travail supplémentaire dans la gestion des entrepreneurs.

Conclusion

Comme toute autre dette, la dette technique peut s'avérer être le fléau des entreprises et la cause première de son accumulation est l'incapacité de mettre en œuvre une pratique proactive d'AQ qui supprime tous les arriérés de l'automatisation.

À propos de l'auteur: Ceci est un message d'invité par l'équipe eInfochips. Ils ont mis au point une approche unique appelée Dette technologique zéro qui est l'un des moyens les plus structurés et les plus efficaces d'éliminer progressivement la dette technique dans les activités d'AQ / d'automatisation. Pour en savoir plus sur la dette technologique, regarde cette video sur une approche visant à réduire le département technique.

c ++ attendre quelques secondes

J'espère que vous avez une idée claire de ce qu'est la dette technique. Faites-nous savoir si vous avez des questions à ce sujet ou comment le gérer dans la pratique.

lecture recommandée

^