Connais-toi toi même

Prendre un temps de recul, s’extraire des urgences du quotidien, pour analyser nos pratiques, confronter nos expériences, formaliser et documenter nos méthodes : telle est l’ambition des « Ateliers SPYRIT » qui ont réuni toute l’entreprise les 7 et 8 octobre dernier.

L’objectif de ce nouvel événement interne est double : d’une part mieux accueillir les nouveaux collaborateurs ; d’autre part, partager des procédures éprouvées pour gagner en efficacité et en qualité.

L’enjeu était particulièrement important après la très forte croissance de SPYRIT, qui a vu son effectif quasiment doubler en quelques mois.

Château de Jambville, Centre national de formation SGDF

Le Château de Jambville, Centre national de formation SGDF

Re-connecter en pleine nature

Pour y parvenir, il était nécessaire de changer d’air, de nous mettre au vert et d’alterner les séances de cogitation et les activités plus manuelles. Quoi de mieux pour cela que d’aller chez les experts incontestés de la pédagogie de plein air et des activités nature ? Nous sommes ainsi partis au château de Jambville (Yvelines), Centre national de formation des Scouts et guides de France qui accueille également des séminaires d’entreprise.

Histoire de marquer la rupture par rapport à notre environnement de travail usuel, nous avons commencé par un activité de construction bois : une petite révision des nœuds puis une initiation au matelotage, pour fabriquer du mobilier avec des perches assemblées par brêlage.

Vite fait, bien fait : après une bonne heure, nous avions nos trois tables prêtes à servir le soir même pour un dîner trappeur, entièrement cuit au feu de bois, avec Paul et Aldric à la guitare, les chamallows grillés apportés par Thomas…

       

Écouter et comprendre l’autre
pour créer des bonnes pratiques en commun

Entre temps, nous sommes entrés dans le vif du sujet de ces premiers Ateliers SPYRIT. Un premier temps de rétrospective personnelle puis de mise en commun était proposé. L’objectif était de répondre selon son expérience et son ressenti. Quelques pistes de réflexion étaient proposées comme l’accueil chez SPYRIT, la transmission des informations, les pratiques, qu’elles soient bonnes ou mauvaises, les méthodes mises en place ou au contraire celles qui manquent.

Les thématiques les plus attendues ont vite émergé : le savoir-faire technique, la maîtrise des logiciels métiers, la gestion de projet, la sécurité informatique, sans oublier les procédures RH et administratives.

Le travail s’est poursuivi le lendemain en petits groupes pour produire les premiers livrables : supports de formations internes sur des sujets techniques (workflow git, installation docker…) ou métiers (processus de facturation, passage des projets en maintenance…), modèles types de documentation technique des projets ou encore préparation d’un livret d’accueil.

Un travail énorme a été accompli en une journée et demie, grâce à l’implication de toute l’équipe. Chacun a pu mesurer le bénéfice personnel de prendre du recul, de s’interroger sur ses propres pratiques professionnelles et de les confronter avec celles de ses collègues.

Le travail va désormais se poursuivre pour finaliser les documents et en assurer la mise à disposition, et pour organiser les premières formations internes.

Cette première édition des Ateliers SPYRIT en appelle d’autres, que ce soit pour aborder d’autres sujets, effectuer la mise à jour des documents ou encore vérifier si nous sommes toujours alignés avec les procédures définies.

Rendez-vous l’année prochaine pour la 2ème édition !

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.

  1. 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.
  2. 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.
  3. 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