La taverne du testeur

Testeur: choisir c’est être libre!

Le testeur est continuellement amené à faire des choix dans sa vie professionnelle. Ces choix sont liés à des questions auxquelles il se doit de répondre et qui peuvent ressembler à: Quels tests faire ? Sous quelle forme ? Quelles améliorations apporter au process ? Quelles adaptation apportées suite au changement de date de sortie ou au mauvais retours utilisateurs ? ….

L’exhaustivité des tests étant impossible le testeur est amené, en fonction de ses contraintes, à devoir faire des choix sur:

  • la manière de concevoir les tests
  • les tests à exécuter
  • la manière d’exécuter ces tests (priorisation, exploratoire, automatisé…)
  • les outils utilisés pour ses tests
  • les moyens de communication qu’il doit utiliser
  • le moyen de gérer les anomalies détectées (informelle avec un échange oral, formel avec une fiche d’anomalie plus ou moins détaillée…)
  • le niveau de criticité d’une anomalie…

Choisir c’est renoncer ?

On pourrait penser que ces choix d’options reviennent à renoncer à de nombreuses autres options… Et d’un certains point de vue c’est le cas. En effet:

  • la manière de concevoir les tests c’est renoncer à concevoir ses tests autrement
  • les tests à exécuter c’est renoncer à l’exécution de certains tests
  • la manière d’exécuter ces tests c’est renoncer à les exécuter autrement
  • les outils utilisés pour ses tests c’est renoncer aux possibilités des autres outils non présentes dans celui-ci
  • les moyens de communication qu’il doit utiliser c’est renoncer à certains moyens de communication qui pourraient être efficaces
  • le moyen de gérer les anomalies détectées c’est renoncer à gérer le bug détecté d’une autre manière
  • le niveau de criticité d’une anomalie c’est renoncer à faire un choix avec toutes les informations sur les impacts de l’anomalie

Néanmoins il reste bon de noter que ce choix n’est pas le fruit d’un hasard ou d’une volonté supérieure à laquelle le testeur se doit de se plier. Non, dans la très grande majorité des cas, ces choix sont le résultat d’une réflexion individuelle ou collective (ex: équipe Agile) à laquelle le testeur a contribué! Le testeur se retrouve donc acteur de ces choix… et a toujours la possibilité après des retours d’expériences de modifier ces choix par la suite (même si cela ne sera pas rétroactif).

L’absence de choix c’est l’aliénation

Au final, il peut être bon de se demander si le choix est vraiment un « problème ». Certes on se retrouve à devoir « renoncer » à certaines alternatives mais faire un choix revient également à adhérer à ce renoncement.

D’expérience, en tant que testeur ou même simplement « homme », je suis beaucoup plus frustré lorsque je n’ai pas le choix. C’est à dire que je n’ai pas pris part à une décision qui m’impacte. Dans ce cas là je me retrouve beaucoup plus frustré que si j’avais renoncé par moi même… et ce même si l’on arrive finalement au même résultat.

En tant que testeur cette frustration peut se ressentir avec:

  • L’obligation d’utiliser certains outils
  • Le devoir de suivre certains processus (vécus comme une perte de temps)
  • L’obligation de faire uniquement certains types de test (ex: pas de test exploratoire ou obligatoirement automatiser)
  • L’impact de décision administratives

On a tous vécu des dans notre vie personnelle ou professionnelle où l’on se dit que la décision que l’on nous impose est stupide mais que l’on doit la suivre car l’on n’a pas le choix (ou alors que le non respect de ce choix à un coût exorbitant).

Cette frustration vient du fait que l’on n’a pas le choix… nous devons nous plier à ces décisions, à ces contraintes, que l’on n’a pas choisies et que l’on nous impose telles des chaînes!

Choisir c’est être libre

Nous remarquons donc ici que le choix, au contraire de renoncer, c’est surtout être libre. Libre de prendre des décisions qui nous impacte directement. Si nous revenons au point de la première partie, choisir peut être vu comme renoncé mais aussi un très bon moyen de s’adapter à notre contexte. Choisir revient donc, pour les différents ci-dessous, à:

  • la manière de concevoir les tests => avoir la liberté de choisir la manière qui nous semble la plus efficiente de concevoir nos test
  • les tests à exécuter => avoir la liberté de définir les tests qui nous semblent les plus pertinents en fonction des objectifs de notre campane et de nos contraintes de temps
  • la manière d’exécuter ces tests => avoir la liberté d’agencer son temps et ses ressources de la manière qui nous semble la plus appropriée
  • les outils utilisés pour ses tests => avoir la liberté de « sélectionner » ou essayer les outils qui nous semble les plus appropriés
  • les moyens de communication qu’il doit utiliser => avoir la liberté de favoriser certains canaux de communication en fonction du contexte et de ce que l’on a à communiquer
  • le moyen de gérer les anomalies détectées (informelle avec un échange oral, formel avec une fiche d’anomalie plus ou moins détaillée…) => avoir la liberté de définir si le besoin nécessite d’être plus ou moins tracé
  • le niveau de criticité d’une anomalie… => avoir la liberté d’estimer un impact

Bref, je pense qu’il devient évident que de ce point de vue, faire des choix n’est pas un luxe mais bien une nécessité pour tout testeur. il est d’ailleurs intéressant de noter que cette liberté de choix est très poussée en Agile avec le concept d’indépendance des équipes… qui savent mieux que personne ce qui est bon pour elles!

Conclusion

Comme souvent il y a du bon et du mauvais dans le fait de faire un choix. La phrase « choisir c’est renoncer » tend à montrer une « mauvaise » partie (on pourrait également dire que choisir c’est la complexité et que le non choix est la simplicité!). Étant un adepte du choix je pousse pour la phrase qui tend à montrer le bon côté avec « Choisir c’est être libre ». Cette liberté est d’ailleurs ce qui fait que j’ai tout de suite aimé le métier de testeur.

Je tiens cependant à nuancer ce propos avec le fait qu’il reste important d’avoir un cadre et de ne pas devoir « tout choisir » tout le temps. De même il faut également se méfier de ce que j’appelle les « faux choix ». Je pense notamment à des « choix » comme: tu suis le processus ou tu est viré. Dans ce cas la contre partie est, dans 99,9% des cas beaucoup trop contraignante pour que cela soit vraiment un choix.

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Données

Outil de test: anonymisez vos données avec DOT anonymizer

DOT anonymizer est un outil d’anonymisation de données développé par la société ARCAD Software. Ce n’est pas proprement un outil de « test » mais un outil qui peut s’avérer essentiel… particulièrement dans un contexte RGPD. La proposition de cet outil est de récupérer l’ensemble ou une partie des données de production

Lire la suite »
processus

La phase de Retest

Le cycle de vie d’un bug  comporte plusieurs étapes décrites ci-dessous : Dans ce cycle, une étape est malheureusement souvent négligée : La phase de Retest (ou de vérification). A quoi correspond exactement cette phase ? La phase de retest d’un bug a plusieurs buts : ·        Vérifier que le bug est bien corrigé : un

Lire la suite »
Agilité

9 : Avantages de BML

Les tableaux présentés jusqu’à présent montrent que chaque affirmation BML peut faire l’objet d’une cellule dans un tableau. On se retrouve sous la forme de l’ATDD “automatisée” (avec un générateur automatique des scénarios de test).  Exemple : Quand X Y Alors Z direction(par défaut étape suivante) Etape E1 – RG1 X=0

Lire la suite »