Cinq conseils sur la façon dont les testeurs peuvent collaborer avec les développeurs de logiciel

Chaque fois que je rejoins une nouvelle équipe, ma première tâche est de favoriser et d'entretenir une bonne relation de travail avec les développeurs. Pourquoi? S'il existe une bonne chimie entre les testeurs et les développeurs, la qualité du travail s'améliore à mesure que la qualité de la communication augmente.

La relation entre développeur et testeur ne doit pas être celle d'un artiste et d'un critique d'art. Il devrait plutôt ressembler à la relation entre un écrivain et un éditeur de copie, où chacun contribue à la qualité du produit final.

Développer une bonne relation de travail avec les développeurs peut être délicat. je suisvraiment chanceux de travailler ici à Threat Stack où mon travail est valorisé et mes idées sont appréciées, mais dans ma carrière - comme beaucoup d'entre vous - j'ai eu mes difficultés.

Dans cet esprit, voici cinq conseils que j'ai trouvés utiles pour entretenir et développer des relations avec mes coéquipiers développeurs.

Astuce n ° 1: Ne laissez pas les mauvaises expériences passées entraver le présent.

 Il peut être difficile d'être un testeur de logiciels. Les testeurs peuvent être blâmés pour:

• Trouver trop de bugs
• Signaler trop de bugs
• Faire mal paraître l'équipe
• Faire mal paraître le produit

Pour ma part, j'ai vu des managers entretenir une mentalité «nous contre eux» entre les développeurs et les testeurs, affirmant que cette rivalité passionnée est en fait une bonne chose, en gardant les deux camps sur leurs gardes. Des gestionnaires de tests ont insisté pour que les testeurs ne communiquent avec les développeurs que par le biais de rapports de bogues et que je n'ai que deux tâches: rechercher des bogues et ne pas déranger les développeurs.

Et j'ai eu des directeurs de développement me rejeter comme "seulement un testeur."

Même si la plupart de ces expériences se sont produites au début de ma carrière, ils peuvent bouillonner pendant que j'interagis avec les développeurs si je passe une mauvaise journée ou si Je travaille sous pression. Plus votre carrière se poursuit dans ce domaine, plus les soucis peuvent s'accumuler.

Malgré tout cela, il est important de ne pas laisser ces expériences passées interférer lorsque vous travaillez avec des développeurs.

Alors, comment un testeur peut-il faire face?

• Discuter avec un ami (en dehors du travail) si vous en avez besoin. Déballez vos soucis
• Parlez à un mentor ou à un conseiller d'orientation.
• Parlez à un manager avec lequel vous êtes amical.
• Si le travail est trop difficile à gérer, trouver un nouveau lieu de travail peut être une option.

Trouvez un moyen de gérer les expériences négatives passées afin qu'elles ne finissent pas par vous hanter. Faites tout ce qu'il faut pour que la prochaine fois que vous commenceriez à travailler avec votre équipe de développement, vous puissiez le faire avec un esprit clair et positif.

 Astuce # 2: Participez aux sessions de planification initiales.

Lorsqu'une nouvelle fonctionnalité de produit est planifiée et que le travail initial est limité, ne soyez pas un spectateur. Travaillez avec vos coéquipiers pour vous assurer que votre voix et votre expérience en tant que testeur soient entendues .

Développer une bonne relation de travail est plus que simplement prendre le déjeuner avec le développeur de votre équipe pour créer et tester la fonctionnalité (bien que cela aide). Apprendre à connaître le développeur non seulement en tant que collègue mais aussi en tant que personne crée un meilleur environnement pour la communication et la collaboration.

Alors que les nouvelles fonctionnalités sont introduites pour la première fois dans votre équipe, travaillez côte à côte avec les développeurs, réfléchissez et examinez chaque fonctionnalité, étape par étape.

Travaillez ensemble pour voir si les exigences sont lisibles, compréhensibles, claires et concises. Alors que les développeurs font des va-et-vient pour essayer de savoir s'il y a suffisamment d'informations pour créer la nouvelle fonctionnalité, travaillez avec les développeurs et les analystes commerciaux pour déterminer s'il y a suffisamment de mesures répertoriées pour tester.

Voici quelques exemples de mesures:

• Cette fonctionnalité est-elle testable?
• Comment savez-vous si la fonctionnalité passe? À quoi ressemble un échec?
• Qu'est-ce qu'une exigence critique? Qu'est-ce qui est simplement «agréable à avoir»?
• Quelles entrées sont acceptables?
• Qu'est-ce qui n'est pas acceptable?

Si la fonctionnalité a un segment d'interface utilisateur, existe-t-il des exemples de captures d'écran de l'apparence et du comportement du produit? Les captures d'écran et les maquettes sont extrêmement utiles pour créer des conversations sur la fonctionnalité, l'utilisabilité et la testabilité tout en discutant des exigences.

Si votre équipe utilise Agile, déterminez la complexité d'un problème en le comparant à un autre, en  lui attribuant divers points. Essayer d'attribuer des points stimule un débat sain et constructif, avec les développeurs, aide à tout comprendre et à contribuer à la conversation.

Une fonctionnalité prendra-t-elle beaucoup de temps à tester? Si les développeurs ne s'expriment pas et déclarent qu'ils ont besoin de consacrer plus de temps au développement et au test de cette fonctionnalité, ils vont se retrouver à faire sauter des délais ou à travailler beaucoup de nuits et de week-ends dans leur avenir immédiat.

