Communication testeur-développeur

Bien que beaucoup de choses soient écrites sur les communications développeur-développeur, développeur-client, développeur-gestionnaire d'équipe, je n'ai trouvé aucun texte qui donne des directives sur la communication et la relation testeur-développeur.

Que les testeurs et les développeurs soient des équipes distinctes ou dans la même (dans mon cas, je suis un seul testeur dans un projet de développement agile), j'ai la conviction que la perception des testeurs est extrêmement importante pour que les tests soient bien acceptés , et pour servir son objectif en améliorant la qualité du projet (par exemple, ils ne devraient pas être considérés comme une force de police).

Des conseils ou des études sur la façon dont un testeur devrait communiquer avec les développeurs?

Mise à jour : Merci à tous pour vos réponses. Ils ont tous confirmé ce que j'avais en tête. Pour l'instant, mon équipe était très réceptive à mon rôle et nous avons fini par faire de réels progrès. J'aurais pu en choisir plus d'une comme réponse, mais j'ai dû prendre ma décision.

Le moyen le plus simple d'améliorer la communication est de travailler avec vos développeurs (et designers et architectes, etc.) et de décomposer lentement ces rôles stupides et de réaliser finalement que nous sommes tous des testeurs, sauf que certains d'entre nous ont plus d'expérience que d'autres.

Pour agile, il suffit de le faire "à la livre". Les testeurs font partie de l'équipe et pas seulement une entité externe à qui vous remettez des trucs quand c'est fait. Votre précieuse expertise est mise à profit tout au long du développement. Tout d'abord, lorsque vous créez des user stories, vous contribuez à dériver des tests d'acceptation et à les automatiser. Ces tests sont ensuite utilisés par les développeurs dans leur travail. Vous passez également du temps quotidiennement à effectuer des tests exploratoires sur les travaux partiels et terminés, et discutez avec le PO pour clarifier et améliorer vos tests en continu.

C'est ce que je veux dire quand je parle de "travailler ensemble". Je suis absolument sûr que c'est ainsi que la communication au sein d'une équipe doit fonctionner. Cet article l' explique très bien d'ailleurs.

En face de cela, de nombreuses organisations aiment gérer le développement en plaçant tous les testeurs (et les administrateurs de base de données, les concepteurs et les programmeurs) dans des départements distincts. Cela va à l'encontre de la communication et ne sert qu'à cimenter l'idée d'un développement progressif. Essayer d'améliorer la communication dans une telle situation est possible, mais les améliorations mineures auxquelles vous pouvez vous attendre ne valent pas la peine. Du moins pas comparé au fait de mettre les gens dans la même pièce et de créer des équipes interfonctionnelles.

Je crois fermement en tout type de communication entre le développeur et le test.

Trop de fois, j'ai vu des combats de petits pains entre chaque équipe, mesquins d'avant en arrière ("fermé par conception", puis "rouvert", etc.).

Je dis toujours aux testeurs avec qui je travaille de venir me parler s'ils ont des doutes.

Une chose que je déteste vraiment, ce sont les développeurs qui sont tous arrogants à propos des tests et en parlent, donc tout ce que je peux faire pour favoriser de bonnes relations avec les équipes de test, j'essaie de le faire.

Un testeur doit être très clair et précis avec les développeurs lorsqu'il communique sur les erreurs et les tests. Une liste détaillée des étapes pour reproduire l'erreur, des captures d'écran si nécessaire ... Des descriptions vagues d'erreurs qui ne peuvent pas être reproduites ou dont les étapes de reproduction ne sont pas claires vont très rapidement détériorer la relation développeur-testeur.

Je n'avais jamais l'habitude de croire qu'il y avait toujours un niveau de désaccord entre développeur et testeur mais j'ai dû faire face à cette situation lorsqu'un de mes meilleurs amis a obtenu le rôle de testeur dans l'entreprise dans laquelle je travaillais et à ma grande surprise, il a été assigné le même module à tester que je développais et donc c'était vraiment de FUNtravailler avec lui et je dois dire qu'il est très important de comprendre l'opinion des autres dans une telle situation et d'avoir le contrôle de son propre ego, cela m'a beaucoup aidé et nous les gars, nous nous gélifions bien avec notre professionnel engagements ainsi que le niveau d'amitié personnelle.

Puisque vous avez déclaré que vous êtes un testeur unique dans un environnement Agile (en supposant Scrum), il peut être judicieux de tirer parti de la réunion rétrospective comme forum ouvert pour définir le processus de communication.

