Alors que je vantais les mérites d’un collègue redoutablement efficace pour tester les applications, quelqu’un m’a demandé à quoi tenait cette qualité. Bonne question ! Qu’est-ce qui fait, au fond, qu’un testeur est un bon testeur ? Le sujet mérite qu’on s’y penche, car quel que soit le nom qu’on lui donne (recette, vérification d’aptitude, validation fonctionnelle ou technique etc.), la phase de test est une étape essentielle dans la réussite d’un projet informatique.
Elle permet tout d’abord d’assurer la confiance du client qui va recevoir une application déjà bien éprouvée – en évitant donc l’effet désastreux de tomber sur une erreur 500 au premier clic, assorti de la réponse bêtasse : « je ne comprends pas, ça marchait chez moi… ». Elle assure aussi les meilleures chances d’exploiter sereinement l’application dans la durée, et de consacrer le budget de maintenance à des optimisations et des évolutions fonctionnelles, plutôt qu’à colmater les brèches en urgence, une fois en prod.
Cela vaut quelle que soit l’organisation du prestataire. Bien sûr, in fine, il revient au client d’effectuer la validation définitive, mais je m’intéresse ici à ce qu’on appelle parfois la « recette usine », c’est-à-dire les contrôles faits par le prestataire avant livraison au client. Tous n’ont pas, loin s’en faut, de quoi justifier des postes de « testeurs » à temps plein, dédiés à cette seule tâche. C’est même plutôt rare. Cette mission est naturellement sous la responsabilité du chef de projet, qui l’assure souvent en grande partie lui-même, avec l’aide du lead developer, ou architecte technique (ou autre nom, les agences web et autres start-up ne manquant pas d’imagination pour trouver des appellations plus originales les unes que les autres : il faut bien innover aussi dans la terminologie le wording).
Bien entendu, les développeurs gardent la responsabilité d’assurer, à leur propre niveau, des tests unitaires et fonctionnels, si possible automatisés. Mais c’est bien connu : les développeurs sont les plus mauvais testeurs de leurs applications. Cela s’explique assez simplement : ayant codé l’application, ils savent comment elle doit être utilisée. Inconsciemment, ils ont donc tendance à rester dans le cadre de l’utilisation normale, ce qui limite la capacité à détecter les anomalies liées aux cas non prévus. En outre, et c’est tout à leur honneur, ils ont le souci premier de la validation technique, ce qui oriente leurs contrôles davantage vers des tests unitaires, ce qui ne suffit pas à détecter des incohérences dans les processus complets à travers toute l’application.
Quant aux tests automatisés, non seulement ils ne sont parfaitement efficaces que s’ils sont totalement exhaustifs (c’est-à-dire jamais), mais encore ils ne testent que ce qu’on a prévu de tester. Or, les anomalies ont en général le mauvais goût de ne pas prévenir. D’ailleurs, en pratique, les tests unitaires ne servent pas tant à éviter des bugs imprévus qu’à garder la cohérence de l’application au cours de son développement, en identifiant les régressions, quand une évolution à tel endroit perturbe ou casse le fonctionnement à tel autre endroit…
Bref, il faut donc des testeurs sachant tester. Revenons donc à la question posée : y a-t-il (comme pour les chasseurs….) une différence substantielle entre un bon testeur et un mauvais testeur ? Sans vouloir trop rapidement simplifier une question qui admet sans doute autant de réponse qu’il y a de situations, trois éléments se dégagent.
- L’expérience. C’est comme pour tout, vous me direz. Mais ici, il ne s’agit pas seulement de l’expérience accumulée par la pratique des tests, qui fait qu’on finit par savoir assez rapidement là où se situent souvent les failles (et même, en étant pointu, quels sont les péchés mignons de tel ou tel développeur – tant il est vrai que nous commettons souvent les mêmes erreurs…). Plus fondamentalement, il s’agit de la connaissance de ce qu’il y a sous le capot. En clair, avoir été soi-même développeur est un ici un grand atout. Quand on sait comment ça marche de l’intérieur, quand on a soi-même, par le passé, dû corriger des bugs, on devine plus facilement dans quels recoins de l’appli a pu se cacher la misère.
- Le décentrement. On pourrait même parler ici d’empathie. Comprendre intimement les préoccupations du client, adopter sa perspective permet d’utiliser l’appli d’une manière aussi proche que possible de la réalité, en ayant en tête les objectifs du client. Dans les projets classiques au forfait, cela fait partie d’ailleurs des missions propres du chef de projet. Dans les méthodologies agiles, cette attention est un peu moins concentrée sur le seul chef de projet, puisqu’avec les personas et les réunions qui scandent le projet, les développeurs s’approprient plus fortement les problématiques du client.
- La méthode. Une recette, ça s’organise. Se lancer bille en tête dans des tests au petit bonheur la chance est la plus sûre manière de ne tester que ce qu’on a déjà en tête, donc de rester dans les deux ou trois processus principaux, ceux qui sont tellement au centre de l’attention depuis le début qu’on est presque sûr qu’ils sont bons – et donc de passer à côté des éventuels vrais problèmes. Savoir écrire un bon plan de tests ou un bon cahier de recette réclame une certaine capacité d’analyse pour systématiser la démarche. Il faut être capable de décomposer de manière aussi exhaustive que possible le fonctionnement de l’application, les différents cas possibles, les résultats attendus à chaque fois. La combinatoire peut vite exploser et il faut à la fois trouver le juste équilibre par rapport aux risques estimés et à l’ampleur du projet, et posséder une bonne aisance dans la modélisation pour mettre en place des outils de formalisation et de suivi de tests.
Expérience, recul et méthodologie : trois notions clefs pour réussir les phases de recette, préparer une bonne appropriation de l’application par ses utilisateurs et réussir ce moment déterminant de transition entre projet et maintenance.
Pierre-Yves Stucki