Si vous utilisez Agile, n'oubliez pas que vous essayez de courir à un sprint sain. Ce n'est pas censé être une marche de la mort.

Astuce # 3: Concentrez vous profondément avec les développeurs avant le début de vos tests

Le développeur et le testeur sont les deux faces d'une même pièce. Le développeur se concentre sur la rédaction et la construction du produit. En tant que testeur, je me concentre principalement sur la manière dont un client utilisera le produit.

Le développeur se concentre sur la création du produit selon les spécifications en constante évolution.

Un testeur se concentre sur l'analyse des risques lors de la modification et de la mise à jour du produit.

Les développeurs et les testeurs ne sont pas des adversaires. Nous sommes coéquipiers - nous sommes partenaires.

Si une nouvelle fonctionnalité est en cours de développement et que vous ne savez pas comment elle fonctionnera, contactez les développeurs. Travaillez avec eux pour comprendre des choses telles que:

• Comment les données passent de l'interface utilisateur à l'API et à la base de données
• Si de nouveaux champs doivent être créés dans la base de données
• Si les données doivent être traitées avant d'être utilisées par l'API
• Le code est-il bien maintenu?
• Y a-t-il un risque que des éléments liés à cette fonctionnalité se cassent lors de la construction ou du nettoyage et du remaniement du code?

Ces préoccupations doivent être adressées à la fois  par le développeur et  le testeur. Travaillez avec les développeurs, les analystes commerciaux et l'expérience utilisateur. Soyez la caisse de résonance.

Astuce n ° 4: Profitez des perspectives de test de chacun.

Les développeurs et les testeurs ont des perspectives différentes en ce qui concerne la visualisation du produit logiciel en construction:

• Les développeurs voient le produit de bas en haut, voyant parfois l'interface utilisateur comme un mince placage qui couvre la machinerie du produit.
• Les testeurs ont tendance à voir le produit de haut en bas, en commençant par la façon dont le client utilise le produit.

Cette différence de perspective s'étend au sujet du test:

• Les développeurs peuvent penser à tester au niveau du code, en mettant l'accent sur les tests unitaires et d'intégration.
• Les testeurs peuvent se concentrer davantage sur les tests fonctionnels, en examinant le produit dans son ensemble.

En partageant la perspective unique de chacun, vous vous aidez à vous améliorer dans votre propre profession.

Lorsque les testeurs et toute l'équipe de développement travaillent ensemble, ils deviennent plus interdisciplinaires. 

Demandez à l'analyste commercial comment les exigences ont été construites. Demandez aux utilisateurs de l'expérience utilisateur comment ils ont déterminé à quoi devrait ressembler le produit. Demandez au développeur de donner une visite virtuelle de code alors que la fonction est en cours de construction .

Voyez si vous pouvez configurer des tests de paire avec le développeur. Vous en saurez plus sur la façon dont le produit est construit, et le développeur aura plus de visibilité sur la façon de tester cette création que vous façonnez tous les deux. 

Astuce n ° 5: En période de stress, essayez d'être gentil.

Il est très facile d' être stressé dans l'industrie du logiciel. Les délais sont toujours imminents. Les choses bougent si vite. Il y a toujours un nouvel outil ou une nouvelle technologie à apprendre toutes les quelques années. Les exigences peuvent changer plus rapidement que vous ne pouvez suivre. Les choses peuvent s'effondrer. Il est facile de se laisser submerger.

Si vous ressentez le stress, le développeur l'est aussi.
Les piles technologiques changent constamment. Les développeurs front-end doivent soudainement devenir des experts en JavaScript, puis Angular, puis Ember, puis React ou Vue , et quel que soit le cadre JavaScript que Google, Amazon ou Facebook préconisent l'année prochaine.

Même si les testeurs travaillent côte à côte avec le reste de l'équipe de développement pour planifier la façon de développer et de tester une fonctionnalité, la communication peut toujours être court-circuitée. Le bogue que vous avez trouvé n'est peut-être pas du tout un bogue:

• Les exigences ont changé, et un courriel de conversation s'est passé entre le propriétaire du produit et développeur dont vous n'êtes pas au courant.
• Le développeur a peut-être réalisé à la dernière minute que le produit n'a pas la structure pour prendre en charge toutes les nouvelles exigences. Les choses ont été réduites .
• Un bug a déjà été trouvé, et le concepteur, le développeur et le propriétaire du produit ont eu une réunion et ont décidé qu'ils pouvaient vivre avec le bug, et ils n'ont tout simplement pas encore eu le temps de vous le communiquer.

Ce n'est peut-être pas du tout un bug. Il pourrait s'agir d'une fonctionnalité non encore documentée.

Lorsque vous trouvez des bogues dans le code - essayez d'être gentil. N'agissez pas comme si le bug représentait un échec de leur éthique de travail. Dans l'industrie du logiciel, nous faisons tellement avec si peu de temps, et il est facile de se manquer. Établir de bonnes relations avec chaque membre de l'équipe, approfondir les aspects techniques de la fonctionnalité, solliciter des commentaires lors de la création du plan de test et tester en paire avec l'équipe peuvent tous aider à établir une bonne collaboration entre les membres de l'équipe . La partie la plus importante à retenir? En période de stress: essayez d'être gentil.