Comment fournir rapidement une assurance qualité

Passer de l'assurance qualité à une assistance de qualité

Laura Daly Laura Daly

Il est difficile d'adapter les méthodes de test traditionnelles à une culture Agile. Les équipes se sentent obligées de sacrifier la qualité de leur produit au profit de la rapidité de livraison.

Pour régler ces problèmes, les équipes Atlassian ont lancé une approche différente des tests Agile appelée « Assistance de qualité ». Au lieu de former une équipe de test distincte chargée de la qualité, une petite équipe d'ingénieurs en assistance de qualité (QA) fait la promotion et enseigne des méthodes de test à l'équipe de développement. Découvrez cette transformation et comment :

  • créer une culture de la qualité ;
  • transférer la responsabilité des tests aux développeurs ;
  • éviter les bugs avant leur survenue.

Questions réponses

Consultez les questions réponses de cette présentation pour découvrir comment une équipe de 65 ingénieurs développe et livre rapidement un produit de qualité élevée avec seulement 6 ingénieurs QA.  

Q1 : Combien de temps faut-il pour briefer un développeur sur ce type de raisonnement ?

R1 : Il est plus difficile de changer la culture de toute une équipe que de transformer des individus. Il nous a fallu cinq ans pour que l'équipe Jira Software atteigne le niveau de qualité actuel, mais les nouveaux développeurs mettent peu de temps pour se mettre à jour. Ils adoptent rapidement l'état d'esprit de leurs collègues développeurs existants, et ils acquièrent rapidement les compétences de test via les binômes et les ateliers. Le plus difficile est de prendre connaissance de toutes les informations sur les risques et le produit. Cela peut prendre des années, mais nous atténuons cette difficulté par le partage de connaissances durant les lancements et les démonstrations d'assurance qualité.

Q2 : Les cas de test sont-ils encore nécessaires ? Sont-ils uniquement destinés aux tests automatisés/de régression ?

R2 : Les cas de tests manuels scriptés n'entrent pas du tout dans notre stratégie. Si un test est une simple « vérification » (c'est-à-dire un ensemble d'étapes prédéfinies et une assertion définie), nous pensons qu'il est préférable qu'un ordinateur le réalise plutôt qu'un humain. Le processus est ainsi plus efficace et moins sujet aux erreurs. Si un test en est vraiment un (s'il nécessite un sens critique, une liberté d'enquêter et une évaluation des risques), nous estimons préférable de le réaliser dans le cadre de tests exploratoires afin d'offrir une certaine forme de liberté et d'intelligence.

Q3 : Les développeurs coûtent généralement plus cher que les testeurs. Si nous employons des développeurs comme testeurs, n'est-ce pas une utilisation inefficace du budget/de la main-d'œuvre ?

R3 : Absolument, l'utilisation de développeurs comme testeurs pour exécuter une étape de test distincte fait perdre de l'argent et du temps aux développeurs. Cependant, une étape de test distincte (même réalisée par les testeurs) fait perdre de l'argent et du temps aux développeurs. Chaque fois que les testeurs remontent une story ou un bug aux développeurs, ce n'est pas seulement un coût de test, c'est un coût de développeur. En faisant passer le taux de rejet de 100 % à 4 %, nous avons gagné beaucoup de temps de développement perdu à reprendre des stories et à corriger des bugs stupides avant la livraison. Nous avons gagné le temps passé à enquêter, à générer des rapports, à trier, à évaluer, à reproduire et à réparer les bugs trouvés en interne. En outre, le code est conçu à partir de zéro de manière à faciliter les tests, car les développeurs savent que ce sont eux qui vont devoir les faire. DoTing (développeur sur test) a été une étape intermédiaire dans l'amélioration de la qualité, qui nous a permis d'éliminer complètement l'étape de test distincte. C'était un investissement temporaire qui a plus que payé.

Q4 : Nous disposons de développeurs et de testeurs QA dans différents fuseaux horaires. Ce modèle fonctionnerait-il uniquement dans un même fuseau horaire ? Comment travailler avec des équipes à distance ?

R4 : Nous avons effectué une assistance de qualité à distance avec des équipes en Pologne et au Vietnam, avec l'ingénieur QA basé en Australie. Ce n'est pas aussi efficace qu'une assistance qualité sur site, car être bon ingénieur QA consiste essentiellement à établir une relation personnelle avec vos développeurs. Un ingénieur QA distant est facilement coupé de la boucle, et il lui est beaucoup plus difficile d'évaluer la culture globale de l'équipe. Toutefois, nous avons réussi à exécuter des démonstrations de QA à distance, des lancements de QA et des sessions de jumelage via des appels vidéo (en contactant directement l'ordinateur de QA depuis celui du dév et en partageant l'écran).

Q5 : Les notes QA sont-elles prises story par story, ou créez-vous une base de connaissances de notes QA ? Comment gérez-vous les risques récurrents ?

R5 : Les notes de QA fonctionnent par story, c'est donc généralement les ingénieurs QA qui détectent les risques récurrents. C'est devenu de plus en plus difficile au fil des ans, à mesure que notre équipe QA Jira Software s'est développée, car un ingénieur QA ne sait pas nécessairement ce que les autres savent. Jusqu'à présent, nous avons atténué cet écart en organisant des réunions hebdomadaires de partage des connaissances et en mettant à disposition des pages wiki où nous gardons une trace des risques communs ou surprenants. Nous arrivons à un stade où cette méthode ne convient plus. À l'heure actuelle, nous travaillons sur une base de connaissances plus structurée avec une base de données de règles exécutées sur chaque commit. Par exemple, si elle voit que vous utilisez l'objet « User » dans votre code Jira Software, elle ajoutera un commentaire indiquant : « L'objet User peut être nul si l'utilisateur actuel est anonyme, vérifiez que vous le gérez correctement » au ticket. Ainsi, nous pourrons exploiter les connaissances des responsables de QA, et nous pourrions nous passer des lancements et des démonstrations de QA. Cela serait utile !