“Comment QA a-t-il manqué ça ?”

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

Cependant, un processus d’assurance qualité inefficace n’est souvent pas 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 QA !

Cela s’applique-t-il dans ce scénario ?

Non!

Une version réussie nécessite une coordination entre différentes équipes, y compris la conception, le développement, l’assurance qualité et autres. Lorsque ces équipes ne sont pas alignées sur ce qu’elles essaient d’accomplir, cela peut entraîner des défauts embêtants dans votre cycle de développement de produits, ce qui signifie des logiciels défectueux et des utilisateurs mécontents !

Voici un récent désastre de conseil: Accenture poursuivi pour 32 millions de dollars pour la refonte du site Web de Hertz

Et c’est pourquoi aujourd’hui, à travers ce blog, nous voulons partager : pourquoi la qualité doit être vue d’un point de vue d’ingénierie holistique, une leçon que nous avons apprise de notre expérience de travail avec des clients du monde entier et de différentes tailles.

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

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

Pourquoi notre QA n’est-il pas en mesure de détecter les défauts plus tôt ?

…Ce sont les questions que nous posent souvent 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’ils ne présentent que la pointe de l’image de l’iceberg et qu’il faut plonger profondément 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.

Maintenant, pourquoi pensons-nous que cela n’a pas été fait comme une approche standard pour examiner la qualité des produits ? Bien qu’il puisse y avoir de nombreuses raisons, tout se résume à un problème central : les leaders technologiques adoptent une approche cloisonnée de la qualité et n’examinent pas le problème/la qualité d’un point de vue technique holistique.

Chez Zuci, nous comprenons que la qualité est un processus continu. Et c’est pourquoi nous avons construit notre approche de conseil QA avec CARE (Check, Act, Refine, Evolve) pour identifier les problèmes à la racine et aider à les résoudre.

Notre président, Vasudevan Swaminathan, explique “Approche holistique de la qualité” dans cette vidéo de 2 minutes. Vérifiez-le

Conseil AQ idéal

“La qualité est la responsabilité de chacun.”

Une bonne qualité logicielle ne concerne pas uniquement les 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 logicielle, les compétences individuelles, les compétences d’équipe et d’autres domaines connexes. – Zingénieurs

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, personnes, processus et culture.

Voici l’approche que Zuci adopte pour comprendre les cinq aspects clés.

Alors que,

1. Pratiques d’ingénierie

1. Produit principal

1. Versions client

1. Ingénierie des tests et assurance qualité

Technologie

L’objectif principal ici est 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.
• Technologie qui prend en charge la qualité du processus logiciel.
• Niveau de technologie utilisé dans le développement de produits de génie logiciel.
• Maturité des processus de génie logiciel.

Les consultants doivent effectuer ces exercices dans les premières étapes de la consultation et obtenir autant de détails que possible et documenter ces observations qui pourraient aider dans les prochaines étapes 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 en examinant différentes parties dela suite d’applications du client dans les outils de gestion de projet ; non seulement du point de vue de l’assurance qualité, mais également du point de vue des processus d’ingénierie logicielle, en prenant une vue d’ensemble de leur architecture, code, infrastructure, dette technique et autres domaines pertinents.

L’examen du produit principal doit inclure :

• Défauts du produit et analyse des modèles
• Examen de la planification et de la livraison du sprint
• Examen des tests manuels et automatisés
• Intégrations API – Outils, approche de test
• Matériel, logiciel et intégrations externes
• Pratiques de gestion des changements de produits
• Intégration de la gestion des produits et de l’assistance à la production

Lorsque vous plongez profondément dans le produit, vous ne pouvez pas manquer la « dette technique » qui lui est associée.

La dette technique est une expression inventée à l’origine par le développeur de logiciels, Ward Cunningham, qui la décrit comme suit :

“Avec de l’argent emprunté, vous pouvez faire quelque chose plus tôt que vous ne le feriez autrement, mais jusqu’à ce que vous remboursiez cet argent, vous paierez des intérêts. Je pensais qu’emprunter de l’argent était une bonne idée, je pensais que précipiter le logiciel pour acquérir de l’expérience était une bonne idée, mais bien sûr, vous finiriez par revenir en arrière et au fur et à mesure que vous appreniez des choses sur ce logiciel, vous rembourseriez cela prêt en refactorisant le programme pour refléter votre expérience au fur et à mesure que vous l’avez acquise.

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 de produits possèdent non seulement des compétences approfondies en ingénierie, mais également un « état d’esprit d’ingénierie de la qualité des produits ». Une pratique de conseil en assurance qualité (AQ) efficace 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 d’équipe, l’expérimentation perpétuelle, l’exploration, la pose de questions précises et la recherche de réponses, l’engagement et la concentration.

