Les développeurs et les testeurs sont du même côté - peu importe qu'une entreprise les place dans la même équipe (agile) ou dans des équipes distinctes de développeurs et de testeurs. C'est aux testeurs et aux développeurs qu'il incombe de créer une application de qualité. Pour atteindre cet objectif, ils devront collaborer de manière productive. Pour ce faire, et pour que leur travail soit mieux fait, plus rapidement et plus facilement, il existe différents conseils pratiques et astuces qui peuvent les aider. Je commencerai par les conseils et les approches qui se concentrent sur la coopération individuelle entre un développeur et un testeur. Dans la deuxième partie de cet article, je partagerai des conseils qui permettront d'améliorer la coopération au niveau de l'équipe.
Une meilleure coopération au niveau individuel
En tant que développeur, je considère les testeurs comme mon filet de sécurité. Je préférerais qu'un bug soit signalé par un testeur, plutôt que l'utilisateur final trouve un bug en production.
D'une manière générale, les gens ne se sentent pas à l'aise lorsque quelqu'un critique leur travail. Les développeurs ne doivent pas considérer les testeurs comme des personnes qui leur disent constamment qu'ils ont fait quelque chose de mal. Au contraire, les développeurs doivent considérer les testeurs comme des partenaires qui essaient d'empêcher les utilisateurs finaux de critiquer leur travail. En même temps, les testeurs doivent être conscients que les jeunes développeurs peuvent se sentir mal à l'aise lorsqu'ils reçoivent un rapport sur bug. Au fur et à mesure qu'ils acquièrent de l'expérience, les développeurs ne seront pas, ou du moins ne devraient pas être sur la défensive quand ils reçoivent des rapports bug.
D'après mon expérience, la coopération entre un développeur et un testeur sera meilleure si le respect mutuel est clairement visible.
Approches pratiques pour les cas de bugs difficiles à reproduire
Parfois, un développeur ne peut pas reproduire un bug qu'un testeur a signalé. Au cours de mes 17 années d'expérience professionnelle en tant que développeur, j'ai découvert qu'il existe quelques trucs et astuces qui peuvent aider.
Lorsqu'un testeur envoie une capture d'écran à un développeur, il est plus efficace d'envoyer une capture d'écran de l'application entière - et pas seulement d'un morceau de l'interface utilisateur. Parfois, lorsqu'un bug se trouve sur une partie de l'interface utilisateur, je parviens à trouver un indice pour le reproduire sur l'autre partie de l'interface. En envoyant simplement la capture d'écran de l'interface complète de l'application testée, un testeur peut faciliter le travail du développeur pour reproduire un bug.
Mais que faire si une capture d'écran ne suffit pas à reproduire un bug? que faire si les informations complémentaires fournies par un testeur ne sont pas suffisantes ? La vidéo est un excellent assistant. Utilisez l'application d'enregistrement d'écran pour enregistrer tout ce qui se passe sur l'interface utilisateur de l'application dans le cadre du test. D'après mon expérience, une vidéo est utile car un développeur peut trouver un (petit) indice pour reproduire un bug quelque part entre des étapes qui étaient déjà mentionnées dans la description de ce bug. Un petit détail peut déclencher un bug, et une vidéo aide le développeur à découvrir ce détail.
Remarque : il n'est pas nécessaire que le testeur parle dans son enregistrement. Entendre le testeur dans la vidéo n'a jamais été crucial pour moi pour reproduire un bug. De nombreux testeurs se sentiront plus à l'aise si on ne leur demande pas de s'enregistrer pour commenter la vidéo.
Gestion des conflits
En cas de conflit entre un testeur et un développeur, toutes les personnes impliquées doivent utiliser une communication efficace, faire preuve de diplomatie et ne pas prendre les choses personnellement. Les deux parties doivent considérer les choses du point de vue d'une autre personne - cette autre personne a également des échéances, des tâches, des priorités, etc.
L'objectif est de prévenir un conflit. Dans la vie quotidienne, il arrive qu'un court message permette d'éviter un malentendu et le conflit qui s'ensuit.
N'oubliez jamais que nous sommes tous du même côté, car nous construisons la même application.
Travail d'équipe à partir de zéro
Je recommanderais, surtout si les développeurs et les testeurs n'ont pas beaucoup d'expérience, de s'assurer que les développeurs connaissent bien le champ d'action des testeurs. Et inversement.
Pour éviter d'éventuels malentendus entre testeurs et développeurs, voire des conflits entre les deux équipes, il est essentiel que chacun connaisse les responsabilités des autres équipes.
Si les développeurs passent une partie de leur temps à maintenir la production, faites savoir aux testeurs quel pourcentage du temps les développeurs consacrent à cette tâche. Ainsi, les testeurs comprendront qu'il est parfois demandé aux développeurs de laisser tomber ce qu'ils font et de se concentrer uniquement sur le maintien de la production.
Les testeurs d'une équipe peuvent être impliqués dans l'accueil et la formation de nouveaux testeurs qui ne sont pas affectés à leur équipe. Parfois, il est demandé aux testeurs d'aider une autre équipe. Il est également important d'informer les développeurs que les testeurs ont une tâche supplémentaire (temporaire), afin que toute l'équipe soit consciente de la charge de travail.
Je recommande aux testeurs et aux développeurs, mais aussi à tous les autres membres de l'équipe, d'apprendre la théorie du travail en équipe.
Par exemple, je trouve utile de savoir que lorsqu'un seul membre rejoint ou quitte une équipe, nous nous retrouvons pratiquement avec une nouvelle équipe. La dynamique de l'équipe sera différente, même lorsqu'un seul membre de l'équipe change. La dynamique changera même entre les membres qui restent en permanence dans l'équipe.
Équipes Agile ou Waterfall
J'ai travaillé dans des équipes agiles utilisant principalement Scrum. Mais à un moment donné, nous avons également utilisé SAFe (Scaled Agile Framework). À d'autres moments, j'ai travaillé dans des équipes qui utilisaient le processus de la cascade. Sur la base de mon expérience, je peux dire que travailler de manière agile, où les développeurs et les testeurs font partie de la même équipe, apporte de multiples avantages.
L'un des avantages d'avoir des testeurs et des développeurs dans la même équipe est visible lors des réunions de planification de sprint. Alors que l'équipe planifie la charge de travail pour le prochain sprint, le PO peut découvrir du travail supplémentaire tout au long de la réunion. L'expérience antérieure et la connaissance interne de l'application peuvent aider les développeurs individuels à partager des idées précieuses et de nouvelles informations utiles. Ces informations peuvent avoir un impact sur les tâches à venir. Il est bon d'avoir à la fois des développeurs et des testeurs présents à la réunion de planification, afin que tout le monde entende immédiatement ces informations supplémentaires. Cela aide les testeurs à faire leur travail plus rapidement, car tous les cas de test sont couverts.
Si les testeurs et les développeurs n'étaient pas présents aux réunions de planification du sprint, du temps serait consacré à des réunions, des courriels ou des appels supplémentaires entre les développeurs et les testeurs, juste pour que les développeurs répètent des informations que les testeurs auraient pu entendre lors de la réunion de planification du sprint.
De plus, et d'après mon expérience, les testeurs peuvent améliorer la précision des estimations, car ils ont plus d'informations sur le processus de test lui-même. Ils réalisent parfois pendant la planification du sprint que des tests supplémentaires doivent être effectués.
Un autre avantage des testeurs et des développeurs travaillant dans la même équipe est que lors des réunions quotidiennes de la mêlée, de nouvelles informations précieuses sont souvent partagées entre tous les membres de l'équipe. Le partage des informations améliore la productivité, mais aussi l'esprit d'équipe. En fait, il accroît la volonté de s'entraider. Certaines personnes, plus que d'autres, seront enclines à aider les collègues qui font partie de la même équipe.
Dans ce cas, le processus en cascade est utilisé, et les testeurs doivent donc être inclus tôt dans le travail. C'est ce qu'on appelle l'approche shift-left, qui signifie que le travail des testeurs est décalé vers la gauche; en d'autres termes, il est décalé vers le début du processus.
Une meilleure communication
Beaucoup de gens s'accordent à dire que la communication entre les testeurs et les développeurs est importante. J'aimerais développer ce point.
Il est essentiel de partager les informations stratégiques telles que les délais, les changements de priorités, etc. avec toutes les personnes impliquées dans la création d'une application. Même s'il semble que certaines informations ne sont pas vitales pour tous les membres de l'équipe, n'oubliez pas que le partage des informations permet de constituer une équipe plus rapidement. Garder les gens dans l'ignorance et ne pas les inclure dans les sujets importants peut diminuer l'esprit d'équipe, la coopération et la productivité.
Si un membre de l'équipe garde pour lui les informations et les connaissances sur le projet et ne partage que le strict minimum avec le reste de l'équipe, cela nuira à l'équipe et au projet dans son ensemble à long terme. Peu importe qu'il s'agisse d'un développeur, d'un testeur, d'un analyste commercial, de product owner ou d'une autre personne. Les effets négatifs finiront par se manifester. Un chef d'équipe doit être informé et doit prendre la responsabilité de gérer la situation.
Conclusion
Pour améliorer leur coopération, les testeurs et les développeurs peuvent choisir parmi une longue liste de conseils. La coopération entre les testeurs et les développeurs est cruciale pour terminer l'application dans les temps. Dès le premier jour, intégrez des conseils pour la coopération individuelle entre un testeur et un développeur, et appliquez également des conseils pour un meilleur travail d'équipe. Réfléchissez aux changements de conseils et à ce qui est le mieux pour votre équipe.
.png)
