Le but du testeur…

J’ai déjà abordé dans un article quel était, selon moi (et selon l’ISTQB), le but principal des tests. Pour rappel, leur but est de donner de la visibilité, un indice de confiance, sur la qualité d’une application. Je n’ai par contre jamais parlé du but principal du testeur.

Contrairement à ce que l’on peut penser le but d’un testeur n’est pas de :

  • Tester totalement une application
  • Trouver des bugs
  • Procurer la meilleure visibilité possible
  • Rester dans les budgets
  • Automatiser les tests
  • Mettre en place des processus et des processus de test
  • Communiquer avec les différents intervenants sur le projet
  • Faire des bilans…

Non le but d’un testeur c’est un peu tout ça à la fois mais également rien de tout cela. Pour trouver le but d’un testeur je me suis plutôt pencher sur plusieurs points qui sont :

Le premier point permet de se rappeler que même si le but des tests est de donner de la visibilité cette visibilité nécessaire n’est pas la même selon les logiciels. En effet :

  • Lorsque je marche sur le trottoir dans la rue (sans la traverser) une visibilité de 2 mètres est amplement suffisante pour me déplacer et ne pas me prendre un poteau
  • Par contre, lorsque je suis en voiture sur l’autoroute et me déplace à 130 km/h cette même visibilité est beaucoup trop faible, et dans le cas d’une visibilité de cet ordre (brouillard très dense) je roule très lentement et active mes feux de brouillard. Pour pouvoir rouler à 130 km/h il me faut en fait plus de 100 mètres de visibilité.

Le degré de visibilité nécessaire n’est donc pas le même en fonction du logiciel et dans ce cas le but d’un testeur est simplement de donner la visibilité « suffisante » pour l’application. Il parait inconcevable de faire des milliers de tests sur des centaines de téléphones dans des conditions de connexions diverses pour une simple application de lancer de dés qui ne collecte aucune donnée. Par contre, toute application permettant un paiement notamment au moyen de sa carte bancaire se devra d’avoir des tests de sécurités poussés afin d’assurer une bonne protection de ces données.

Le second point, sur lequel je suis en total désaccord (aucune entreprise n’enchaine les investissements à perte… Et toutes les entreprises de logiciel font du test), reste néanmoins très intéressant et rappel l’importance de coût des tests sur un projet.

En effet, si les personnes jugent les tests coûteux c’est parce qu’ils ne voient pas forcément le retour sur investissement. Il est d’ailleurs vrai que les tests et leur stratégie ne sont pas toujours optimisés ni adaptés au contexte… Dans ce cas on peut atteindre le niveau de visibilité souhaité mais à un coût qui pourrait être optimisé.

Ici le rôle du testeur est donc de proposer des processus et procédures qui permettent donc d’atteindre la visibilité souhaité et/ou nécessaire au coût minimal.

Cela explique l’essor du shift left qui vise à tester tôt pour repérer et corriger les défauts tôt et à moindre coût mais aussi la naissance du shift right qui vise à tester en production et recueillir des mesures en partant du fait que des tests plus complets ne seraient pas forcément suffisant et beaucoup trop coûteux.

Analyse :

De manière instinctive et si je voulais rester parfaitement rigoureux, je pourrais dire que le vrai but d’un testeur est d’atteindre la visibilité souhaitée… De préférence en restant dans les budgets et les délais…

Néanmoins cela serait oublier le 2nd point exposé plus tôt, point qu’il ne faut pas négliger.

J’arrive donc à une autre proposition :

Le principal but du testeur ne serait-il pas d’atteindre le « suffisant » ?

Je dirai même plus, un bon testeur ne serait-il pas un testeur capable d’exceller dans ce « suffisant » ?

Suffisant afin d’atteindre la visibilité souhaitée.

Suffisant en terme de budget, c’est-à-dire consommer le moins possible sur l’ensemble du projet (en comptant la potentielle maintenance selon la durée des projets) pour atteindre cette visibilité sans la dépasser. Dépasser la visibilité minimale peut vite coûter cher et il est important d’atteindre cette visibilité suffisante avec le moins d’investissement possible.

Pour cela un testeur se doit de mettre en place des processus et procédures adaptés au contexte afin d’atteindre les objectifs au coût optimal. Dès lors les processus et procédures mis en place se révèlent suffisant (attention à s’assurer qu’ils restent optimaux tout au long du cycle de vie du logiciel !)

Cela peut sembler relever du bon sens mais cette mise en place est tout sauf aisée notamment à cause de plusieurs points :

  • Ce qui est pertinent sur un projet ne l’est pas forcément sur un autre. Pourquoi automatiser des tests sur un projet développer en 1 semaine dont la durée de vie est estimée à 1 mois ?
  • Il faut faire comprendre aux membres du projet pourquoi on ne fait pas certains tests ou que l’on ne met pas en place certains processus
  • Il faut fortement travailler sa stratégie, anticiper divers scénarios afin de déterminer quelle est l’association la plus efficace
  • Il faut bien connaitre l’équipe et ses capacités. Il arrive fréquemment que la solution théorique optimale ne soit pas la solution optimale sur un projet… Cela se voit très régulièrement en terme de choix d’outils.

Pour atteindre cet objectif le testeur doit faire appel à de nombreuses qualités et connaissances. Il doit rester en veille afin de connaitre les nouvelles tendances dans le test mais aussi dans le développement, savoir anticiper sur l’avenir.

Conclusion

Il me semble donc que le véritable but du testeur est donc de se rapprocher le plus possible de la « perfection du suffisant ». Il doit donc atteindre et communiquer la visibilité nécessaire et suffisante (qui est le premier but du testeur) au coût le plus faible possible.

Qu’en pensez-vous ? Pour vous, quel est le but d’un testeur ?

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

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

Laisser un commentaire

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

Interview

Retour d’Expérience (REX): Cerberus Testing – Yves Richard

Yves Richard, expert QA et automatisation chez Ausy, nous partage son expérience avec Cerberus Testing. Contenu de l’interview Automatiser, oui, mais à quel prix ? Réussir un projet d’automatisation requiert la combinaison de plusieurs facteurs de succès. C’est loin d’être un seul sujet d’outillage réservé à des profils techniques. Une

Lire la suite »
BD

[Alerte Qualité] Lord of the Ring

Planche sous licence Creative Commons: pas de modification mais usage commercial autorisé Merci à Jerry Mbanta pour les dessins et à Dimitri Doye pour la co-écriture sur le scénario! N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos

Lire la suite »
Avenir

Enquête CFTL: les axes d’améliorations pour le test

Les résultats de l’enquête 2023 de CFTL sont disponibles. Cette enquête permet de faire un état des lieux régulier du test depuis plus de 10 ans. Cela permet de ce faire une idée des évolutions du test en plus de savoir, à un instant t, quelles sont les problématiques, les

Lire la suite »