Lorsqu’on parle de personnes et de collaboration, on ne peut souligner l’importance de responsabiliser les gens 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 sur la même longueur d’onde afin qu’ils comprennent comment chaque partie de leur travail s’intègre dans l’ensemble de la création d’applications de qualité.

Intéressé par une solution qui montre une image claire de la qualité du produit pour les personnes de toute l’organisation ?

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

Processus

Généralement, les équipes de conseil suivent des processus internes ou des processus légers. Beaucoup d’entre eux suivent des méthodologies basées sur Agile ou Lean.

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

• Discussions avec la gestion des produits
• Discussions avec l’équipe d’ingénierie (s)
• Discussions avec l’équipe des services professionnels
• Discussions avec les équipes en contact avec les clients
• Collaboration entre les équipes Product Management, Engineering, Solutions & Production Support
• Pratiques de soutien à la production

La façon dont Zuci envisage le « processus » consiste à examiner trois domaines principaux qui donnent un aperçu des processus d’ingénierie globaux et de leur efficacité, notamment :

Vous n’êtes pas sûr de la maturité de votre processus d’assurance qualité ? Nous avons couvert en détail sur Maturité AQ et tracé une route pour y parvenir et plus encore. Obtenez tout ici.

Culture

La qualité du logiciel est énorme. Cela peut faire ou défaire une entreprise. Il est très agressif et bourré 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ésolvant des 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 ici est de permettre une culture de décalage à gauche qui élimine les silos et contribue à améliorer la collaboration au sein de l’équipe

Éléments clés de Maj-gauche

• Incluez les testeurs dès le début : faites en sorte que l’assurance qualité fasse partie de l’équipe SCRUM. L’assurance qualité doit passer en revue les témoignages d’utilisateurs et travailler avec les chefs de produit pour comprendre et obtenir des éclaircissements. L’AQ définit ensuite les critères d’acceptation avec les chefs de produit et les analystes. Le QA décidera des tests manuels qui doivent être effectués avant le début du Sprint.
• Amener les développeurs dans les activités de test : apportez plus d’analyses de code d’unité, d’intégration et statique pour 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 navigables.
• Initier les testeurs au codage : QA travaillera avec les développeurs pour automatiser les tests d’acceptation en fonction des critères d’acceptation.
• Gardez à l’esprit la testabilité lors du codage : un test de décalage vers la gauche réussi nécessite également un effort d’équipe. Lors de l’écriture de code, les développeurs doivent se demander : “Comment puis-je le rendre plus testable ?” Cela peut signifier exposer un crochet ou créer un identifiant unique pour un élément
• Trouvez une opportunité d’automatiser tout processus reproductible : l’automatisation doit couvrir les tests unitaires/d’intégration/d’acceptation couvrant les fonctionnalités, les intégrations, les configurations, les déploiements, les performances, la capacité et les tests de sécurité des applications.
• Complétez les tests automatisés avec des tests exploratoires et des tests d’utilisabilité.

Chez Zuci, nous apprécions pleinement chaque exercice de conseil en assurance qualité et espérons que vous apprécierez également la lecture à ce sujet.

Dernières pensées

Il est important d’avoir une vision globale de l’ingénierie du produit. Parfois, la “vue d’ensemble” nous indique ce qui ne va pas avec une partie du produit ; d’autres fois; cela nous aide simplement à identifier les opportunités potentielles d’amélioration dans plusieurs domaines.

Pour déterminer les domaines d’amélioration, vous pouvez simplement commencer par un tableau de bord de la qualité du produit ou même répondre à un quiz de maturité QA qui fera avancer l’aiguille dans votre processus de cycle de vie du produit.

Alors, qu’est-ce qui distingue un produit? La réponse est simple mais pas facile : la qualité.

La qualité repose sur les compétences d’écriture de code de base des développeurs. Les bons produits n’auront pas un tas de dettes techniques accumulées en eux. Ils disposent d’une documentation claire pour chacune des équipes et facilitent la collaboration. Ils prennent en compte les expériences des utilisateurs finaux. Et cela ne laisse pas la qualité au hasard.

Vous voulez une copie gratuite du rapport de conseil que nous avons réalisé pour un géant du e-commerce F500 ?

Écrivez-nous à sales@zucisystems.com et nous vous répondrons dans la journée.