Comment construire une bonne relation entre QA et DEV ?

Rappel des rôles de chacun

 L’équipe agile est composée de deux métiers à la relation bien particulière : les Quality Analysts (QA) et les Développeurs. Leurs rôles sont distincts mais ne cessent de s'entremêler.

En effet, ils sont en interaction permanente : l'un développe, l'autre teste ce qui a été développé puis signale les anomalies observées.

Avant de rentrer dans le vif du sujet, revenons rapidement et de manière non exhaustive sur le rôle et les caractéristiques de chacun :

• Le développeur dans une équipe agile a pour objectif de développer des fonctionnalités en répondant à un cahier des charges élaboré par le PO par le biais des User Stories. Il peut également contribuer à la rédaction des US en apportant son expertise sur les aspects techniques que ne maîtrise pas forcément le PO. Avant de merger ses développements, il effectue des tests unitaires, mais sa logique de test n'est pas toujours très objective, puisqu’il sait ce qu’il a développé (il s’éloigne donc rarement des sentiers battus). Cela ne permet donc pas forcément de reproduire les différents comportements qu'auront les utilisateurs dans la vie réelle.
• Le Quality Analyst, aussi appelé testeur ou recetteur, a pour objectif de tester les fonctionnalités livrées par les développeurs. Son rôle est de repérer les éventuels bugs en poussant ses tests au maximum afin d'assurer la qualité de ce qui sera par la suite mis en production. Le testeur va chercher mille et une manière de "torturer" la fonctionnalité développée, afin d'éviter qu'un utilisateur ne se retrouve coincé. Le bon testeur est curieux et créatif, et ce sont ces caractéristiques qui peuvent faire de lui "l'ennemi" du développeur.

On commence donc ici à voir se dessiner les raisons pour lesquelles développeurs et testeurs pourraient ne pas s'entendre.

Pourquoi la relation peut être tendue ?

 Comme expliqué précédemment, le travail des testeurs est de trouver les bugs dans le travail des développeurs, on comprend donc aisément pourquoi il peut parfois y avoir des frictions.

En règle générale, les développeurs sont concentrés sur le fait de délivrer des fonctionnalités, tandis que les QA sont concentrés sur la qualité de ce qui est délivré. Ainsi, les développeurs peuvent avoir le sentiment que les testeurs cherchent la petite bête dans leur travail. Evidemment, personne n'aime que l'on pointe ses erreurs, et il peut arriver que certains prennent les choses personnellement. Nous verrons plus loin comment pallier ce problème.

De leur côté, tous les testeurs ont déjà entendu au moins une fois le fameux "Non mais ça c'est rien, c'est pas vraiment un bug !". Ainsi, les développeurs peuvent avoir tendance à décrédibiliser le travail des QA. On pense d'ailleurs souvent que le métier de QA est plus facile que celui des développeurs, que les tâches sont moins complexes, moins exigeantes et que le travail des développeurs est plus important. De par leurs rôles intrinsèques les développeurs et les QA ont des points de vue différents, qui peuvent se confronter.

Prenons en exemple une fonctionnalité X décrite dans une US :

Il peut arriver que certains comportements attendus ne soient pas explicitement spécifiés dans l'US en question (oubli, inattention...). Ces comportements peuvent sembler évidents pour les testeurs, car leur rôle est de se mettre à la place de l'utilisateur. Or du point de vue du développeur ce qui n’est pas spécifié n’est pas attendu. Il ne va donc pas en tenir compte, et il aura raison car ce qui est sujet à interprétation doit être clarifié.

Ainsi, lorsque le QA testera, il aura l'impression que le développeur n'a pas réfléchi à l'utilisation de sa fonctionnalité, voire même qu'il manque d’implication. Il crée donc un bug au développeur, qui affirmera que la demande n'était pas spécifiée. On en arrive ainsi à s'accuser mutuellement pour un bug alors que tout le monde a raison.

 Mais si QA et développeurs sont si différents, ils restent totalement complémentaires et indispensables à la livraison des fonctionnalités. On comprend donc l'intérêt d'une bonne relation entre les deux parties.

