Faire comprendre l’importance des tests au client

Au début, tout va toujours bien !

Vous sortez de la dernière réunion validant les ultimes maquettes graphiques du projet. Chacun est très excité à l’idée du lancement, car enfin, tout vous paraît clair et concret, le design tangible sous les yeux. Vous n’attendez qu’une chose : que l’équipe de développement entame l’implémentation des premières fonctionnalités.

Le calendrier est bien défini pour les semaines à venir et les choses démarrent. Une fonctionnalité, puis une autre, et encore une autre… Vous êtes mis à contribution pour la recette. Mis à part quelques retours de temps à autre, tout se déroule plutôt bien.

Les premiers symptômes.

Puis arrive un jour où vous remarquez que le formulaire de contact ne fonctionne plus. Vous l’aviez pourtant testé il y a un mois. Il marchait ! De plus, aucune modification du code ne semble avoir pu impacter cette fonctionnalité… C’est curieux ! Ce problème, qui fait partie de la vie courante d’une application, est la raison première des tests : éviter les régressions.
 On a fini par comprendre la raison : un nouveau développeur, intégré récemment au projet, a mis à jour des librairies. Le changement semblait anodin et on lui avait justement confié cette tâche pour qu’il rentre en douceur sur l’application.
 Que va-t-il advenir si l’équipe continue à développer sans tests ? Ce type de situation se reproduira continuellement. La part de temps alloué à revenir sur des choses qui fonctionnaient, se fera de plus en plus grande. Et le temps, c’est de l’argent ! Mais ce n’est que le début des ennuis.

La frustration s’installe…

Vous vous rendez compte qu’il vous faut être de plus en plus attentif à la stabilité globale de l’application. Et donc, consciencieusement, vous vous appliquez à effectuer des vérifications complètes sur les parties les plus critiques. Vous perdez de plus en plus de temps à faire de la recette, à remonter des anomalies, à faire comprendre le cheminement suivi pour reproduire un bug. Du côté de l’équipe technique, ce n’est pas vraiment la joie non plus ! Pour finir le projet dans les temps, il va falloir mettre les bouchées doubles. Mais le client crée des tickets de bugs qui, dans un cercle vicieux, prennent le pas sur le reste à faire.

Des deux côtés, chacun expérimente dans la douleur d’avoir négligé les tests. Pour continuer à avancer, il va falloir corriger le tir.

Rétablir la confiance.

La dette technique est importante, mais les deux parties sont motivées à redresser la situation progressivement. D’un commun accord, les développeurs mettent en place des tests automatisés sur les parties les plus critiques. Cela vous libère du temps : dans votre check-list, plus besoin de vérifier une énième fois ce fameux formulaire de contact. Enfin !

Il y a également un fait nouveau : l’un des ingénieurs vous demande comment l’application doit se comporter, sur un cas un peu en marge, qu’il a décelé en écrivant un test. Cela pourrait être par exemple : que faire si telle valeur n’existe pas dans votre base client ? Doit-on stopper la procédure, ou proposer une alternative ?

De fait, c’est une situation à laquelle vous n’aviez pas songé : un premier exemple de raffinement des comportements ; un gain pour l’expérience finale utilisateur.

Un cercle vertueux.

Le projet ne sortira pas à temps, la faute à la négligence première. Mais désormais, l’application est plus solide. Et surtout, les bons réflexes sont intégrés à la routine comme une bonne hygiène de vie. Avec eux, viennent des bénéfices pas forcément attendus.
Bientôt, le projet sera mis en ligne. Demain d’autres développeurs assureront la maintenance et un nouveau « Product Owner » reprendra le flambeau. Ils hériteront tous d’une plus-value… voyons pourquoi.
 Le nouveau PO ne maîtrise pas pleinement le métier, et manque de chance, son prédécesseur est parti trop précipitamment pour assurer une transition solide. Une partie de la connaissance a disparu avec lui… 

En l’absence de tests, c’est le comportement de l’application qui fait foi. Mais comment être pleinement sûr qu’il ne s’agit pas plutôt d’un bug ? On pourrait croire ce genre de situations à la marge, mais je la mentionne pour l’avoir déjà rencontrée. Si, par contre, des tests sont présents et explicites, pour confirmer les comportements voulus, alors l’équipe de développement est capable, avec confiance, de remonter de l’information.

Les tests ont valeur de vérité. Ils servent alors de documentation, de base de compréhension.

Intégrer au quotidien de la qualité, a un bénéfice humain pas nécessairement quantifiable. Il s’agit plutôt d’un ressenti sur le confort de travail, à tous les niveaux.

S’appuyer sur une base solide permet de se concentrer sur ce qui a de la valeur ajoutée : les fonctionnalités au service de l’utilisateur final.
 Mais aussi, c’est prendre le pli d’un processus de communication sain, où l’on anticipe au mieux les cas d’usage, où les ambiguïtés sont levées en amont, où l’on s’entend sur un vocabulaire commun. L’équipe technique s’enrichit de la connaissance métier, et en retour le client comprend mieux le fonctionnement de son application.

En résumé…

Faites de l’intégration des tests une routine de travail qui engage l’ensemble des métiers. Au-delà des aspects purement techniques, on peut également souligner de nombreux effets vertueux qui en découlent. Pour n’en citer que quelques-uns :

– Assurance aux non-régressions

– Gain de temps à la recette

– Confort de travail

– Communication renforcée

– Anticipation des cas d’usage

– Documentation historique au projet, source de vérité

Cette liste, bien que non exhaustive, est loin d’être négligeable et devrait suffire à convaincre vos clients de tout l’intérêt des tests.