Mois : mars 2022

Découvrir ODASE, partie II : intégrer les ontologies dans le SI

Posted on | by hightest | Leave a Comment on Découvrir ODASE, partie II : intégrer les ontologies dans le SI

ODASE est un logiciel permettant de formaliser la réalité du métier, de façon à constituer un référentiel exploitable par une multitude d’applicatifs.

La semaine dernière, nous accueillions Rémi Le Brouster pour nous parler de cette solution, de ses objectifs et du changement de paradigme que cela entraîne pour la définition des règles métier.

Nous nous retrouvons cette semaine pour échanger sur l’intégration de cette solution dans le quotidien des acteurs techniques.

H : Comment les équipes techniques utilisent la représentation du métier définie par ODASE ?

RLB : Avec l’équipe informatique côté client, on définit en parallèle comment ils souhaitent interroger l’outil. On peut par exemple déterminer un ensemble de services pour interroger ODASE, auquel cas on établit alors un contrat d’API. Nous nous occupons alors de réaliser la partie technique qui va proposer les services, transmettre les informations à l’outil, demander le résultat, et le retourner. Ainsi, ni le client, ni le serveur n’ont à connaître le fonctionnement métier.

Afin de décorréler encore plus le technique du métier, et exploiter encore plus l’explicabilité fournie par l’outil ODASE, l’API n’a pas nécessairement besoin de se baser sur la modélisation métier. Nous réalisons alors une ontologie d’intégration, qui fait la conversion entre les concepts métiers et les concepts techniques. Cette correspondance est donc parfaitement compréhensible et documentée, et il n’y a donc pas besoin d’aller investiguer du code pour comprendre le mapping. La passerelle entre le métier et le technique est donc une simple affaire de traduction, très localisée et lisible, et cette indépendance entre le métier et le technique permet de pouvoir avancer sur les deux aspects de façon indépendante.

H : Comment les développeurs accueillent la solution ODASE ? Le fait qu’il y ait besoin de s’interfacer avec un outil tiers complique-t-il leur travail ?

RLB : Les développeurs n’étant pas une entité unique, je suppose que leur accueil de la solution doit varier. Par exemple, je sais qu’en tant que développeur, j’adore me creuser la tête sur des problématiques métiers, définir le périmètre précis et les cas limites, et trouver des algorithmes efficaces, ce que rend obsolète ODASE sur la partie métier, le périmètre et les cas limites étant modélisés en amont, et les résultats étant calculés par l’outil.

A ma connaissance, la plupart des développeurs préfèrent s’occuper de la partie technique, ce qu’ils ont encore plus le loisir de faire grâce à notre outil. Cela leur évite également les frustrations de devoir gérer des spécifications métiers qui ne sont pas toujours limpides, ou de se rendre compte trop tard de la divergence entre la réalité métier et ce qu’ils en avaient compris, ce qui invalide parfois toute leur implémentation.

Concernant le fait de s’interfacer avec ODASE, c’est aussi simple que de s’interfacer avec n’importe quelle autre API ou JAR (selon le choix technique qui a été fait), ce à quoi les développeurs sont généralement habitués. ODASE a donc plus tendance à leur simplifier le travail et à leur éviter des frustrations que l’inverse.

H : Certains développeurs aiment particulièrement apprendre des choses sur le métier, pour comprendre pourquoi ils font ce qu’ils font et donner du sens à leurs efforts. En séparant les règles métier de l’implémentation technique, y a-t-il un risque de frustrer les développeurs qui ont ce type d’appétence ?

RLB : Bien que cela soit possible, s’ils aiment autant s’occuper de problématiques métiers que moi, je pense qu’il reste important pour les développeurs de se familiariser avec le métier, même dans une approche ODASE, ne serait-ce que pour comprendre comment seront utilisées leurs applications. Ainsi, même si on les libère d’une partie de la gestion de ce métier, on ne saurait que trop les encourager à s’y intéresser tout de même (et encourager leurs employeurs à leur y octroyer du temps !). Idéalement, ils pourront alors s’appuyer sur la modélisation ontologique pour approfondir leurs connaissances métiers, afin de proposer et délivrer des applications et fonctionnalités plus pertinentes.

