Un avis ? Un commentaire ?
Cet espace est pour vous.
How Google Tests Software (de James Whittaker, Jason Arbon et Jeff Carollo, 2012) est à nos yeux un ouvrage de référence. Il ne s’agit certes pas d’un référentiel de pratiques de test à appliquer à la lettre, mais nous avons été agréablement surpris de voir qu’il regorge d’idées intéressantes pouvant être adaptées à des entreprises de toutes les tailles. Ce qui nous a d’ailleurs inspiré un article sur les plans de test.
Ce livre peut être appréhendé comme une photographie des processus de test de Google à un instant T. Un instant déjà lointain, et pourtant bon nombre d’idées vous sembleront venues du futur ! Il est également truffé de bons mots, dont certains que nous avons choisi de partager avec vous dans cet article. A méditer sans modération !
A noter : les traductions sont de notre cru.
« La qualité doit être intégrée au logiciel, et non pas boulonnée par-dessus. Dans cette mesure, elle est du ressort du développeur. Point. » p. 229
« Quand le test devient un service qui permet aux développeurs de ne pas penser à la qualité, alors ils ne pensent plus à la qualité. » p. 230
Ces punchlines résument bien la vision du testeur portée par cet ouvrage : celle d’un facilitateur de la qualité, qui partage intelligemment le fardeau de cette responsabilité. Une vision agile par excellence.
« Les testeurs mettent en avant leur rôle, et non pas le produit sur lequel ils travaillent. Et dès lors qu’on détourne son attention du produit, celui-ci en pâtit. Après tout, le but ultime du développement logiciel est de construire un produit, pas de le développer, de le tester ou de le documenter. […] Les utilisateurs tombent amoureux de produits, pas des processus qui ont permis de le construire. » p. 230
Dans cette logique, les auteurs considèrent que pour se présenter professionnellement, « Je travaille sur Chrome » est une affirmation plus saine que « Je suis testeur ».
« Les développeurs ont un avantage clé sur les testeurs en ce que tout le monde s’intéresse aux artefacts qu’ils produisent. » p. 79
Elle pourrait être lue comme un constat grinçant, mais cette phrase est simplement un rappel de bon sens. Elle implique entre autres qu’en tant que communicant, le testeur doit se tenir à une exigence de concision. Les livrables de test doivent être avant tout opérationnels et les plus digestes possible. Cela rejoint la punchline précédente, on doit avant tout travailler au service du produit, la « beauté » de nos tests n’a pas d’importance.
Dans le même esprit, on retrouve :
« Un plan de test qui n’aboutit pas directement à des cas de test est une perte de temps. » p. 82
« Les bugs sont comme des gamins couvés par leurs parents. […] De même qu’un papa ou une maman sort son thermomètre, le testeur prépare ses outils. Un parent veut faciliter le diagnostic de la maladie de son enfant. Une mère veut faire comprendre au docteur à quel point son petit est mal en point. Un testeur veut faire connaître la criticité du bug, et plus encore, le rendre facile à corriger. » p. 126
Voilà une tendre comparaison à opposer aux esprits chagrins qui considèrent que le test est une activité destructrice… Elle est issue d’un encart très intéressant nommé « It’s a Bug’s Life ». Encore une puissante métaphore (voir notre série sur ce sujet) qui pourrait aider à faire changer la perception que beaucoup de gens ont des testeurs !
« ‘Pourrai-je bientôt me passer du test manuel ?’ Notre réponse est un non catégorique. [La mise en place de l’automatisation des tests] permet simplement aux testeurs de faire enfin le travail pour lequel ils ont été recrutés : des tests exploratoires bien pensés, de l’analyse des risques, et une réflexion orientée utilisateur. » p. 152
S’il fallait mettre un dernier clou au cercueil de cette idée reçue (« Les robots vont tester à la place des testeurs, youpi ! »), voilà une punchline qui pourrait vous inspirer. On la doit à Tejas Shah, alors à la tête d’un projet d’automatisation des tests pour Chrome.
« Assurément, ne pas livrer un logiciel n’est pas une option, bien qu’elle représente un risque d’échec inexistant. Une entreprise tire profit de risques correctement estimés. » p. 97
Bref, nous ne pouvons que vous conseiller la lecture de cet excellent ouvrage, et nous espérons que ces quelques amuse-bouche vous auront donné envie de le lire. Qui sait, peut-être voudrez-vous l’offrir à un de vos collègues pour Noël ?
Cet espace est pour vous.