Pourquoi les testeurs et les programmeurs ne s'aiment-ils pas? [fermé]

Au cours de ma carrière de programmeur, j'ai vu divers programmeurs et testeurs, et beaucoup d'entre eux ne s'aiment pas / ne s'aiment pas. Je veux dire, les programmeurs pensent que le travail d'un testeur n'est pas un "vrai" travail, et les testeurs pensent que les programmeurs sont trop "fiers".

Est-ce la bonne décision que j'ai prise, pourquoi est-elle, et que pouvons-nous faire pour éviter ce genre de problèmes?

Je pense que c'est une grossière généralisation et une simplification.

Je suis actuellement testeur, j'écris presque autant de code que j'ai écrit en tant que développeur (cela dépend de la phase de test) et mon meilleur ami dans l'entreprise est un développeur et nous nous entendons tous.

Vous voudrez peut-être jeter un œil à la culture d'entreprise et à la façon dont les équipes travaillent les unes envers les autres pour trouver votre réponse. D'après mon expérience, si vous avez des flux de travail très réactionnaires (c.-à-d. Les développeurs "lancent une construction par-dessus le mur pour tester" et testent "rejette les bogues") au lieu de travailler ensemble , juste à partir de différents points de focalisation ou "vecteurs d'attaque", alors vous ' ll constater que les deux départements en général, ne se détestent pas.

Là où je travaille, chaque équipe technique ou équipe de conception compte presque autant de testeurs que de développeurs travaillant ensemble pour produire des résultats. Cette sortie est un code de production qui répond aux exigences énoncées par le code de test.

Éditer

Notez également que je pense que le fardeau de la preuve incombe davantage au testeur qu'au développeur pour soutenir la relation entre les deux.

Il est beaucoup plus facile pour nous de rendre la vie des développeurs meilleure ou pire, mais l'objectif n'est pas simplement de "trouver des bugs" mais aussi de trouver des solutions potentielles. Si je ne peux pas, alors je ne peux pas, et je travaillerai avec quiconque se verra attribuer le bogue à ce stade pour trouver une solution. Mais si c'est une solution simple, je fournirai ce que je pense être un correctif potentiel qui satisferait les diverses exigences et l'éventuel test de régression que j'écrirai.

J'AIMER mes testeurs - ils me aider à résoudre et des choses que je repère ne pense pas comme un problème, mais nos clients ont dit qu'ils. Et le plus important pour moi, ils m'aident à ne pas tuer quelqu'un avec un mauvais code.

Pourquoi des problèmes surgissent-ils?

• Vous jugez constamment le travail de chacun, et certaines personnes ne peuvent accepter aucune critique
• Faire un mauvais travail fait perdre le temps à votre opposé
• Vous êtes tous les deux sous pression, en même temps, pour la même chose et personne ne veut être celui qui tient les choses en place

La combinaison de ce qui précède et de la nature des positions signifie qu'il est très facile de se débarrasser de vos colères et frustrations actuelles, si vous tombez dans ce piège, vous arrêtez de travailler ensemble et commencez à travailler les uns contre les autres. C'est difficile à sortir et ce n'est bon pour personne.