H : La solution ODASE, quand elle est mise en place, semble devenir le point névralgique d’un système d’information… Le SI devient-il « captif » de cette solution ? Les équipes de vos clients deviennent-elles autonomes, ou bien faut-il faire appel aux ontologues d’ODASE pour chaque ajout de règle métier ?

RLB : Dans une approche idéale où le client embrasse intégralement l’approche ODASE, notre solution devient en effet le point névralgique du système d’information, et je pense qu’il est essentiel de comprendre pourquoi, afin de saisir aussi en quoi cela peut aussi être émancipateur, notamment si le client veut changer totalement d’approche plus tard, et refondre son système d’information tout en revenant à une approche classique.

Tout d’abord, je tiens à rappeler que le système d’information ne se limite pas simplement à de l’applicatif, mais inclut aussi l’ensemble des échanges entre les acteurs et leur accès aux informations et documentations.

Dans une approche classique, la définition du métier est morcelée. Elle se trouve dans les connaissances et souvenirs des différents acteurs, dans des brouillons papiers, dans des mails, dans des outils de ticketing, dans des documents à destination du métier, des développeurs, du support ou des utilisateurs, dans le code aussi bien en langage informatique qu’en commentaires, etc. Il devient alors difficile d’interroger ces connaissances, et de savoir quelle source est fiable pour quel aspect. Car une spécification peut être obsolète ou décrire un changement qui n’a pas encore été implémenté, et même un expert avec une excellente connaissance métier peut se tromper, surtout face à des spécifications changeantes; l’interprétation du code par un humain peut passer à côté de certains cas particuliers, et le code lui-même est rarement une source unique, avec de multiples applications intégrant différentes règles, et comme nous venons de le voir, ces règles varient selon la source qui a été choisie en amont.

Dans l’approche ODASE, l’essentiel de notre travail est d’agréger toutes les connaissances de l’ensemble du domaine à modéliser, et de clarifier ce qu’est la vérité métier. A partir de là, nous construisons l’ontologie métier qui servira de référence. L’entreprise obtient ainsi un point unique qui définit toutes les règles de façon parfaitement indépendantes, et qui est interrogeable directement, que ce soit pour valider cette définition métier (plus besoin de tester extensivement le métier dans chaque application, et de devoir comparer les résultats !) ou pour vérifier ce qu’on obtient, d’un point de vue métier, dans telle ou telle situation. Cela signifie aussi que quelqu’un ayant une question métier peut la confronter à une source fiable. Cette source est réellement un point unique en ce que l’ensemble des applications peuvent se baser dessus, car elle ne décrit pas des règles métiers pour une application ou un ensemble d’applications, mais bien les règles métiers de l’ensemble du domaine. Ainsi, même pour une nouvelle application ayant besoin de nouveaux services afin d’interroger certains éléments intermédiaires, il suffit de rajouter techniquement de nouveaux services dans l’interface programmatique d’ODASE, autrement dit de nouveaux points d’entrée ou de nouvelles façons de l’interroger, mais sans toucher aucunement à la partie métier. De même, si c’est la partie métier qui change, sans que cela n’impacte les éléments nécessaires et donc la partie technique, il suffit de modifier les règles métiers, puis de déployer la nouvelle version sur les différentes plateformes intégrant ODASE.

Cette solution a donc ceci d’émancipateur que :

  • si le client veut remplacer une application faite il y a 15 ans en développant une version plus au goût du jour, il n’a pas besoin de recoder la partie métier, ni de développer de nouveaux algorithmes car le métier est approché d’une nouvelle façon (par exemple, avec l’ordre des questions qui change) ; il peut se concentrer purement sur la partie technique
  • si le client veut refondre totalement son système d’information et se séparer d’ODASE, pour déléguer l’ensemble de sa gestion à un gros ERP par exemple, le fait d’avoir défini clairement le métier en un point unique et fiable fera que son travail sera grandement facilité, et qu’il y gagnera en coûts, en qualité et en délais.