Comme vous le savez, la réunion rétrospective vise à remédier aux rides du processus Scrum. Il peut s'agir d'articles permettant aux développeurs de disposer d'heures XY de temps ininterrompu, de communiquer par e-mail uniquement le lundi et de communiquer verbalement le reste de la semaine, selon ce qui convient à VOTRE équipe; car la communication n'est jamais une approche universelle.

En tant que développeur, j'apprécie un testeur qui fait preuve d'initiative. Ils ne dessinent pas de lignes ... ils veulent que le défaut soit résolu; quelle que soit la cause profonde. Les développeurs et les testeurs doivent séparer les sentiments des affaires. Les défauts font partie de l'entreprise car les humains sont impliqués. La meilleure approche pour la résolution des défauts est une équipe alignée prête à résoudre les défauts de manière globale. Lorsque les lignes commencent à faire surface et que les bordures sont tracées; la communication va s'effondrer.

Profitez de vos réunions quotidiennes debout. Impliquez-vous autant que possible; non seulement avec les tests, mais avec le produit dans son intégralité. À la fin de la journée, un développeur et un testeur travaillent sur un seul objectif et doivent toujours garder cela en tête.

Je préfère voir les testeurs faire partie de la même équipe. À cet égard, il n'y a pas de problème de communication.

Chaque fois qu'un testeur doit parler à un développeur ou l'inverse, venez et discutons. Juste une routine de tous les jours.

Cependant, les deux parties doivent se respecter et faire leur travail correctement.

Les testeurs doivent fournir des détails approfondis sur les conditions de bogue et ne pas signaler quelque chose comme un bogue pendant sa conception. Surtout quand il suffit de demander au gars là-bas quelque chose qui ressemble étrangement à une fonctionnalité.

Les développeurs doivent prendre un rapport de bogue au sérieux et enquêter en profondeur et non pas simplement fermer le problème si vous ne reproduisez pas le bogue en cinq clics.

Une attitude professionnelle suffit.

L'outil numéro 1 que j'ai trouvé que moi, en tant que testeur (SDET), peux utiliser pour améliorer les relations dev-test est une flatterie honnête, en particulier sous la forme de recherche de mentorat auprès des développeurs.

Avec un peu de chance, les développeurs avec qui je travaille sont de meilleurs développeurs que moi. Ils ne sont pas parfaits, sinon je n'aurais pas d'emploi, mais il y a beaucoup de choses qu'ils connaissent mieux que moi. Ils ont été un pur développement, alors que mon attention est partiellement concentrée sur les tests. Je note ces choses qu'ils font mieux et je les mentionne fréquemment. Lorsque je lis leur code, je note des détails élégants ou des utilisations soignées des modèles de conception et les aborde. J'imite les développeurs, en utilisant des conventions de codage similaires lorsque cela est possible et en intégrant des composants de production dans mes outils de test lorsque cela est approprié (par exemple, la journalisation). Je reconnais leur expertise et, par conséquent, ils sont heureux de reconnaître la mienne. Attention, si je pense qu'il y a une meilleure façon de faire les choses, alors je m'exprime absolument - mais je vise à donner plus de commentaires positifs que négatifs, global. En général, j'essaie de rendre les commentaires négatifs plus formels et impersonnels (par exemple, les rapports de bogues) et les commentaires positifs moins formels et plus personnels (par exemple, les conversations en personne).

Donner des commentaires positifs sur la qualité ainsi que des commentaires négatifs et demander des conseils fait passer la relation du contentieux au travail d'équipe et à l'apprentissage mutuel et diminue la défensive. Les développeurs savent qu'ils peuvent me faire confiance pour toujours dire plus de bonnes choses que de mauvaises, alors ils se sentent à l'aise de m'écouter. En outre, poser des questions perspicaces sur le développement soulève leur opinion sur moi et brise le stéréotype "Les SDET sont des développeurs ratés" (où il existe toujours).

Je crois fermement qu'une bonne communication entre les développeurs et les testeurs est essentielle. Quant à la meilleure façon de le faire, je suis sûr qu'il existe de nombreuses bonnes approches, mais voici ce qui a le mieux fonctionné pour moi.

Communication directe / personnelle! J'ai trouvé que la communication personnelle, et non le courrier électronique, fonctionne toujours mieux. Il permet au développeur et au testeur de nouer une relation personnelle. Une fois que vous avez cela, les choses semblent mieux fonctionner et ont tendance à couler. Ils n'ont jamais de problèmes pour effectuer un test spécial ou faire un effort supplémentaire pour vous. Il en va de même pour le développeur et je prends toujours le temps supplémentaire pour regarder les choses sur lesquelles ils ont besoin d'aide ou qui ont un problème. D'après mon expérience, cela accélère la résolution des problèmes, il y a moins de temps perdu.