Reading Time: 13 mins

Pourquoi le conseil en AQ a besoin d’une vision holistique de l’ingénierie ?

Pourquoi le conseil en AQ a besoin d’une vision holistique de l’ingénierie ?

"Comment l'assurance qualité a pu manquer ça ?"

Traditionnellement, cette question se pose chaque trimestre lorsqu'il y a un problème de qualité du produit après sa sortie.

Cependant, un processus d'AQ inefficace n'est pas souvent la seule raison.

En fait, le problème peut être plus complexe que cela et peut avoir commencé avant même la sortie du produit.

Voyons un exemple :

Pointons du doigt l'AQ !

S'applique-t-il dans ce scénario ?

Non !

Une mise en production réussie nécessite une coordination entre différentes équipes, notamment la conception, le développement, l'assurance qualité, etc. Lorsque ces équipes ne sont pas alignées sur ce qu'elles essaient d'accomplir, cela peut entraîner des défauts gênants dans le cycle de développement de votre produit - ce qui signifie un logiciel défectueux et des utilisateurs mécontents !

Voici un récent désastre en matière de conseil : Accenture est poursuivi pour 32 millions de dollars pour la refonte du site Web de Hertz.

Et c'est pourquoi aujourd'hui, par le biais de ce blog, nous voulons partager : pourquoi la qualité doit être considérée sous l'angle d'une ingénierie holistique, une leçon que nous avons tirée de notre expérience de travail avec des clients du monde entier et de tailles diverses.

Pourquoi y a-t-il une baisse de la qualité des produits ?

Pourquoi nos utilisateurs signalent-ils des défauts critiques ?

Pourquoi notre service d'assurance qualité n'est-il pas en mesure de détecter les défauts plus tôt ?

...Ce sont les questions que nous entendons souvent de la part de nos clients.

Bien que ces "pourquoi" aident à découvrir ce qui n'a pas fonctionné en ce qui concerne la qualité du produit, nous pensons qu'il ne s'agit que de la partie émergée de l'iceberg et qu'il faut plonger en profondeur dans les processus d'ingénierie pour découvrir des composants beaucoup plus importants qui sont directement ou indirectement liés à la qualité du logiciel.

Pourquoi pensez-vous que cette approche n'est pas devenue une approche standard de la qualité des produits ? Les raisons peuvent être multiples, mais elles se résument toutes à un problème fondamental : les responsables techniques adoptent une approche cloisonnée de la qualité et ne considèrent pas le problème/la qualité d'un point de vue d'ingénierie holistique.

Chez Zuci, nous comprenons que la qualité est un processus continu. C'est pourquoi nous avons conçu notre approche de conseil en AQ avec CARE (Check, Act, Refine, Evolve) pour identifier les problèmes à la racine et aider à les résoudre.

Notre président, Vasudevan Swaminathan, présente une"approche holistique de la qualité" dans cette vidéo de 2 minutes. Consultez le site

Conseil idéal en matière d'AQ

"La qualité est la responsabilité de tous". La bonne qualité des logiciels ne se limite pas aux tests, mais englobe d'autres pratiques d'ingénierie logicielle, telles que la clarté des exigences, l'estimation, la qualité du code, la documentation, la maintenance des logiciels, les compétences individuelles, les compétences des équipes et d'autres domaines connexes.

Les caractéristiques de l'exercice de conseil en AQ sont uniques. Parcourons les caractéristiques du conseil à travers les cinq aspects clés : technologie, produit, personnel, processus et culture.

Voici l'approche adoptée par Zuci pour comprendre les cinq aspects clés.

Considérant que,

  1. Pratiques d'ingénierie
  1. Produit de base
  1. Communiqués de presse des clients
  1. Ingénierie d'essai et AQ

Technologie

L'objectif principal est ici d'examiner la technologie et les capacités du client sur la base des prémisses suivantes :

  • La qualité du produit logiciel découle de la qualité du processus utilisé pour le créer.
  • Une technologie qui favorise la qualité du processus logiciel.
  • Niveau de technologie utilisé dans le développement de produits d'ingénierie logicielle.
  • Maturité des processus de génie logiciel.