Pour ce qui est de la modification lorsque l’approche ODASE est en place, passer par nous est tout à fait possible et encouragé, notamment pour garantir la qualité de la représentation ontologique. Toutefois, il est également possible pour le client d’avoir son ou sa propre ontologue qui réaliserait tout ou partie des modifications (on pourrait par exemple former quelqu’un chez le client à cette fin).

Pour ce qui est des modifications classiques (par exemple les prix qui évoluent d’une année sur l’autre), on peut avoir ces éléments stockés dans des sources externes (fichiers Excel, base de données, autre), que le client pourra aisément mettre à jour, afin qu’il n’y ait qu’à relancer les instances du serveur ODASE pour que tout soit pris en compte (dans le cas d’une utilisation en mode serveur).

Enfin, nous sommes actuellement en train de développer un outil pour rendre les ontologies plus accessibles, aussi bien pour les visualiser que pour les modifier.

Il me semble que l’important, comme dans tout domaine, est de faire réaliser les modifications par des personnes dont l’expertise est adaptée à la complexité de la modification à apporter. Et nous visons à permettre que ces personnes puissent être côté client, afin justement d’offrir de l’autonomie et de la maîtrise, aussi bien en faisant progresser l’expertise côté client qu’en simplifiant la réalisation de modifications.

H : Est-il possible d’intégrer ODASE au sein d’un SI ayant une forte proportion de legacy, ou est-ce plutôt une solution à privilégier sur des SI naissants ou du moins récents ?

RLB : Il est évidemment toujours plus confortable de travailler sur des bases neuves ou saines, plutôt que de devoir investiguer l’ancien. Toutefois, ODASE a principalement été utilisé dans des contextes de refonte du legacy de grosses structures, pour lesquelles les approchent classiques avaient déjà échouées plusieurs fois. En effet, l’approche ontologique permet de s’abstraire au fur et à mesure de la nébuleuse qu’est souvent la structure legacy, tout en testant ensuite le fait d’obtenir les mêmes résultats. De plus, là où dans les approches classiques, un petit détail peut invalider toute la structure de l’implémentation, ou forcer des contournements qui s’accumulent rapidement et rendent l’ensemble instable ou non-maintenable, dans l’approche ontologique, il est juste question de rajouter un concept, quelques attributs ou modifier / créer quelques règles supplémentaires. Autrement dit, c’est aussi simple que de mettre à jour de la documentation métier, mais sans avoir à s’encombrer de formulations complexes ni de phrases à rallonge.

H : Quelle est la plus grande réussite d’ODASE à ce jour ?

RLB : ODASE est actuellement utilisé dans le milieu de l’assurance, ce qui est gage de la fiabilité de l’outil et de l’intérêt de l’approche. C’est une très belle référence pour nous, et notamment de notre capacité à modéliser avec précision des ensembles métiers particulièrement complexes. 

H : Comment ODASE vise à se développer dans les années à venir ?

RLB : Nous sommes en train de créer notre propre outil qui permettra de visualiser et d’éditer les ontologies. L’objectif est que l’ensemble devienne plus simple, intuitif, pratique et confortable d’utilisation. Les étapes clefs sont :

  • la visualisation de l’ontologie (concepts et règles), en permettant de construire et enregistrer des vues qui affichent seulement les concepts qui leurs sont pertinents,
  • l’édition simple d’attributs ou de règles, pour permettre au métier de gagner de l’autonomie sur ces aspects,
  • l’ajout de règles,
  • puis de rajouter progressivement différents outils qui sont pratiques ou nécessaires pour les ontologues.
Etat actuel de l’outil de visualisation des ontologies.
Tout cela se fera évidemment en prenant en compte les retours des utilisateurs et utilisatrices, et avec pour objectif d’avoir avant tout un outil simple pour le métier, et ensuite seulement un outil pratique pour les ontologues, ce qui passera vraisemblablement par le fait de conditionner l’affichage de certains éléments à des options.

Merci à Rémi Le Brouster pour cette présentation détaillée du fonctionnement d’ODASE !

Découvrir ODASE, partie I : définir les ontologies