Je suppose que cela arrive parce que les programmeurs créent un programme, et ils perçoivent que les testeurs tentent ensuite de trouver des failles dans celui-ci (même si les testeurs font réellement partie de l'amélioration du produit final). Chaque fois que quelqu'un trouve des défauts dans quelque chose dans lequel vous faites beaucoup d'efforts, c'est probablement une réaction naturelle de réagir négativement envers lui.

Les moyens d'atténuer cela seraient de faire en sorte que les développeurs et les testeurs voient le produit fini comme le résultat de toute l' équipe (y compris les testeurs ET les développeurs) et de leur faire comprendre que les tests ne sont pas une mission de recherche de pannes autonome mais une partie importante de le processus de développement . Et si les développeurs ne pensent pas que le test est un vrai travail, ou que c'est facile, demandez-leur d'écrire les matrices de test, d'exécuter des centaines de cas de test, de documenter chaque étape et chaque résultat.

Je connais des programmeurs et des testeurs particuliers qui ne s'aiment pas, mais pas pour les raisons que vous avez mentionnées mais plutôt parce qu'ils fonctionnent les uns pour les autres.

C'est la nature de la bête. Certains des testeurs particuliers que je connais qui ne se souciaient pas de programmeurs particuliers parce qu'ils pensaient que leur code était sujet à des erreurs par négligence / paresse / etc. Certains des codeurs particuliers que je connais qui ne se souciaient pas de certains testeurs pensaient qu'ils utilisaient des conditions de test ridiculement artificielles (choisir des lentes) ou demandaient des révisions du code en fonction du style.

Je pense que garder les personnalités à l'écart et se concentrer sur la tâche à accomplir contribue grandement à réduire les tensions. Si une organisation est suffisamment grande, les tests en double aveugle sont une excellente idée.

Un testeur qui peut exprimer clairement les problèmes et les codeurs qui mettent clairement en œuvre des solutions sont une excellente équipe.

Dans les équipes où j'ai travaillé en étroite collaboration avec les testeurs, nous nous entendions très bien. Les testeurs comprennent les décisions qui ont été prises dans les différentes décisions prises, ils savent à quoi ressemblent les horaires des développeurs et un rapport est établi entre les deux groupes.

Dans les équipes où le test est une entité amorphe au large, cela n'a pas été le cas. Les résultats des testeurs sont moins pertinents car ils ne savent pas trop ce qui se passe, les développeurs commencent à redouter le flot de ce qu'ils considèrent comme des détails sans importance qui se trouvent dans des parties du programme qui n'ont pas été touchées en deux. mois, l'équipe de test est ennuyée qu'aucun des bogues déposés ne soit corrigé (parce que le calendrier est foiré et que les développeurs sont occupés à se préparer pour des démos ou à ajouter des fonctionnalités demandées, etc.), et en général, les deux groupes se voient comme antagonistes «autres» par opposition aux membres de l'équipe.

Travaillez en étroite collaboration et tout ira bien. Quelqu'un doit s'assurer que les deux équipes sont coordonnées et sur la même page. Ma meilleure expérience, l'équipe de test a été invitée à toute réunion de haut niveau à laquelle l'équipe de développement a été invitée (tous) et nous connaissions tous le calendrier, nous avions une liste de priorités unifiée, et les développeurs et les tests avaient tous deux la même chose (jusqu'à à jour) des exigences. Ma pire expérience (à part aucun test), nous avons essentiellement emballé nos affaires, les avons expédiées à l'étranger pour qu'elles soient examinées, puis nous avons tout récupéré un mois plus tard avec des choses marquées comme incorrectes qui n'étaient même pas les nôtres (plugin tiers qui a rencontré le nouveau exigences de l’équipe de test).

Aucun dev ou test ne réussira sans l'autre. Si vous travaillez comme deux moitiés de la même machine et respectez l'autre côté autant que vous respectez les membres de votre équipe les plus immédiats, tout ira bien. Comportez-vous comme deux machines distinctes et supposez que votre machine est meilleure, les choses seront terribles.

Lorsque les programmeurs et les testeurs ne s'aiment pas, c'est souvent parce qu'ils s'imaginent à tort que leurs objectifs sont en conflit.

J'ai constaté que ces problèmes sont considérablement atténués lorsque les testeurs et les développeurs sont dans la même équipe, plutôt qu'une «équipe de test» et une «équipe de développement». Je pense que c'est pourquoi, en tant que testeur, je préfère fortement travailler sur des équipes Agiles plutôt que sur le développement en cascade. Il y a plus de communication, le délai d'exécution est plus rapide, et les développeurs apprécient davantage le temps et le talent qui entrent dans les tests lorsque ce travail est plus transparent.

Individuellement, il y a aussi beaucoup à faire. En tant que testeur, je trouve que je suis capable de réduire ce frottement en fournissant des commentaires positifs ainsi qu'en trouvant des bugs. Je n'ai pas encore testé un développeur qui ne pouvait pas m'apprendre beaucoup , et je trouve que les développeurs apprécient un testeur qui travaille vraiment pour comprendre le code. Les développeurs sont fiers, comme tout bon artisan. Il est important de leur faire savoir que les bogues ne les rendent pas moins admirables

Les développeurs que j'ai trouvés les plus faciles à utiliser sont de bonne qualité et l'ont démontré en s'efforçant d'écrire du code de haute qualité avant que le testeur ne le voie, y compris en effectuant des tests préliminaires (principalement des tests unitaires automatisés et des tests de fumée manuels). Ces développeurs ont également demandé à test de faire des revues de code pour la testabilité, et ont inclus les testeurs dans le processus dès que possible, y compris en leur présentant les conceptions dès le début (ce qui permet aux testeurs de commencer à planifier des stratégies de test tôt, lorsque le test est plus léger). Les développeurs peuvent aider les testeurs à trouver les zones faibles de leur code en leur indiquant quelles zones ont été développées rapidement ou quelles zones ont été difficiles à tester. En général, tout ce que les développeurs peuvent faire pour faciliter le travail d'un testeur est apprécié et montre qu'ils apprécient le temps du testeur ainsi que le leur. Lorsque les développeurs font cela,

Un autre problème est que l'AQ est souvent un sujet de réflexion par de nombreuses entreprises. La plupart du temps, il est informé des projets à la dernière minute et est largement en sous-effectif par rapport à l'équipe de développement. À certains endroits, le chemin vers le développeur est le support technique, l'AQ, puis un développeur. Donc, parfois, il est composé de personnes qui souhaitent être des développeurs ... Et puis, quand ils trouvent un défaut, leur attitude est de savoir comment cette personne peut être un développeur et pas moi, je ne ferais jamais une telle erreur, etc ...

Dans l'ensemble, j'aimerais une équipe QA. Je pense également que les tests unitaires devraient être une partie nécessaire du développement logiciel séparé de l'assurance qualité. Ainsi, lorsque QA trouve des bogues, les tests unitaires sont modifiés pour tester cela. De plus, je pense que les développeurs qui effectuent des tests unitaires peuvent mieux comprendre ce que le contrôle qualité trouve.

De plus, de nombreuses équipes d'assurance qualité doivent faire les choses manuellement, auquel cas c'est un travail vraiment ennuyeux. Dans certains endroits, le contrôle qualité écrit des scripts et utilise des programmes d'automatisation qui permettent même de créer des scripts pour les interfaces graphiques (grâce à une sorte de reconnaissance d'image à l'écran pour les boutons / etc.). Ensuite, c'est toujours difficile quand des changements majeurs se produisent au début, mais ensuite tout est automatisé et cela semble plus amusant ...

Certains développeurs ont également méprisé l'AQ. Je préfèrerais quand même mieux que QA trouve un défaut que le client ....

Nous aimons nos testeurs ici, mais beaucoup d'entre nous se souviennent de ce que c'était avant de les avoir. Il est tellement préférable que les testeurs trouvent des problèmes que de les trouver après que vous êtes allé en production. Il n'y a pas de développeur vivant qui n'ait pas créé de bogue ou mal interprété une exigence.

L'essentiel est de traiter tous les professionnels avec politesse et respect, qu'ils fassent ou non ce que vous faites. Une fois que vous commencez à penser que votre travail est meilleur ou plus important que le leur, vous avez perdu.

Sur la base de cette question: Techniques ou catégories de tests de logiciels Je soupçonne que vous avez besoin d'un ajustement d'attitude envers les testeurs et les tests en général.

En tant que développeur, j'ai connu ma part de tension avec les testeurs.

Dans un travail, les testeurs testaient rarement la «bonne chose». J'implémenterais une nouvelle fonctionnalité pour le serveur de notre produit, et les testeurs rapporteraient un tas d'erreurs sur l'interface utilisateur. Étant donné que, dans ce produit, l'interface utilisateur était configurée non codée , la présence (ou non) de problèmes dans notre interface utilisateur de développement n'avait absolument aucun lien avec la question de savoir si les utilisateurs finaux auraient une interface utilisateur avec des problèmes similaires. Les testeurs le savaient, mais persistaient à enregistrer des bogues sur les zones étrangères.

Cela dit, les bons testeurs valent leur pesant d'or - je troquerais un développeur moche pour un bon testeur en un instant. Un bon testeur est un partenaire pour livrer un produit de qualité.

J'ai également connu des développeurs qui traitent les testeurs comme l'ennemi - comme si les testeurs introduisaient les défauts. Il est important pour les développeurs de réaliser que les testeurs n'introduisent jamais la faute - ils la découvrent simplement.

Comment éviter ces problèmes? Que diriez-vous d'être gentils les uns envers les autres? L'un a besoin de l'autre pour sortir une application logicielle de qualité, alors pourquoi ne pas respecter ce que chaque partie doit faire pour y parvenir? Apprenez à savoir ce que fait chaque partie et vous apprécierez peut-être le travail impliqué.

L'entêtement des deux côtés de ce qui est l'interprétation correcte d'une exigence serait là où j'ai eu tendance à voir le conflit entre les développeurs et les testeurs en général. Bien qu'il puisse y avoir une apparence de snobisme ou d'arrogance, c'est juste que chaque côté s'en tient à ses armes et veut avoir raison.

Un bon moyen d'éviter ce problème consiste à faire en sorte que 3 parties, le développeur, le testeur et un médiateur, soit un analyste commercial ou un chef de projet, déterminent comment les divers cas limites doivent être traités. Quelque chose à considérer est quel genre d'ego peut survenir en cas de désaccord entre les développeurs et les testeurs.

Les mauvais sentiments sont généralement le résultat d'une mauvaise communication, qui est généralement le résultat des programmeurs et des testeurs ayant des perspectives différentes du code. Le programmeur connaît intimement les bits sur lesquels il a travaillé, mais peut ne pas savoir comment ils s'intègrent dans le système global (au-delà de ce que la spécification lui dit). Les testeurs voient la situation dans son ensemble, mais ne connaissent pas le code en détail. Les groupes peuvent utiliser une terminologie et des procédures différentes pour les mêmes choses.

Cela peut entraîner le dépôt de défauts contre le mauvais composant (car le composant répond à une défaillance en amont) ou la fermeture de défauts légitimes par les développeurs car ils ne peuvent pas reproduire le problème dans leur environnement (car ils ne comprennent pas vraiment comment reproduire correctement le problème). Si cela se produit souvent, cela peut nuire aux relations entre les groupes.

Ensuite, il y a la joie d'obtenir un lot de défauts à la 11e heure; les délais sont imminents, la pression vous vient de votre supérieur immédiat sur la chaîne, et vous obtenez un nouveau lot de défauts sur un problème que vous savez déjà résolu et vous ne voulez vraiment pas avoir à prendre le temps de partir à travers le processus pour le prouver.

Un très bon moyen de faire chier votre équipe QA est de fermer sommairement plusieurs centaines de défauts légitimes mais de faible priorité (principalement déposés contre des interfaces utilisateur laides ou incohérentes qui étaient par ailleurs fonctionnelles) avec le raisonnement que votre arriéré de défauts de priorité plus élevée est si important que " nous n'y arriverons jamais. " Vous passez du rouge au vert sur la feuille de calcul du gestionnaire de programme et obtenez un attaboy de la haute direction, tandis que l'équipe AQ ​​prend un coup sur leurs mesures pour classer un tas de défauts faux.

Mauvais juju.

Cela découle souvent de trois facteurs -

• Des questions comme celles-ci indiquent l'existence d'un «folklore» dans l'industrie que les développeurs et les testeurs ne s'aiment pas. Les gens essaient de trouver des aspects qui renforcent cela, même lorsqu'un tel sentiment peut ne pas exister dans leur équipe.
• Chefs de projet incompétents mesurant les progrès par des mesures telles que le nombre de bogues enregistrés.
• Une équipe dysfonctionnelle (et un manque de leaders suffisamment soucieux de le réparer).

J'aime les testeurs, mais j'ai trouvé deux cas de conflit.

1. Lorsque la direction joue les testeurs et les développeurs les uns des autres.

2. Lorsque des problèmes sont constamment soumis et manquent de détails, c'est-à-dire que "l'écran x ne fonctionne pas".

Je pense que si c'est vraiment le cas, c'est un signe d'immaturité. Parfois, vous pourriez en parler comme d'une blague. Mais si vous (développeurs et testeurs travaillant sur le même projet) ne vous sentez pas comme une équipe, le résultat serait un désastre.

Les tests sont une partie assez importante du cycle de vie du développement logiciel (qu'il soit agile ou non). Vous ne devez donc pas considérer les testeurs comme des personnes qui vivent pour vous déranger avec des bugs, mais plutôt comme un coéquipier qui vous aide à expédier des logiciels de qualité.