Les 5 principales clés d’une assurance qualité (QA) vraiment efficace 

Plusieurs approches possibles permettent d’intégrer la qualité au cœur de l’application, afin de limiter les risques, la reprise du code, d’améliorer la compréhension au sein de des équipes, ou encore de déployer des projets avec plus d’assurance et de sérénité. Christopher James, QA Analyst chez SQLI partage son expertise sur le sujet.

#1 La qualité : Une responsabilité partagée

Communément, les équipes pensent à tort que la qualité est du ressort du service QA. Et même au sein des projets Agile, la QA est souvent traitée comme une activité à part qui a lieu après le développement !

Pourtant, la qualité est l’affaire de tous et à tout moment du projet. Pour adopter une approche quality-first efficace, il est essentiel de commencer par éliminer les silos entre le business, les développeurs et l’assurance qualité, et d’encourager la collaboration entre ces équipes.

De même, il s’avère utile d’animer des points fréquents au cours du développement afin de gérer les attentes des parties prenantes. Par exemple, si une fonctionnalité s’avère plus complexe que prévu, il est préférable d’en discuter quelques minutes en vue d’identifier les obstacles et de réagir aux éventuels changements imprévus, quitte à exclure ladite fonctionnalité de la release à venir. C’est ce que l’on appelle le shoulder check ou le 3 amigos en Agile.

#2 Définir la stratégie qualité dès le début

L’élaboration d’une stratégie qualité en amont d’un projet permet à l’équipe de delivery d’anticiper les risques, d’affiner les méthodes de test, et d’établir des critères de réussite objectifs. Il est toutefois crucial de noter que cette définition de la qualité ne se limite pas aux aspects fonctionnels, tels que la convivialité ou la compatibilité avec divers devices.

Dans le cadre de modèles DevOps, les plateformes e-commerce peuvent intégrer des métriques DORA (fréquence de déploiement, délai d’exécution des changements, délai moyen de rétablissement et taux d’échec des changements) pour garantir des performances optimales.

La qualité étant multifacettes, la compréhension et la définition des aspects qualitatifs peuvent sembler complexes. Pour éclaircir cette perspective, le RiskStorming s’avère un point de départ recommandé.

Lors de l’élaboration de la stratégie qualité, le RiskStorming facilite un consensus sur les aspects cruciaux du système. Ainsi, l’équipe peut partager une vision commune de la manière dont la « qualité » doit être perçue par elle-même et ses clients.

Compte tenu de la subjectivité de la qualité, la participation à cette session doit idéalement impliquer des représentants de différentes disciplines au sein du projet, avec au minimum des membres des services business et développement. Ainsi, il est fortement recommandé de porter autant d’attention aux aspects business que techniques. En définitive, le client demeure le meilleur juge de la qualité, justifiant ainsi son implication essentielle dans ce processus.

#3 Tester les attentes en termes de qualité

Une fois la définition de la qualité arrêtée, il est important d’identifier les éventuels risques ou obstacles qui peuvent empêcher les clients de percevoir cette qualité. Ensuite, de réfléchir aux tests à employer pour lutter contre ces problèmes.

Dans le cas d’une plateforme e-commerce, la rapidité s’impose probablement comme une métrique importante. En effet, il est essentiel que les mises à jour de prix ou de stocks soient faites quotidiennement pour offrir une expérience utilisateur en phase avec la réalité. Pour y parvenir, il faut tester le processus qui gère la mise à jour des données, en vue d’identifier les éventuels goulots d’étranglement et risques en termes d’informations invalides ou incorrectes.

De même, si la plateforme est principalement utilisée sur des appareils mobiles, les utilisateurs finaux risquent de rencontrer des problèmes de performance selon la qualité du réseau.  Ici, les équipes delivery doivent s’appuyer sur des données d’utilisation en temps réel pour identifier les limites des appareils des utilisateurs, puis tester le système avec une connexion réseau bridée pour essayer de reproduire au mieux l’UX, par exemple.

Que ce soient des chartes de tests exploratoires ou des modèles de tests classiques, documenter son approche d’analyse en équipe est fondamental. C’est à la fois un bon exercice de collaboration, et une activité qui renforce la compréhension commune d’une fonctionnalité donnée. De plus, cela permet de se mettre d’accord sur le champ d’application des tests et de déterminer plus facilement le moment où la fonctionnalité est prête pour le déploiement.

#4 Évaluer la qualité en continu

À tout moment au cours du développement d’une fonctionnalité système, il faut pouvoir se demander : « Où en est la qualité ? » et toujours y répondre avec assurance. En effet, si une boucle de feedback essentielle manque, il faut éviter les problèmes qui peuvent survenir en aval, lorsqu’il est trop tard pour agir.

Pour disposer de feedback rapide, il est essentiel de mettre en place des processus qui permettent à l’équipe delivery de réaliser des tests à n’importe quelle étape du développement. L’équipe delivery doit être impliquée très tôt dans le processus, dès les réunions de lancement pour signaler des dépendances techniques potentielles et aider à déterminer la faisabilité de telle ou telle fonctionnalité avant de se lancer.

Le modèle de test holistique est un excellent exemple de la manière d’évaluer la qualité pendant le développement et après la mise en ligne

Plus tard au cours du développement, le recours à des outils permettant d’exécuter des tests pratiques avant de pousser le code dans un environnement de production peut simplifier la correction des bugs.

Ainsi, il est possible d’identifier et de corriger d’éventuels bugs front-end à l’étape de code review. Cela évite de retravailler son code en aval, puisque les bugs ont été détectés avant le déploiement. Dans le même esprit, on peut demander à un développeur back-end de transmettre une compilation d’un webservice à exécuter localement. Cela permet de commencer à tester les réponses de réussite / d’échec d’un endpoint, et de signaler les problèmes identifiés dans la foulée, quand ils sont encore faciles à corriger.

L’évaluation de la qualité au sens traditionnel du terme est probablement perçue comme laborieuse et futile. Il est conseillé plutôt ceci : définir des critères de qualité, réfléchir aux preuves nécessaires et déterminer où en est la qualité à toutes les étapes du processus.

#5 Les 3 piliers de la qualité

• Changer de mentalité, en faisant de la qualité une responsabilité partagée dans toute l’équipe
• Collaborer pour définir et comprendre les attentes en termes de qualité.
• Tester et évaluer ces attentes tout au long du cycle de développement

3 piliers, et c’est réglé ? Pas tout à fait… Il revient de positionner et d’équilibrer ces éléments complexes et nuancés pour stabiliser le tout !