Posted on | by hightest | Leave a Comment on Découvrir ODASE, partie I : définir les ontologies

Il était une fois une entreprise qui avait un système d’information. Dans ce système prospéraient différents applicatifs, plus ou moins récents et plus ou moins bien maintenus. Même s’ils formaient un ensemble hétéroclite et souvent assez bancal, tous ces applicatifs avaient bon nombre de points communs. Premièrement, ils parlaient souvent des mêmes choses (de « clients », de « contrats », de « factures », de « produits »…) Deuxièmement, ils étaient mal documentés, vraiment très mal documentés. Troisièmement, ils faisaient l’objet d’une lutte sans relâche : les équipes techniques refusaient de porter la connaissance fonctionnelle de ces outils, et les équipes fonctionnelles refusaient d’admettre que les équipes techniques ne connaissaient pas leurs règles de gestion.

Les problèmes de cette entreprise étaient aussi épineux que désespérément ordinaires.

Aujourd’hui, notre invité Rémi Le Brouster est avec nous pour parler d’une solution, nommée ODASE, visant à résoudre les problèmes de cette entreprise.

Hightest : Bonjour Rémi ! Tu es directeur technique adjoint de la solution ODASE, et tu étais précédemment développeur. Au cours de ta carrière, as-tu déjà été impliqué au sein d’une entreprise comme celle dont on parlait à l’instant ?

Rémi Le Brouster : Bonjour Hightest ! Ca m’est en effet arrivé, et c’est aussi pour cela que je me suis beaucoup investi pour rejoindre ODASE. J’ai été dans une entreprise très orientée métier, avec une problématique de migration d’un ancien logiciel vers un nouveau, où il fallait donc recouvrer et réimplémenter les règles de gestion. L’ancienne application datant, les spécialistes des différentes parties du métier n’étaient plus tous là, et ceux qui les avaient remplacés étaient parfois contraints de nous répondre de refaire pareil, faute de documentation métier suffisante, ce qui impliquait de fouiller dans le code…

Cela était d’autant plus déroutant que la fiabilité de l’ancien logiciel était contestée, donc il fallait avancer en marchant sur des œufs.

Et évidemment, en voulant réimplémenter les comportements métiers, qu’ils soient historiquement bien réalisés ou fautifs, les développeurs introduisaient aussi de nouveau bugs, ce qui est le lot de presque tout développement.

Je pense également que ce genre de problématiques arrive dans beaucoup d’entreprises, mais avec le chef de service informatique / responsable R&D qui fait le tampon entre le métier et les développeurs, ce qui invisibilise le problème pour ces derniers.

H : Quel est l’objectif d’ODASE ?

RLB : L’objectif d’ODASE est de séparer intégralement le métier de la technique. Le métier doit être garant de la partie métier, tout comme les développeurs doivent se concentrer sur le code et ses problématiques techniques. Pour cela, il faut un outil capable de faire la passerelle entre les deux, se basant donc sur la documentation métier, et qui soit interrogeable via des applications, en leur retournant les résultats calculés souhaités. Cela permet aussi que cette documentation métier soit nécessairement à jour et en phase avec les applications.

Habituellement, dans les systèmes d’information :

• Les spécifications métier peuvent être éparpillées, redondantes, incomplètes, incorrectes, ambiguës.
• Le nombre de lignes de code peut être très important.
• Les changements dus au métier affectent toute l’implémentation.
• Ces changements métiers sont rarement bien documentés, bien qu’ils devraient l’être.
• Le debugging porte tant sur la technique que sur le métier puisque les experts métier n’ont pu intervenir en amont de l’implémentation.

Mettons qu’un SI ait un client lourd et une appli web, voici à quoi cela ressemble classiquement :

Il est courant de trouver des spécifications métier redondantes voire contradictoires les unes envers les autres. Chacune vit sa vie.

Avec ODASE, un certain nombre de choses changent.

