Les petits trucs de testeur: Aller voir le développeur

Introduction

Lorsque l’on conçoit nos tests, lorsque l’on les exécute, lorsque l’on détecte des anomalies puis que l’on remplit leur fiche, lorsque l’on fait du suivi de production… Bref, lorsque l’on travaille en tant que testeur nous sommes amenés à nous poser un très grand nombre de questions comme:

• Quelles sont les faiblesses de l’application ?
• Quelles sont les régressions probables de cette nouvelle fonctionnalité ?
• Est-ce que ce que je considère comme une anomalie en est vraiment une ?
• De quelles informations le développeur a besoin pour corriger l’anomalie ?
• Comment faire pour faciliter la reproduction de l’anomalie ?
• Quel est ce comportement en production ? Est-il normal ?
• …

Ces questions sont légitimes! Elles découlent du fait que nous souhaitons proposer des tests pertinents, efficients et remonter des informations fiables (et aussi complètes que possible). Pour cela une connaissance profonde de l’application est nécessaire… et, même si, en tant que testeur nous connaissons bien notre logiciel, ses caractéristiques, le comportement de ces utilisateurs et failles habituelles… il est quelque chose dont nous manquons généralement: la connaissance du code de notre logiciel et les difficultés qu’on les développeurs à implémenter les fonctionnalités demandées. C’est ici qu’intervient une nécessité (que l’on soit en Agile ou non!): il faut aller voir le développeur et échanger avec lui!

Aller voir le développeur pour mieux tester

Aller voir le développeur, discuter avec lui, échanger avec lui peut répondre (au moins en partie) à l’ensemble des questions mentionnées en début d’article:

• Quelles sont les faiblesses de l’application ?

Le développeur développe l’application, il connait les forces et faiblesses de ce qu’il a développé ou contribué à développer. Dans ce cadre il peut permettre d’évaluer ou d’identifier des risques auxquels nous n’aurions pas pensé en tant que testeur!

• Quelles sont les régressions probables de cette nouvelle fonctionnalité ?

Le développeur a fait les modifications de code pour implémenter la fonctionnalité. Il sait quelles sont les parties qu’il a modifiées. Dans ce cadre il peut permettre d’évaluer ou d’identifier des risques auxquels nous n’aurions pas pensé en tant que testeur!

• Est-ce que ce que je considère comme une anomalie en est vraiment une ?

On pense souvent au cas, « c’est pas un bug, c’est une feature« . Fort heureusement dans la vraie vie, lorsque l’on a noué une relation de confiance et où l’on collabore avec le développeur, ce type de problématique n’est que peu présente. Le développeur, comme le testeur connait bien l’application mais on un point de vue différent dessus. Un échange avec un développeur permet de confirmer ou d’infirmer nos impressions afin de définir la validité ou non d’un bug… et ce, même si la notion de bug, en elle même est... buggée.

• De quelles informations le développeur a besoin pour corriger l’anomalie ?

Les allers-retours des fiches d’anomalie… Cela peut vite tourner au cauchemar et faire perdre du temps. Je me suis d’ailleurs très vite aperçu de cette problématique dans mon expérience de testeur. Afin de limiter ces aller-retours j’ai trouvé un moyen simple et efficace: échanger avec le développeur, connaître ses besoins, connaitre son environnement de travail et le contexte afin de savoir qu’elles sont les informations dont il a besoin!

• Comment faire pour faciliter la reproduction de l’anomalie ?

Pour corriger une anomalie il n’y a rien de mieux pour un développeur que d’être capable de la reproduire. Pour cela il faut écrire, comme dit au point précédent, des fiches avec l’ensemble des informations dont il a besoin. Néanmoins, il se peut que, dans certains cas cela ne soit pas suffisant, que l’on soit dans un cas bien connu de « ça marche sur ma machine » ou une autre où vous êtes « le seul à réussir à reproduire l’anomalie dans l’équipe ». Dans ce cas, encore une fois, le mieux est d’aller au côté du développeur de reproduire l’anomalie à ses côtés pour qu’il arrive à avoir les logs.

• Quel est ce comportement en production ? Est-il normal ?

Le suivi de la production est essentiel. Néanmoins cette partie est technique et complexe et, en tant que testeur, nous ne comprenons pas forcément tout. L’idéal est d’échanger avec un Ops mais aussi avec le développeur. Ces derniers sont capables d’analyser plus aisément des logs et déterminer si un problème est survenu ainsi que son impact et sa cause.

Les questions abordées ne sont évidemment pas exhaustives et je ne peux que vous encourager à analyser les questions que vous vous posez au quotidien en vous demandant si un échange avec le développeur ne serait pas fructueux. Vous serez surpris de voir à quel point l’échange avec le développeur peut y répondre (ou aider à y répondre).

Conclusion

La collaboration avec le développeur est essentielle au testeur et n’est pas limitée à l’Agile! Un testeur est, par définition, un être social qui fait un travail d’équipe et qui ne peut être seul.

Un testeur est un être au savoir très important et spécialisé… mais aussi avec de nombreuses lacunes. Fort heureusement, le testeur n’étant jamais seul il est entouré d’autres personnes qui ont le même but que lui: proposer un logiciel fonctionnel de qualité. Dans ce cadre il est amené à travailler en collaboration avec de nombreux acteurs du projet (ou produit) dont le développeur. La collaboration entre le testeur et le développeur, est plus qu’un simple luxe, elle est essentielle et permet d’accélérer de nombreux processus et d’améliorer la qualité. Il est donc nécessaire pour le testeur de ne plus hésiter à « aller voir le développeur »

Ps: à titre personnel j’ai travaillé en Agile et en Cycle en V. J’ai connu des développements de logiciels catastrophiques et très bons avec les 2 méthodes. Dans tous les cas lorsque les développements de logiciels étaient bons il y avait une bonne collaboration entre testeurs et développeurs, lorsque nous étions en échec c’étaient quand cette collaboration était limitée

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.