Les consultants devraient effectuer ces exercices dans les premières étapes de la consultation et obtenir autant de détails que possible et documenter ces observations qui aideront dans les étapes suivantes de la consultation.

Produit

Les consultants doivent acquérir une compréhension complète du produit. Cela peut se faire par le biais d'une série de réunions, de tableaux blancs, de séances de remue-méninges et de l'examen de différentes parties de la suite d'applications du client dans des outils de gestion de projet ; pas seulement du point de vue de l'assurance qualité, mais aussi du point de vue des processus d'ingénierie logicielle, en prenant une vue d'ensemble de leur architecture, de leur code, de leur infrastructure, de leur dette technique et d'autres domaines pertinents.

L'examen des produits de base devrait inclure :

  • Défauts de produits et analyse de modèles
  • Revue de la planification et de la livraison du sprint
  • Examen des tests manuels et automatisés
  • Intégrations API - Outils, approche des tests
  • Matériel, logiciels et intégrations externes
  • Pratiques de gestion des changements de produits
  • Intégration de la gestion des produits et du soutien à la production

Lorsque vous vous plongez dans le produit, vous ne pouvez pas manquer la "dette technique" qui y est associée.

La dette technique est une expression inventée par Ward Cunningham, développeur de logiciels, qui la décrit comme suit,

"Avec de l'argent emprunté, vous pouvez faire quelque chose plus tôt que vous ne l'auriez fait autrement, mais ensuite, jusqu'à ce que vous remboursiez cet argent, vous payez des intérêts. Je pensais qu'emprunter de l'argent était une bonne idée, je pensais que se précipiter sur un logiciel pour acquérir de l'expérience avec lui était une bonne idée, mais que bien sûr, vous reviendriez éventuellement en arrière et qu'au fur et à mesure que vous apprendriez des choses sur ce logiciel, vous rembourseriez ce prêt en remaniant le programme pour refléter votre expérience au fur et à mesure de son acquisition."

Cela peut vous intéresser

Dette technique – Comment HORUS la gère-t-elle ?

Personnes

Les ingénieurs qui contribuent aux différentes phases du cycle de vie de la création d'un produit possèdent non seulement des compétences techniques approfondies, mais aussi un "état d'esprit d'ingénierie de la qualité des produits". Une pratique efficace du conseil en assurance qualité (AQ) doit être fondée sur l'état d'esprit de l'ingénierie de la qualité des produits.

Cet état d'esprit est un ensemble unique de principes, de méthodologies et de pratiques qui consiste en l'auto-apprentissage, la collaboration, le travail en équipe, l'expérimentation perpétuelle, l'exploration, le fait de poser des questions précises et de chercher des réponses, l'engagement et la concentration.

Lorsqu'on parle de personnes et de collaboration, on ne saurait trop insister sur l'importance de l'autonomisation des personnes par le biais de programmes de formation et de développement. Cela sert de base de connaissances et est crucial lorsque des équipes géographiquement dispersées travaillent ensemble.

Il est essentiel de reconnaître le rôle des consultants en AQ à cet égard afin de créer une base solide pour toute organisation. La clé est de mettre tout le monde d'accord pour qu'ils comprennent comment chaque partie de leur travail s'intègre dans l'ensemble de la création d'applications de qualité.

Vous êtes intéressé par une solution qui donne une image claire de la qualité du produit aux personnes de toute l'organisation ?

Comment HORUS profite à chaque partie prenante de l'organisation d'ingénierie ?

Traiter

En général, les équipes de consultants suivent des processus maison ou des processus légers. Beaucoup d'entre elles suivent des méthodologies Agile ou Lean.