• Le métier et la technique sont clairement séparés.
• Le métier est défini en un point unique (l’ontologie et les règles associées).
• L’ontologie est validée en amont avec les experts métier grâce aux explications.
• Il ne peut pas y avoir de contradictions entre le métier et l’implémentation technique.
• Le nombre de lignes de code est très réduit (il ne couvre que la technique).
• Les changements métier ne portent que sur l’ontologie.
• L’ontologie est une documentation de la vérité métier, toujours à jour.
• Les tests de type informatique ne portent que sur la technique.

On se retrouve donc avec une configuration comme suit :

ODASE permet de centraliser les modèles métiers et devient une source de vérité fiable.

H : Comment fonctionne ODASE ?

RLB : Notre fonctionnement est qu’un·e ontologue se charge de la modélisation du métier sous forme d’ontologies, et idéalement cela se fait en interaction forte avec un·e ou plusieurs spécialiste·s métiers, qui formulent le fonctionnement métier, et valident au fur et à mesure l’expression ontologique du métier. L’ontologue s’appuie aussi généralement sur de la documentation, et parfois même du code.

L’ontologie se découpe principalement en une représentation des concepts, de leurs attributs et de leurs liens entre eux, et en une spécifications des règles métiers qui définissent l’interaction entre ces différents éléments. Ces règles métiers sont des propositions logiques, ce qui signifient qu’elles sont tout le temps vraies, et qu’il n’y a aucune notion d’ordre entre elles.

Description de concepts d’une ontologie simple de démonstration. Dans cet exemple, il s’agit d’une application de location d’œuvre d’art. On voit que pour un contrat de location, on a plusieurs propriétés : une durée de location, un un prix total, un locataire…
 
Fichier contenant les règles métiers de l’ontologie. On voit ici que chaque règle de ce ficher est exprimée sous forme de conditions : si ceci, alors cela. Par exemple, on voit que si l’artiste est décédé, alors le contrat de location d’œuvre d’art comprend un supplément (afin de promouvoir les artistes vivants).
Afin de valider ces règles métiers, on peut implémenter des cas de tests, et vérifier les résultats. On peut également enregistrer les résultats des différents cas de test, afin que l’outil indique les changements lors d’exécutions futures.
Détection du changement d’un résultat de test
Détail du changement d’un résultat de test.

H : Pour parler en langage de testeur, ODASE permet de réaliser une analyse statique automatisée du référentiel métier… C’est top ! 

RLB : Notre outil permet également l’explicabilité de ces résultats, pour savoir par exemple pourquoi on obtient ce prix, ou pourquoi telle promotion ne s’est pas appliquée.
Explication du montant de 6€ de la réduction pour jeune locataire.

On obtient ainsi une représentation du métier spécifique, compréhensible et validée par le métier, que l’on peut faire évoluer facilement.

H : Mettons qu’ODASE soit installé dans une entreprise où travaillent des testeurs. Quels sont les changements à prévoir dans le quotidien de ces testeurs ? Quelle interaction avec ODASE prévoyez-vous ?

RLB : Tout dépend du contexte. Par exemple, si les testeurs ont une bonne connaissance métier, il peut être pertinent pour l’ontologue d’échanger avec eux, pour essayer d’en extraire de la connaissance métier, en complément des autres sources disponibles.

Dans ce contexte de bonne connaissance métier des testeurs, ou s’il y a une application legacy, ils peuvent aussi spécifier des cas de tests, et les résultats attendus. Cela permettra de valider que le métier est bien couvert, et de garder un œil sur des cas particulièrement complexes, stratégiques, ou historiquement problématiques, en vérifiant l’impact des évolutions sur le résultat des tests.

Les testeurs peuvent également valider, dans les applications techniques, que les résultats obtenus sont les bons. En effet, même si le métier est juste, si les applications qui interrogent ODASE ne fournissent pas les bonnes informations, c’est-à-dire s’ils envoient une mauvaise valeur ou omettent une variable nécessaire dans la construction du JSON de la requête envoyée (dans le cas d’une architecture client/serveur), le résultat sera erroné. Dans cette continuité, les testeurs peuvent également porter leur attention sur l’évolution de l’API, par exemple suite à l’évolution des informations nécessaires d’un point de vue métier, pour tester que ces évolutions ont bien été prises en compte techniquement dans les applications.