L'importance d'une relation saine entre QA et développeurs

Les deux métiers ne peuvent pas aller l'un sans l'autre, ils ont tous les deux des rôles primordiaux.

Sans développeurs → pas de fonctionnalité

Sans testeurs → des fonctionnalités non optimales et potentiellement buggées

Une bonne relation entre les deux parties semble donc indispensable car il est difficile d'avancer et de délivrer de la qualité si deux des principaux acteurs ne s'entendent pas. D'autre part, on dit souvent que les développeurs ne parlent pas la même langue que nous, qu’ils ont un langage plus technique, et cela apporte une couche supplémentaire de complexité. Il faut réussir à se comprendre, et ce n'est pas forcément évident.  

Si on se base sur les arguments avancés plus haut, on comprend qu'il est facile pour chacun de se rejeter la faute. Or en agilité il n'y a pas de responsabilité individuelle, il n'y a qu'une responsabilité collective, en tant qu'équipe.

Il faut travailler main dans la main en gardant en tête l'objectif commun : délivrer la meilleure qualité possible à l'utilisateur. Et même si le QA est garant de la qualité, il n'en n'est pas le seul responsable. Les développeurs aussi ont la responsabilité de passer des tests unitaires pertinents.

Il n'existe aucune ambiance de travail où se rejeter la faute est source de motivation. D'une bonne entente entre les deux rôles résulte : moins de stress, un travail plus qualitatif et par la suite de meilleures fonctionnalités pour les clients.

Le fait que les QA et les développeurs communiquent permet aussi aux QA de mieux comprendre comment fonctionne l'applicatif sur lequel ils travaillent, donc de mieux comprendre les différents impacts et liens entre les fonctionnalités, et ainsi de mieux détecter la source des différents bugs. Cela permet un vrai gain de temps et d'efficacité.

Les développeurs doivent aussi comprendre que les QA permettent de détecter des bugs de fond, qui pourraient être bloquants ou problématiques plus tard. Il est ainsi possible de réagir vite, et donc de diminuer les risques liés à la qualité. Mais par-dessus tout, les développeurs doivent comprendre que le travail du QA est de trouver des bugs, ce n'est donc ni contre eux, ni pour les dénigrer, c'est leur travail.

Comment construire une bonne relation entre QA et développeurs    

 Maintenant que nous avons compris l'importance de la bonne entente entre les développeurs et les QA, voyons comment nous pouvons la mettre en place : d'abord grâce à des process de travail, mais aussi grâce à des habitudes moins formelles.

Par des process de travail

Certains process de travail peuvent permettre une meilleure compréhension entre les développeurs et les QA, et donc permettre une meilleure entente.

Du début à la fin du parcours de développement, le QA peut épauler le développeur et l'accompagner :

• En début de parcours le développeur peut avoir besoin des critères d'acceptance à la fois pour comprendre l'objectif de l'US, mais aussi à la fin de son développement pour s'appuyer dans ses tests unitaires. Grâce à ces critères d'acceptance on peut balayer les cas les plus évidents et donc éviter les bugs les plus bloquants.
• En milieu de parcours le testeur et le développeur peuvent adopter la méthode du pair testing (ou PO review). Le pair testing consiste à prendre quelques minutes entre le développeur et le QA (ou parfois le PO), et à passer quelques cas de test en local, sur l'environnement de développement, avant que la fonctionnalité ne soit mergée. Le testeur guide le développeur dans le parcours afin de lui faire exécuter quelques cas simples, passants et non passants. Ces quelques minutes sont très souvent vite rentabilisées car elles permettent de détecter rapidement les bugs les plus flagrants et les petits bugs de design par exemple. Cela représente donc un gain de temps comparé au temps qui aurait été utilisé pour déployer, tester, ouvrir le bug, le corriger, re-déployer... etc. L'idée est donc d'éviter l'effet ping-pong des bugs entre le testeur et le développeur pour des anomalies qui auraient pu être facilement évitées.
• En fin de parcours, les QA ont la possibilité de faciliter la résolution de bugs non seulement en cherchant la source, mais aussi en s'attachant à apporter un maximum d'informations lors de la rédaction des tickets de bug : captures d'écrans ou vidéos, informations complètes, jeux de données et utilisation de l'inspecteur, sont autant de bonnes pratiques qui permettent au développeur d'aborder plus sereinement un ticket.  

