Conseils pour une QA vraiment efficace

Par exemple, si leurs analyses révèlent des bugs à corriger ou des changements à implémenter, l’équipe ne sera pas forcément en mesure de respecter l’échéance de lancement en production. À l’ère du déploiement continu (CD), et en particulier dans le e-commerce, la réussite des entreprises repose sur leur capacité à livrer rapidement.

Existe-t-il une autre option ? Une autre approche qualité qui commencerait avant la phase de programmation qui reposerait sur une équipe transversale pour prévenir plutôt que guérir ?

Découvrez plusieurs idées pour intégrer la qualité au cœur de votre application, afin de limiter les risques et la reprise du code, d’améliorer la compréhension au sein de vos équipes, et de déployer vos projets avec plus d’assurance et de sérénité.

 

La qualité : une responsabilité partagée

Beaucoup d’é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.

Pour adopter une approche quality-first efficace, il est essentiel de commencer par éliminer les silos qui séparent le business, les développeurs et l’assurance qualité.  Idéalement, la QA ne devrait plus être perçue comme une fonction distincte, mais bien comme un aspect intrinsèque et omniprésent au sein du processus de développement.

Par exemple, pensez au nombre de personnes que vous conviez à vos cérémonies Agile habituelles (daily, refinement, planning, etc.).  S’il y a trop de monde, certains n’oseront pas s’exprimer, ce qui mène parfois à des malentendus ou nuit au partage de connaissances. De plus petits groupes ou des équipes plus compactes encouragent au contraire la participation.

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 qu’initialement prévu, discutez-en quelques minutes en vue d’identifier les obstacles et de réagir aux éventuels changements inattendus, quitte à exclure ladite fonctionnalité de la release à venir. C’est ce que l’on appelle le « shoulder check » ou le « 3 amigos » en Agile.

Maintenant que tout le monde peut communiquer librement, quelles mesures prendre pour encourager la collaboration et faire de la qualité une responsabilité partagée par tous les membres de votre équipe ?

 

Définissez votre stratégie qualité sans tarder

En définissant votre stratégie qualité au début du projet, l’équipe delivery sera plus à même d’identifier les risques éventuels, comprendra mieux comment tester l’application, et s’appuiera sur des critères de réussite objectifs.

Notez cependant que cette définition de la qualité va au-delà des aspects fonctionnels de l’application (telles que la convivialité ou la compatibilité avec différents appareils) : les plateformes e-commerce qui s’appuient sur un modèle DevOps peuvent par exemple intégrer les métriques DORA à leur définition en vue d’obtenir un système performant.

Comme la qualité s’envisage sous plusieurs angles, la compréhension et la définition des aspects qualitatifs peuvent sembler difficiles à appréhender.

Pour y voir plus clair, je vous conseille de commencer avec RiskStorming. Dans le contexte de la définition de votre stratégie qualité, RiskStorming est utile pour se mettre d’accord sur les aspects qualité les plus importants de votre système. Ainsi, l’équipe partagera les mêmes compréhension et attentes vis-à-vis de la manière dont elle et ses clients doivent percevoir la « qualité ».

Compte tenu de la subjectivité de la qualité, la session devrait idéalement impliquer des représentants de différentes disciplines au sein de votre projet, avec au minimum des membres des services business et développement.  Ainsi, vous accorderez autant d’attention aux aspects business que techniques. En définitive, c’est le client qui est le plus à même de juger de la qualité, son implication est essentielle.

Testez vos attentes en termes de qualité

Maintenant que vous avez convenu d’une définition, essayez d’identifier les éventuels risques ou obstacles qui vous empêcheraient, vous et vos clients, de percevoir cette qualité. Ensuite, vous réfléchissez aux tests à employer pour lutter contre ces problèmes.

Dans le cas d’une plateforme e-commerce, la rapidité s’imposera 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 faudra 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 non valides ou incorrectes.

De même, si votre plateforme est principalement utilisée sur des appareils mobiles, les utilisateurs finaux risquent de rencontrer des problèmes de performance si leur connectivité n’est pas bonne.  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 vous utilisiez des chartes de tests exploratoires ou des modèles de tests classiques, vous avez tout intérêt à documenter votre approche d’analyse en équipe. C’est à la fois un bon exercice de collaboration, et une activité qui renforcera votre compréhension commune d’une fonctionnalité donnée. De plus, cela vous permettra de vous mettre d’accord sur le champ d’application des tests ; vous déterminerez plus facilement le moment où la fonctionnalité sera prête pour le déploiement.

Évaluez la qualité en continu

À tout moment au cours du développement d’une fonctionnalité système, demandez-vous : « Où en est la qualité ? »  Si vous n’arrivez pas à répondre avec assurance,  une boucle de feedback essentielle vous manque pour éviter les problèmes qui pourraient survenir en aval, lorsqu’il est trop tard pour agir.

Pour disposer de boucles de feedback rapides, vous devez mettre en place des processus permettant à l’équipe delivery de faire des tests à n’importe quelle étape du développement. Il s’agit de tester le projet même si vous n’avez pas encore de version fonctionnelle, en vue d’identifier les éventuels éléments qui mériteraient d’être examinés de plus près. Vous avez même intérêt à impliquer votre équipe delivery très tôt dans le processus, dès les réunions de découverte : comme elle connaît bien le système, elle vous signalera des dépendances techniques potentielles et vous aidera à déterminer la faisabilité de telle ou telle fonctionnalité avant que vous vous lanciez.

 

 

Le modèle de test holistique est un excellent exemple de la manière dont nous pouvons é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 de faire des tests pratiques avant de pusher le code dans un environnement de production peut simplifier la correction des bugs.  Par le passé, j’ai par exemple utilisé AWS Amplify pour obtenir un aperçu exploitable d’une webapp alors que les changements étaient encore en code review. 

Ainsi, il est possible d’identifier et de corriger les éventuels bugs front-end à l’étape de code review. Cela vous évite de retravailler votre code en aval, puisque vous avez détecté les bugs avant le déploiement. Dans le même esprit, je peux demander à un développeur back-end de me transmettre une compilation d’un webservice à exécuter localement. Cela me 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. Je vous conseille plutôt ceci : quand vous définissez vos critères de qualité, réfléchissez aux preuves dont vous aurez besoin pour déterminer où en est votre qualité à toutes les étapes du processus.

Les 3 piliers de la qualité

Il est difficile de définir la qualité, et encore plus de la mesurer. Mais si vous souhaitez adopter une approche quality-first dans vos projets, impossible d’y couper : vous devrez bien réfléchir à tout ce qu’elle implique pour vous.

Pour assurer la réussite de vos déploiements :

1. Changez de mentalité, en faisant de la qualité une responsabilité partagée dans toute l’équipe
2. Collaborez pour définir et comprendre vos attentes en termes de qualité
3. Testez et évaluez ces attentes tout au long du cycle de développement

3 piliers, et c’est réglé ? Pas tout à fait... Il vous revient de positionner et d’équilibrer ces éléments complexes et nuancés pour stabiliser le tout, mais je suis sûr que vous y parviendrez ! J’espère vous avoir donné des pistes utiles pour vous lancer. Maintenant, à vous de jouer !