H : Quels types de profils deviennent ontologue ?

RLB : Il s’agit en général de docteur·e·s en informatique spécialisé·e·s dans la représentation des connaissances.

H : L’approche d’ODASE rappelle celle du BDD (behavior driven development). Comment se situe ODASE vis-à-vis des outils de BDD ?

RLB : Notre approche étant basée sur des propositions logiques toujours vraies, elle est fondamentalement orientée état. Ainsi, il n’y a pas du tout la notion de « When » des scénarios « Given … When … Then … ». Un état partiel est transmis à ODASE, et ODASE complète le reste. Le comportement, lui, est implémenté au niveau de l’applicatif, de façon technique.

De même, nous cherchons à représenter la réalité métier, de façon indépendante des fonctionnements attendus. Ainsi, ce ne sont pas des tests à passer, ni une volonté stratégique, commerciale ou produit quelconque qui vont régir l’ontologie. La réalisation de l’ontologie est avant tout une quête de la plus pure réalité métier. Les choix ontologiques sont uniquement faits en ce sens. Par contre, on peut s’adapter pour modéliser une partie de cette réalité métier avant une autre.

H : Merci Rémi pour ton temps et tes explications !

Retrouvez l’intégration d’ODASE dans le quotidien des équipes techniques dans la deuxième partie de cet article !

Découvrir ODASE, partie II : intégrer les ontologies dans le SI

 

PS : Si vous souhaitez en savoir plus, voici l’adresse d’ODASE : info@odase.io

7 signes que vous faites de la sur-qualité, et comment vous en sortir

Posted on | by hightest | Leave a Comment on 7 signes que vous faites de la sur-qualité, et comment vous en sortir

La sur-qualité est l’ennemie sournoise de la qualité ; elle se déguise pour lui ressembler, mais ne manque pas de nuire aux projets dans lesquels elle s’invite. Voici quelques signes qui vous permettront de l’identifier dans vos pratiques et dans celles de vos équipes !

Dans son acception la plus simple, la sur-qualité consiste à allouer à la qualité des moyens supérieurs aux besoins réels.

Dans cet article, nous montrerons que la sur-qualité peut également provenir d’une mauvaise gestion de moyens alloués à la qualité, même si ces moyens sont originellement bien dimensionnés.

Afin d’illustrer des comportements extrêmes à éviter, les traits sont volontairement un peu forcés ! 🙂

Signe 1 : Vous rejouez toujours tous les tests de régression

Contexte : vous avez passé du temps à écrire un test d’importance moyenne à faible en 2020 à l’occasion de l’implémentation d’une nouvelle fonctionnalité. Aucune anomalie n’a été détectée en exécutant ce test. La fonctionnalité s’est avérée très stable au fil du temps.

Ce test s’est pourtant retrouvé rejoué VINGT-HUIT FOIS, à l’occasion de chacune des campagnes de test qui ont eu lieu depuis.

Vingt-huit fois.

Pourquoi ?

Par habitude ? Parce que vous avez décidé, ou bien votre entreprise a décidé, que la qualité était une priorité, et que dans cette mesure il fallait rejouer à chaque campagne l’ensemble des tests de régression ?

Des leviers plus forts que vous sont certainement en jeu (biais cognitifs, management, etc), mais c’est contre-productif. Au mieux, cela dépense silencieusement un budget énorme qui avait été prévu à cet endroit. Au pire, cela contribue à construire une mauvaise réputation des activités de test. Ainsi pourrez-vous entendre les discours suivants :

  • « Les tests, ça coûte cher »
  • « Les recettes sont de plus en plus longues et créent un goulet d’étranglement »
  • « On fait de plus en plus de tests mais on ne trouve pas de plus en plus de bugs »
  • « Les testeurs doivent s’ennuyer, ils font toujours la même chose ».

Comment éviter ça ?

Le meilleur moyen d’éviter cet écueil est de prendre le temps de revoir sa stratégie de test, et de trouver un équilibre entre rapidité et couverture de test.

Signe 2 : Vous conservez tous les cas de tests écrits depuis le début du projet