D'autre part, puisqu'on reproche souvent aux développeurs de ne pas se poser la question de l'utilisation finale de la fonctionnalité, il peut être intéressant de faire l'effort de plus souvent leur parler des projets en globalité. Leur expliquer le contexte du projet, les raisons pour lesquelles tel et tel choix ont été faits. Cela leur permettra de se sentir embarqués, de mieux comprendre la finalité du produit, ils seront ainsi plus à-même d'anticiper de potentiels blocages ou problèmes.

Dans la même optique, continuer de partager après la mise en production du projet est une bonne pratique à mettre en place. Il est toujours agréable d'avoir un retour sur son travail, et partager les informations sur l'utilisation de la fonctionnalité, sur les retours des équipes métier ou sur les datas récupérées, peut être un bon moteur pour que les développeurs se sentent plus impliqués dans le produit. 

Aussi, les développeurs disposent de connaissances techniques et font parfois un travail de veille sur les dernières avancées technologiques. Il peut ainsi être intéressant de les pousser à proposer des améliorations sur des fonctionnalités existantes qui ne sont pas optimales, à challenger les solutions proposées, ou encore à proposer des évolutions.

Une autre pratique qui peut permettre aux développeurs et aux QA de se rapprocher est de les faire animer ensemble la démo en binôme. Le fait de préparer la démo ensemble et que l'un effectue le parcours pendant que l'autre commente est un bon moyen de se rapprocher et de développer un bon esprit d'équipe. 

Par des habitudes plus informelles

On peut aussi améliorer la relation entre les QA et les développeurs de façon plus informelle, dans les paroles notamment.

Comme dans n'importe quelle équipe il est important de se féliciter et de s'encourager. Cela permet d'augmenter la productivité et le bien-être au travail.

Par exemple les QA peuvent féliciter et encourager un développeur lorsqu'il a été réactif, ou qu'il a terminé un ticket compliqué. A l'inverse, les développeurs peuvent féliciter un QA qui a trouvé un bug un peu tordu, ou parce qu'il pense toujours à mettre des jeux de données dans ses bugs.

 Il ne faut pas que le QA blâme le développeur en cas de bug et de la même façon le développeur ne doit pas se moquer de ce que lui remonte le testeur, ni considérer que le testeur cherche la petite bête, c'est son travail de détecter les anomalies.

On peut même faire de ces rôles un amusement, un jeu, un peu comme le chat et la souris. Le QA et le développeur peuvent avoir une relation amicale, rire des bugs détectés.

En développant une relation amicale on a plus de facilités à se parler, à dire ce qui ne va pas, à expliquer les choses sans que l'autre ne le prenne personnellement. Cela permet aussi de se challenger.

A retenir sur la relation entre QA et Dev:  

• Il est important que les QA et les développeurs s'entendent bien car leurs rôles sont intimement liés
• Garder en tête l'objectif commun : la qualité de ce qui sera délivré à l’utilisateur
• Chacun a quelque chose à apporter à l'autre
• Le pair testing permet d'éviter des bugs facilement détectables et de faire gagner du temps à tout le monde
• Partager les informations sur le projet avant et après sa livraison permet d'embarquer les développeurs pour qu'ils se sentent impliqués dans le produit
• Se féliciter mutuellement, s'encourager ! Cela crée une bonne ambiance, réduit le stress et améliore la communication