Pourquoi le conseil en assurance qualité a besoin d’une vue d’ingénierie holistique ?

“How did QA miss this?”

Traditionally, this question arises from every quarter when there’s an issue with post-release product quality.

However, an inefficient QA process is not often the sole reason.

In fact, the problem can be more complex than that and may have started before the product was even released.

Let’s see an example:

Let’s point our fingers at QA!

Does it apply in this scenario?

No!

A successful release requires coordination between different teams, including design, development, QA, and others. When these teams aren’t aligned on what they’re trying to accomplish, it can lead to pesky defects in your product development cycle—which means defective software and unhappy users!

Here’s a recent consulting disaster: Accenture sued for $32 million over Hertz website redesign

And that’s why today, through this blog we want to share: why quality needs to be viewed from a holistic engineering lens, a lesson we learnt from our experience of working with clients across the globe and of varying sizes.

Why is there a drop in product quality?

Why are our users reporting critical defects?

Why is our QA not able to spot defects earlier?

…These are the questions we often get to hear from our clients.

While these “Why’s” help to uncover what went wrong with respect to product quality, we think that it only presents the tip of the iceberg picture and there needs to be a deep dive into the engineering processes to uncover much more important components that are directly or indirectly related to software quality.

Now, why do we think this hasn’t been made as a standard approach to looking at product quality? While there can be many reasons, it all boils down to one core issue – tech leaders take a siloed approach to quality and are not looking into the problem/quality from a holistic engineering point of view.

At Zuci, we understand quality is an ongoing process. And that’s why we have built our QA consulting approach with CARE (Check, Act, Refine, Evolve) to identify issues at the root and help fix them.

Our President, Vasudevan Swaminathan briefs “Holistic approach to quality” in this 2-min video. Check it out

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

En règle générale, les équipes de consultants suivent des processus locaux ou des processus légers. Beaucoup d’entre eux 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. Cela nécessite principalement que les consultants aient :

• Discussions avec la direction des produits
• Discussions avec les équipes d’ingénierie
• Discussions avec l’équipe des services professionnels
• Discussions avec les équipes en contact avec les clients
• Collaboration entre la gestion des produits, l’ingénierie, les solutions et les services. Équipes d’assistance à la production
• Pratiques d’assistance à la production

La manière de Zuci d’envisager 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 maturité du contrôle qualité et a tracé la voie pour y parvenir et bien plus encore. Obtenez tout cela 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.