« Ce cas de test a bien été écrit pour une raison… »

C’est le seul motif que vous avez pour conserver ce cas de test, et le rejouer respectueusement campagne après campagne.

La personne qui l’a écrit est partie depuis des mois, d’autres tests ont été écrits depuis qui couvrent peut-être encore mieux cette partie, mais dans votre esprit, il est hors de question de supprimer ce cas de test.

Or, un référentiel de tests en bonne santé est comme un serpent ; il grandit certes, mais lentement, et se débarrasse régulièrement de sa peau morte. Comme l’indique avec humour le wiki Fan de Test, conserver, par principe, la totalité des tests écrits depuis le début du projet, relève de la syllogomanie.

Comment éviter ça ?

Effectuer régulièrement une revue des tests, pour éventuellement en supprimer ou en fusionner, est une bonne pratique. Il y a de quoi hésiter avant de supprimer un cas de test, mais si vous utilisez un outil de gestion des tests qui intègre une gestion des versions, cela devient beaucoup moins intimidant.

Signe 3 : La combinatoire vous contrôle plus que vous ne la contrôlez

Vous voulez tester toutes les configurations, TOUTES.

Un produit peut être de 10 couleurs différentes et de 5 tailles différentes ? Boum, vous prévoyez 50 tests pour vérifier que ce produit s’affiche correctement dans le panier quelle que soit sa couleur et sa taille.

Vous souhaitez que le site web fonctionne correctement sur les 3 navigateurs les plus utilisés du marché ? Allez : 50 tests multipliés par 3, 150 tests.

Et ainsi de suite.

C’est une caricature évidemment, mais pourrait-elle être votre caricature ?

Comment éviter ça ?

Découvrez des techniques, par exemple Pairwise, qui vous permettront de réduire le nombre de jeux de données tout en conservant une couverture satisfaisante.

Et pour éviter le paradoxe du pesticide, changez de temps à autre les jeux de données !

Il est important également de voir les cas d’utilisation au-delà de la combinatoire. S’il est possible, dans un formulaire d’inscription, de saisir un pays de résidence et une devise préférée, il est important de proposer l’euro aux utilisateurs ayant choisi la France comme pays de résidence. Le dollar des Tuvalu (archipel de 11 000 habitants)… un peu moins. Inutile donc de fournir le même effort de test sur les deux cas !

Signe 4 : Vous avez des lubies

Un jour, vous avez trouvé un bug de sécurité sur un applicatif A, qui pouvait être reproduit en modifiant malicieusement le contenu de listes déroulantes. Vous avez donc mis en place des tests très poussés sur cette partie, ce qui s’est révélé parfaitement pertinent dans le contexte. Quel bonheur de faire une si belle moisson de bugs ! Quel génie !

Depuis, à chaque fois que vous vous retrouvez sur un nouveau projet, vous mettez en œuvre ce type de test. La sécurité des listes déroulantes est systématiquement testée de fond en comble. C’est votre dada. Et peu vous importe que cela prenne du temps, peu vous importe que les risques ne soient pas les mêmes ; ça a marché une fois, ça devrait marcher de nouveau !

Bref, il est facile d’oublier les 7 principes généraux du test logiciel, et un en particulier : « Les tests dépendent du contexte ».

Comment éviter ça ?

Votre expérience de testeur doit vous bonifier avec le temps, ouvrir vos perspectives et vous permettre de vous adapter à toujours plus de situations. Si vous pensez constamment à ce qui a fonctionné sur vos précédents projets, vous risquez de tomber dans la sur-qualité sur certaines parties anodines et d’utiliser le temps dédié aux tests à mauvais escient.

Le mieux est alors, à chaque fois que l’on intervient sur un nouveau projet de test, de s’efforcer à adopter un regard neuf. Presque comme si on voyait un logiciel pour la première fois… tout en capitalisant sur l’expérience passée. Un exercice d’équilibriste, mais qui en vaut la peine !

Signe 5 : La loi de Murphy est votre seule crédo

« Tout ce qui est susceptible d’aller mal ira mal. »

