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.