Début d’une nouvelle série. Le but de cette dernière est de vous proposer mes réponses à des questions fréquentes sur le test.
Contactez moi si vous avez des questions ou même si vous souhaitez proposer un article proposant VOS réponses à ces mêmes questions.
Pourquoi teste-t-on ?
Cette question est centrale et comporte autant de réponses que de personnes à qui on la pose! Le pire c’est que toutes ces réponses sont bonnes (au moins dans leur contexte!).
L’ISTQB propose des objectifs de test que j’aime répartir en 4 catégories: trouver des défauts, donner de la confiance, prévenir des défauts et Donner de l’information pour la prise de décision.
J’ai également proposé un article spécifique sur les raisons de tester de « manière générale » et plutôt d’un point de vu des personnes dans cet article. J’y donnais 4 apports du test: vérifier la qualité de son travail, pourvoir échanger, pour s’améliorer, par curiosité (pour apprendre).
Si je devais répondre en une seule phrase tout en évitant les exemples que l’on voit régulièrement sur les bugs des logiciels et d’un point de vue « entreprise » je dirais que:
« on teste les logiciels car cela coûte plus cher de ne pas les tester »
Ne pas tester c’est se couper d’informations potentiellement vitales, c’est de potentiellement proposer des logiciels dont la qualité peut fortement nuire à l’entreprise ou ses utilisateurs. Ne pas tester c’est ne pas savoir si ce qui a été fait a de la valeur ou est utilisable mais c’est aussi faire faire aux utilisateurs ses « crashs test ». Dit comme ça cela semble inconcevable et c’est bien pour ça que (quasi) toutes les entreprises dépensent de l’argent dans cette activité souvent perçue comme non productive.
Qui teste ?
Tout le monde teste!
C’est d’ailleurs ce constat qui me fait dire que le terme de « testeur » pour désigner le métier est mauvais. Il laisse croire le contraire alors que dès que l’on creuse un peu on s’aperçoit que tout le monde a sa part!
Avec les niveaux de test on est souvent amené à indiquer quel rôle pour quel niveau de test. On y voit généralement que les développeurs font les tests de composants et tests d’intégration, les testeurs les tests systèmes, les métiers ou leurs représentants les tests d’acceptation.
Avec le principe de tester tôt (ex: revues et BDD) on voit qu’une collaboration est nécessaire entre les différents acteurs.
Bref tout peut être testé et tout le monde est amené à tester à un moment ou un autre comme on peut le voir dans cet interview fictive écrite avec Benjamin Butel.
Comment teste-t-on ?
C’est peut être une des questions les plus complexes et les plus dépendantes du contexte à laquelle les testeurs doivent faire face.
Les tests exhaustifs sont impossibles, il n’y a donc pas de formule miracle pour tout tester et s’assurer que « tout va bien ». Il faut donc faire des choix… qui ne sont pas automatiques car les tests dépendent du contexte.
Tout l’art du test est alors de déterminer comment être le plus efficient (dépenser le moins de ressources pour atteindre le niveau de qualité/d’information souhaité).
Fort heureusement le testeur dispose de nombreuses techniques, de manières de catégoriser les tests et d’approches afin de savoir quoi faire (ou vers quoi s’orienter). Il y a les techniques de conception, les niveaux de test, les indicateurs, des concepts (shift left / right…), des critères de qualité (ISO 25010)…
Pour bien tester il faut bien appréhender le contexte afin de déterminer la meilleure manière d’y répondre avec l’aide de l’ensemble des outils (au sens large) que le test a à sa disposition.
Qu’est-ce qui est testé ?
Tout peut être testé
et c’est d’ailleurs un des problèmes majeurs que l’on a avec le test: il faut savoir quoi testé et faire des choix!
De manière théorique ce qui est testé dans une entreprise est orienté et/ou définit dans la politique de test et la stratégie de test. Ces éléments servent de base à des logiciels plus spécifiques liés à des produits, des projets ou à des parties de ces produits et/ou projets.
Quand teste t-on ?
Un des principes du test est « tester tôt« .
Il est donc tentant de répondre qu’il faut tester uniquement tôt. Il faut faire attention avec cela car cela revient à une mécompréhension de ce principe. Ici le tôt veut dire qu’il faut tester dès que possible (comme avec les revues ou le BDD), dès lors ou l’élément à tester (cela peut être une expression de besoin, du code, un test ou tout autre chose) est en construction.
De même il ne faut pas tester uniquement tôt. Le principe rappelle l’importance de tester tôt car historiquement on se retrouve souvent à tester « tard ». Il est donc important d’effectuer des tests sur des objets déjà testés tôt. Les tests exécutés doivent alors être complémentaires et apporter une information différentes. D’ailleurs par « tard » on peut lire jusqu’en production comme on le voit avec le « shift right« .
Au final:
On teste tout le temps… mais pas de la même manière
Quel avenir pour le test ?
Le test évolue beaucoup tout comme l’industrie logicielle. Le test est d’ailleurs une branche assez jeune de cette industrie. Les évolutions n’en ont que plus nombreuses et rapides.
On y voit également de nombreuses expérimentations (notamment en Agile) avec l’absence de personnes appelées « testeurs » dans des équipes afin que tout le monde se sente concerné par la qualité et ait les compétences minimales nécessaires. Même dans ce cas les compétences ne sont pas perdues et dans les organisation que j’ai observées il existe une équipes transverse d’expert pour accompagner les équipes.
En bref
le test est promis à un bel avenir mais totalement imprévisible
D’un point de vue personnel je dirais que le test va probablement se scinder en 2 branches. Une branche technique lié à l’automatisation, les tests techniques et les chaînes d’intégration continue.
La seconde branche sera plus axée sur la partie stratégie, méthodologie mais aussi liée aux challenges contemporains (environnement, IA, transformations…)
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.