L’applicatif à tester est mis en production toutes les deux semaines ? Pas de problème : toutes les deux semaines, vous faites non seulement des tests sur des cas passants, sur des cas non-passants, mais aussi sur des scénarios abracadabrantesques. Toujours les mêmes, par sécurité, parce qu’on ne sait jamais.

Hé oui, car que se passerait-il en production si un utilisateur essayait de changer sa date de naissance de manière à indiquer qu’il est né après-demain, en passant par l’inspecteur parce que l’interface web ne permet pas cette manipulation ?

Quelle question brûlante, cela vaut vraiment la peine de faire ce test tous les 15 jours ! (Ironie)

Comment éviter ça ?

La loi de Murphy n’est pas dénuée de bon sens, mais la plupart du temps, il est important d’obtenir d’abord des informations sur ce qui est le plus probable d’arriver.

Pensez avant tout au besoin métier, recentrez-vous sur le cœur des exigences.

Dans la mesure du possible, collectez également des informations sur les utilisateurs finaux : quels sont leurs besoins les plus fréquents ? Quelles sont les fonctionnalités qu’ils utilisent le plus ? Quelles sont leurs habitudes de navigation ? Cela aide à redonner à la loi de Murphy sa juste place.

Signe 6 : Vous testez comme des fous mais il y a tout de même des bugs découverts en prod

Le temps passé à couper les cheveux en quatre, consciemment ou inconsciemment, sur des fonctionnalités triviales, représente un manque à gagner. C’est du temps confisqué aux questions essentielles, celles qui s’intéressent à ce qui pourrait vraiment mal tourner.

La sur-qualité sur certaines parties n’empêche donc en rien… la sous-qualité sur d’autres !

Comment éviter ça ?

Prendre conscience du décalage entre l’important effort de test fourni, et les résultats infructueux, est la première étape. Cela permet ensuite de marquer une pause pour revoir la stratégie. L’étape suivante : recentrer les activités de test autour des fonctionnalités les plus fragiles, celles qui regroupent le plus de défauts (pensez Pareto !)

Signe 7 : Ajouter davantage de tests ne réussit pas au projet

« Les tests, c’est comme le fromage : plus il y en a et meilleur c’est ! »

Oui… mais dans les mêmes limites !

Ne niez pas : vous ne voudriez pas d’une pizza recouverte d’une couche de 4 centimètres de fromage. (Si ? Bon ok, mais à ce moment-là on a de très bons cardiologues à vous conseiller.)

Il existe de même un seuil à partir duquel ajouter des tests ne réussit plus au projet, au contraire.

Jusqu’à un certain point, augmenter les moyens alloués aux tests est bénéfique au projet : les anomalies sont trouvées plus tôt, et leur coût de correction est donc moindre.

Au-delà d’un certain point, les tests continuent de déceler des anomalies, mais plus suffisamment pour assurer le ROI de cette activité.

Comment éviter ça ?

Observez comment se déroulent vos campagnes de test.

Mettons qu’une campagne se déroule sur 4 jours ; si très peu d’anomalies majeures sont découvertes pendant les trois premiers jours, qu’aucune n’est découverte lors du quatrième, et que la nouvelle version ne révèle aucune nouvelle anomalie une fois en production, interrogez-vous collectivement : serait-il possible la prochaine fois de réduire le temps alloué à la campagne de tests ?

Ce temps gagné pourrait être utilisé autrement : en effectuant des revues de spécifications, en automatisant davantage de tests, en optimisant l’outil de gestion des tests…

Résultat : au fil de l’eau, les tests permettent de livrer de plus en plus vite en production, et deviennent un facteur visible de succès.

En conclusion

La surqualité est l’ennemie de la qualité, mais aussi de l’image que vos interlocuteurs se font des activités de test. Pire encore, elle cohabite volontiers avec la sous-qualité.

Elle met en péril l’efficience (faire bien les choses), et parfois aussi l’efficacité (faire les bonnes choses), des tests. Heureusement, des solutions existent !

Et vous, quels signaux utilisez-vous pour déceler la sur-qualité au sein de vos projets ?