L'objectif principal de l'évaluation des processus est d'examiner les pratiques d'ingénierie logicielle suivies par le client. Elle exige principalement que les consultants aient :

  • Discussions avec la direction des produits
  • Discussions avec l'équipe ou les équipes d'ingénierie
  • Discussions avec l'équipe des services professionnels
  • Discussions avec les équipes en contact avec la clientèle
  • Collaboration entre les équipes de gestion des produits, d'ingénierie, de solutions et de soutien à la production.
  • Pratiques de soutien à la production

La façon dont Zuci aborde le "processus" consiste à examiner trois domaines essentiels qui donnent une vue d'ensemble des processus d'ingénierie et de leur efficacité, à savoir :

Vous n'êtes pas sûr de la maturité de votre processus d'AQ ? Nous avons couvert en détail la maturité de l'AQ et avons tracé un chemin pour y parvenir et plus encore. Obtenez tout cela ici.

Culture

La qualité des logiciels est énorme. Elle peut faire ou défaire une entreprise. Il est très agressif et plein d'action.

Certaines entreprises préfèrent intégrer la qualité dans leurs produits dès le départ, tandis que d'autres se concentrent sur la correction des bogues après le lancement du produit. Certaines entreprises gagnent de l'argent en fabriquant des produits de haute qualité ; d'autres gagnent de l'argent en réparant les problèmes après l'expédition d'un produit.

Tout dépend de la "culture" de l'entreprise.

Le rôle d'un consultant est ici de favoriser une culture de changement qui élimine les silos et contribue à améliorer la collaboration entre les équipes.

Les éléments clés de Shift-left

  • Faites participer les testeurs dès le début : Intégrez l'assurance qualité à l'équipe SCRUM. Le service d'assurance qualité doit examiner les histoires d'utilisateurs et travailler avec les chefs de produit pour les comprendre et les clarifier. L'AQ définit ensuite les critères d'acceptation avec les chefs de produit et les analystes. L'AQ décidera des tests manuels qui doivent être effectués avant le début du sprint.
  • Faire participer les développeurs aux activités de test : Faites participer davantage les développeurs à l'analyse du code unitaire, d'intégration et statique de leur code avant de le pousser vers la branche principale ; le code fusionné est plus propre et moins sujet aux erreurs. Les unités de code individuelles sont plus faciles à tester car elles sont plus petites et plus faciles à naviguer.
  • Initier les testeurs au codage : L'AQ travaillera avec les développeurs pour automatiser les tests d'acceptation sur la base des critères d'acceptation.
  • Gardez la testabilité à l'esprit pendant le codage : La réussite du test Shift Left nécessite également un effort d'équipe. Lorsqu'ils écrivent du code, les développeurs doivent se demander "Comment le rendre plus testable ?". Cela peut signifier l'exposition d'un crochet ou la création d'un ID unique pour un élément.
  • Trouvez une occasion d'automatiser tout processus reproductible : L'automatisation doit couvrir les tests d'unité, d'intégration et d'acceptation portant sur les fonctionnalités des applications, les intégrations, les configurations, les déploiements, les tests de performance, de capacité et de sécurité.
  • Complétez les tests automatisés par des tests exploratoires et des tests de convivialité.

Chez Zuci, nous aimons beaucoup chaque exercice de conseil en AQ et nous espérons que vous aimerez aussi le lire.

Si cela vous intéresse d'en savoir plus sur notre travail, et d'obtenir un rapport de consultation complet, cliquez ici.

Dernières pensées

En conclusion, il est important d'avoir une vision d'ingénierie holistique du produit. Parfois, la "vue d'ensemble" nous indique ce qui ne va pas dans un domaine du produit ; d'autres fois, elle nous aide simplement à identifier les possibilités d'amélioration dans plusieurs domaines.

En fin de compte, les améliorations de la qualité seront de courte durée sans cette approche holistique, car la concurrence sans cesse croissante oblige les propriétaires de produits à reculer en matière de qualité, de caractéristiques et de fonctionnalités.

Vous souhaitez en savoir plus sur le sujet ? Envoyez vos questions à sales@zucisystems.com et nous vous répondrons dans la journée.

Keerthi Veerappan

An INFJ personality wielding brevity in speech and writing. Marketer @ Zucisystems.