hightest, auteur/autrice sur Hightest

Tests non fonctionnels : quelques ressources pour vous lancer

Posted on 11 mai 2022 | by hightest | Leave a Comment

« Les compères dans leur Fiat font sécher leurs mains en utilisant les portes. »

Qu’est-ce que c’est ? Une formule magique ? Une chaîne aléatoire générée par une IA ? Un extrait de chanson absurde ?

Rien de tout ça : c’est notre moyen mnémotechnique pour se souvenir des 8 aspects de la qualité logicielle définis par ISO 25010 !

Les com(patibilité)per(formance)es dans leur Fia(bilité)t fon(ctionnalité)t sec(urité)her leurs main(tenabilité)s en utilisa(bilité)nt les port(abilité)es.

Compatibilité, Performance, Fiabilité, Fonctionnalité, Sécurité, Maintenabilité, Utilisabilité, Portabilité.

Ces 8 aspects sont tous importants, mais l’un d’entre eux est comme un arbre qui cache la forêt : l’aspect fonctionnel. Eh oui : quand un produit numérique est créé, on veut avant tout savoir “s’il fonctionne” !

Toutefois, il est important d’avoir en tête les 7 autres aspects, qui se focalisent sur comment le produit fonctionne : rapidement, joliment, sécuritairement, compréhensiblement, simplement…

Cet article donne quelques clés pour comprendre ces types de test avant de vous lancer. Les ressources partagées sont issues de nos propres travaux ainsi que d’autres ressources francophones, pertinentes et faisant autorité dans le domaine de la qualité logicielle. Nous étofferons avec plaisir cette liste avec vos suggestions, alors n’hésitez pas à nous en partager.

Bonne lecture !

Compatibilité

Portrait robot du problème de compatibilité

L’applicatif fonctionne bien sur la machine du développeur (héhé !) mais rencontre des problèmes dès qu’il se trouve sur le même environnement qu’un autre logiciel du système d’information ? Il a du mal à communiquer avec d’autres systèmes dont il dépend ? Il présente certainement un problème de compatibilité !

A quoi ressemblent des tests de compatibilité ?

Bien souvent, les problèmes de compatibilité sont découverts “par hasard”, ou plutôt “par nécessité”, quand l’applicatif est installé dans son environnement cible. Mais en fonction du produit (notamment ceux nécessitant une installation locale chez chaque client), il peut être nécessaire de procéder à des tests systématiques. Cela consiste à imaginer différentes configurations que pourrait rencontrer l’applicatif, et vérifier si chacune d’elle permet un comportement nominal de celui-ci. Des tests de portabilité sont alors souvent également nécessaires (voir la section dédiée).

Pour aller plus loin :

Comprendre les enjeux liés à la compatibilité : Article sur la Taverne du testeur

Fiabilité

Problèmes de fiabilité : kézako ?

Les utilisateurs ne font pas confiance à l’applicatif ? Il plante à chaque fois qu’on saisit une valeur qu’il n’attend pas ? Il est régulièrement indisponible ? Il est incapable de se rétablir après avoir “crashé” suite à une forte affluence ? Il y a certainement un problème de fiabilité !

Comment tester la fiabilité ?

La fiabilité donne lieu à des tests de diverses natures.

Certains tests visent à mettre l’applicatif et son environnement en difficulté (coupure réseau, indisponibilité d’une ressource tierce…) afin de vérifier l’adéquation de son comportement et sa capacité de récupération.

Des dispositifs de monitoring peuvent également être mis en œuvre afin de vérifier la disponibilité de l’applicatif au fil du temps.

Pour aller plus loin :

Comprendre les enjeux liés à la fiabilité : Article sur la Taverne du testeur

Performance

La performance, qu’est-ce que c’est ?

L’applicatif est trop lent ? Il ne tient pas plus de 15 utilisateurs simultanés ? Il y a certainement un problème de performance !

La performance regroupe un certain nombre de termes utilisés au quotidien au sein des DSI : charge, robustesse, stress, rendement…

Pourtant, chaque terme a une signification différente et peut mener à des types de test différents.

Vous vous perdez dans la sémantique ? Pas de panique, faites un petit tour par cet article de désambiguïsation qui vous permettra d’y voir plus clair grâce aux définitions de l’ISTQB !

Quels types de tests pouvez-vous réaliser ?

Les tests les plus courants pour cet aspect de la qualité sont les “tirs de charge”, qui consistent à simuler l’utilisation de l’applicatif par un certain nombre de personnes. Le type d’utilisation peut être spécifié, et des rapports sont générés de façon à comprendre quelles ressources sont les plus susceptibles de créer des lenteurs voire des indisponibilités en production.

Quelques outils connus : JMeter, Neoload, Gatling.

Pour aller plus loin :

Comprendre les tests de performance : Article sur la Taverne du testeur
Cas pratique de tests de performance (dans le monde de l’audiovisuel) : Article ici
Tutoriel : chronométrer vos étapes de test fonctionnel au sein d’un projet d’automatisation développé en Java.
Tutoriel : ajouter des tests JMeter à un job Jenkins dans une approche d’intégration continue.

Sécurité

Bugs de sécurité : des bugs pas comme les autres ?

Les bugs de sécurité, aussi appelés “failles”, ont une place un peu à part dans l’inconscient collectif, car ils mettent en jeu non seulement l’applicatif, son environnement et ses utilisateurs, mais aussi des acteurs bien spécifiques, communément désignés sous le noms de hackers, pirates ou utilisateurs malveillants !

Ces anomalies peuvent être de natures très différentes. On distingue communément les défauts présents dans l’applicatif (on parle tout simplement de “sécurité applicative”), et ceux qui concernent son environnement ou son réseau.

Techniques de tests de sécurité

Parmi les techniques spécifiques les plus courantes pour effectuer des tests de sécurité, on compte le pentest ou penetration testing (des tests souvent outillés qui consistent à s’introduire dans un système) et les scans de vulnérabilité, qui comparent un existant avec une bibliothèque de failles connues et plus ou moins communes. Tandis que les pentests nécessitent souvent des connaissances assez poussées, il est possible de mettre en œuvre rapidement et à peu de frais des scans de vulnérabilité. Toutefois, l’un ne remplace pas l’autre.

Des tests de sécurité peuvent être facilement mis en œuvre lors de la conception de tests d’API ; il suffit alors d’imaginer des scénarios “interdits” (exemple : essayer de changer le prix d’un article en utilisant l’API en étant connecté en tant que simple client !)

Pour aller plus loin :

Comprendre les tests de sécurité : Article sur la Taverne du testeur
Les “hacktivities” : des cours en ligne pour se former aux tests de sécurité
Il existe des outils simples permettant d’obtenir de premiers retours sur cet aspect. Nous en avons listé quelques-uns dans cet article.

Maintenabilité

Repérer les problèmes de maintenabilité

L’applicatif connaît de nombreuses régressions ? L’intégration de nouveaux développeurs se fait lentement et dans la douleur ? Les devs historiques rechignent à retourner sur le projet ? Ca sent la problématique de maintenabilité !

Comment gérer les défauts de maintenabilité ?

La qualité de code est étroitement liée à cet aspect de la qualité logicielle ; toutefois, ce n’est pas parce que la qualité de code est essentiellement une responsabilité des développeurs, que les testeurs n’ont pas de rôle à jouer pour faciliter la consolidation de la maintenabilité.

Les outils de qualimétrie peuvent être des alliés dans la détections de problèmes de maintenabilité. SonarQube par exemple détecte 3 types de problèmes de code : les bugs, les vulnérabilités et les “code smells”. Cette troisième catégorie permet de détecter des aspects qui trahissent un manque de maintenabilité au sein du code.

Un travail collaboratif de définition de bonnes pratiques de développement est également un investissement très intéressant pour la qualité à long terme du produit. Cela peut prendre la forme de revues de code classiques (simple et efficace !), mais cela peut aussi être outillé avec des solutions telles que Promyze.

Pour aller plus loin :

Comprendre la maintenabilité : Article sur la Taverne du testeur
Un article qui donne des clés pour mettre en œuvre SonarQube au sein d’une organisation
Davantage sur la solution Promyze : questions au créateur de cette solution

Utilisabilité

Le spectre des problèmes d’utilisabilité

L’utilisabilité est un aspect passionnant de la qualité logicielle, qui s’intéresse avant tout à l’expérience subjective de l’utilisateur. Et “subjective” n’est pas un gros mot ! Cela signifie simplement qu’il est nécessaire ici de se positionner dans une situation spécifique. Celle, par exemple, d’une personne qui n’a pas forcément les mêmes informations que nous, le même vécu ou encore les mêmes caractéristiques physiques (dans le cas des tests d’accessibilité).

Comment obtenir des retours d’utilisabilités crédibles ?

Une des grandes difficultés qu’un testeur peut rencontrer au moment de rapporter un bug d’utilisabilité est le risque de se voir rétorquer “C’est subjectif” (sous-entendu “Cela n’est pas un bug, cela ne sera pas corrigé”). Il est donc important de s’appuyer sur des arguments solides et si possible soutenus par des ressources tierces (états de l’art, témoignages utilisateurs…)

Comme pour la portabilité (voir section suivante), le crowdtesting (ou test participatif) est en mesure d’apporter rapidement des informations qualifiées sur l’utilisabilité des applicatifs.

Pour aller plus loin :

Comprendre la maintenabilité : Article sur la Taverne du testeur
Quelques digressions sur le très controversé “bug d’UX”
Interview de Marie-Françoise Pierre, entrepreneuse malvoyante, qui nous a donné des éléments sur les rapports qu’il y avait entre son handicap et sa vie numérique.
Notre contribution au défi des 30 jours de tests d’accessibilité

Portabilité

Les signes de problèmes de portabilité

L’applicatif fonctionne bien sur Windows 10 mais pas sur MacOS ? Sur Chrome mais pas sur Firefox ? Le design est magnifique sur écran d’ordinateur mais horrible sur smartphone ? Quand on parle de portabilité, il s’agit exactement de ce type de problèmes !

Démarrer une démarche de tests de portabilité

L’ennemi n°1 de la portabilité, c’est… de ne pas faire de tests de portabilité. Certes !

L’ennemi n°2, c’est de se disperser.

En effet, la combinatoire des environnements (système d’exploitation, version d’OS, navigateur, taille d’écran…) empêche la plupart du temps de tout tester. La portabilité donne une belle illustration du principe général du test “Les tests exhaustifs sont impossibles” !

Pour asseoir une stratégie de tests de portabilité efficace, il est nécessaire de s’appuyer sur des chiffres. Quelles sont les configurations les plus plausibles dans notre cas ? Quels sont les 20 % de configurations (à la louche !) qui nous permettront d’être confiants sur 80 % des cas ?

Des outils de tracking des utilisateurs sont alors très utiles (par exemple, Google Analytics pour un site web permet de connaître quelques éléments sur les habitudes de navigation des utilisateurs).

Une fois cet état des lieux réalisé, c’est le moment de se lancer. Plusieurs possibilités peuvent alors être envisagées :

Avoir recours à des fermes de devices ou de navigateurs (des services en ligne qui mettent à disposition des environnements dédiés à ce type de tests)
Investir dans de nombreux devices de test (c’est beaucoup plus onéreux ; la plupart du temps nous déconseillons cette pratique)
Faire appel à des crowdtesteurs. L’avantage ici étant que les retours ne concerneront pas seulement la portabilité, mais aussi d’autres aspects de la qualité logicielle.

Pour aller plus loin :

Comprendre les enjeux liés à la compatibilité : Article sur la Taverne du testeur
Nous avons testé pour vous deux services cloud permettant de mettre en œuvre des tests de portabilité : pCloudy et BrowserStack.
L’extension Lighthouse de Chrome permet de passer en revue des aspects tels que la performance, la portabilité et l’accessibilité.
La portabilité et la compatibilité sont souvent étroitement liées, car elles s’intéressent toutes deux à la variété des configurations logicielles et matérielles dans lesquelles l’applicatif va être utilisé. Toutefois, ce sont deux notions à distinguer. Voici donc un paragraphe (en anglais) sur la différence entre compatibilité et portabilité.

Par où commencer ?

Eh oui, cela fait beaucoup d’infos !

Connaître les 8 aspects de la qualité logicielle est un bon début. Pour la suite, nous vous conseillons ces étapes pour faire de vous un cador des tests non-fonctionnels :

Faire connaître ces 8 aspects à votre équipe (en partageant cet article par exemple !)
Discuter collégialement des différentes facettes de la qualité vis-à-vis des applicatifs que vous testez au quotidien
Identifier les tests non fonctionnels prioritaires pour chaque applicatif
Vous former et mettre en œuvre ces tests au sein de votre stratégie globale !

Tout cela étant dit, nous vous souhaitons bon courage dans votre périple ! Si vous avez des questions ou besoin d’aide, nous vous conseillons de poster un message sur le groupe LinkedIn francophone très réactif Le métier du test. Au plaisir de vous y retrouver !

Bon courage dans votre exploration et souvenez-vous que le test regorge toujours d’occasions d’apprendre !

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

Posted on 31 mars 2022 | by hightest | Leave a Comment

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 25 mars 2022 | by hightest | Leave a Comment

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 :

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 :

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 4 mars 2022 | by hightest | Leave a Comment

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 ?

[VIDEO] Un bug d’UX est-il un bug ?

Posted on 20 janvier 2022 | by hightest | Leave a Comment

Un bug, c’est « toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. » (Glossaire CFTL, ISTQB).
Si on se contente de lire la première partie de cette définition (jusqu’à « etc »), le positionnement général vis-à-vis du bug est tout à fait confortable puisque cela permet pour les testeurs de définir deux parties de leur activité assez clairement :

Vérifier que les exigences forment un ensemble cohérent
Tester si l’application est conforme à ces exigences

Par contre, pour la seconde partie, « les perceptions ou expériences de quelqu’un », c’est une autre histoire :

Qui est quelqu’un ?
Qu’est-ce qu’un bug d’UX ?
Quelles perceptions ? Quelles expériences ?
Quels biais entrent en jeu ?
Comment gérer ces bugs ?

Zoé vous apporte des réponses cette vidéo sur les Bugs d’expérience (UX).

Et vous alors, quels bug d’UX avez-vous pu trouver dernièrement ? Dans vos organisations, comment procédez-vous pour les trouver / corriger ?

8 choses essentielles à savoir pour tester un serveur d’autorisation

Posted on 21 décembre 2021 | by hightest | Leave a Comment

Que se passe-t-il vraiment lorsqu’on retire de l’argent à un distributeur de billets, quand on paie par carte bleue chez un commerçant ou qu’on réalise une transaction en ligne ? Le monde de la monétique est passionnant et donne lieu à son propre arsenal de tests. Aujourd’hui, Coralie Ipotesi, experte du domaine, vous donne un premier aperçu de ces problématiques ! Bonne lecture !

Imaginez-vous à l’autre bout du monde, en face d’un distributeur automatique qui refuse de vous délivrer des billets. Vous ressentez un état de solitude profonde, car sans ces billets vous ne pourrez pas payer le bouiboui qui vous sert d’hôtel (et qui évidemment n’accepte pas la carte bleue). Eh bien, vous êtes sans doute en train de faire l’expérience d’un serveur d’autorisation qui s’amuse à vous titiller. Pourquoi ? Les raisons peuvent être multiples :

dépassement de plafond à l’étranger,
absence d’autorisation d’utilisation de la carte dans tel pays,
problème sécuritaire,
décalage horaire mal calculé…

Bref, il y a une boîte noire située à plusieurs milliers de kilomètres qui, si elle est mal gérée, peut causer de gros dégâts. Attardons-nous un peu sur ce serveur pour mieux le connaître !

1) Le serveur d’autorisation agit dans l’ombre

Personne ne le connait, mais pourtant tout le monde l’utilise au quotidien. Le serveur d’autorisation est au cœur du monde de la monétique, et il est capable de traiter des millions de transactions quotidiennes.

Si un paiement refusé sur le terminal provoque toujours un état de panique chez l’acheteur, c’est souvent à tort qu’on s’en prend à la carte ou au terminal : c’est en réalité bien souvent le serveur d’autorisation qui a rendu son verdict dans l’ombre d’une salle obscure. Son but : s’assurer qu’autant l’acheteur que le commerçant sont en mesure d’honorer la transaction.

Le serveur d’autorisation est en fait un applicatif qui implémente un ensemble de règles de gestion permettant l’acceptation ou le refus d’une transaction par carte bancaire. L’ensemble des données échangées lors de cette transaction répond à un ou plusieurs protocoles de communication. Ces données peuvent être aussi bien des données sécuritaires de la carte que des informations liées au marchand, en passant par des données contextuelles relatives à l’achat et bien d’autres encore. Le serveur d’autorisation va s’appuyer sur cet ensemble de paramètres et sur le contexte client ou commerçant pour déterminer si la transaction peut avoir lieu.

2) Il existe 2 types de serveurs d’autor’

Une transaction bancaire se produit toujours entre un acheteur et un vendeur. C’est pourquoi il y a 2 types de serveurs d’autorisation qui entrent en jeu : un pour le porteur de la carte (le serveur d’autorisation émetteur, ou SAE) et un pour le commerçant (le serveur d’autorisation acquéreur, ou SAA). Chacun sa tâche, chacun ses vérifications avant de passer la main à l’autre. Là où l’un va s’attarder sur les règles métier, l’autre va surtout s’atteler à convertir des protocoles. Des approches de test complètement différentes pour un but commun : s’assurer de la complétude de la transaction. On vous explique tout ça un peu plus loin ! En attendant, voici le schéma de fonctionnement général pour un paiement par carte bleue sollicitant à la fois le SAE et le SAA :

3) Les serveurs d’autorisation s’appuient sur des réseaux bancaires

Les serveurs d’autor’ c’est bien, mais il faut bien que la transaction soit véhiculée de l’un à l’autre. C’est là que les réseaux bancaires entrent en jeu. On parle ici par exemple de VISA ou MasterCard, les plus connus, mais il existe en réalité une multitude d’autres réseaux bancaires, chaque pays ayant plus ou moins le sien : JCP pour le Japon, UPI pour la Chine, Diners ou American Express aux Etats Unis, ou plus proche de nous, le réseau CB en France. Dans le monde des serveurs d’autorisation, c’est ce que l’on appelle « le règlementaire ». Il faut en effet voir chaque réseau comme un chef d’orchestre, qui définit un protocole de communication auquel les serveurs d’autorisation vont devoir s’adapter pour utiliser le réseau. Par exemple, si un commerçant souhaite accepter les cartes Diners de ses clients, le serveur d’autorisation auprès duquel il a souscrit doit au préalable avoir signé un contrat avec Diners pour l’acquisition de ce flux. Cela implique une période de certification, qui permet au réseau de s’assurer que les données véhiculées sont conformes à son protocole. Une fois la certification acquise, le serveur d’autorisation est autorisé à traiter les cartes Diners.

Si la plupart des réseaux répondent à la norme ISO8583 qui définit la structure des messages pour des transactions financières par carte bancaire, d’autres, comme NEXO par exemple, ont adopté un format complètement différent (ISO 20022) qui, s’il vise à uniformiser les règles du paiement en Europe, oblige les acquéreurs à revoir complètement les règles de conversion avec les réseaux internationaux.

4) La sécurité avant tout

Le serveur d’autorisation, c’est aussi une myriade de cryptogrammes, clés et autres données sécuritaires qui vont garantir la fiabilité de la transaction. Tout un arsenal est mis en place notamment via la puce de la carte pour éviter toute forme de malveillance. Les tests sur ces aspects sécuritaires sont souvent complexes et chronophages, un paramètre important à prendre en compte en phase de test. En effet, si des outils existent pour décrypter les échanges entre la puce de la carte et le TPE, la complétude des tests sécuritaires ne peut souvent se faire qu’à l’aide de « cartes blanches ». Ces cartes de test vont reproduire l’environnement technique et sécuritaire de la carte finale sans en avoir le visuel ou l’embossage (oui, c’est comme ça qu’on appelle les petits reliefs sur une carte !). En reproduisant un environnement commerçant à l’aide de TPE de test, il sera alors possible de s’assurer que les paramètres sécuritaires des cartes sont correctement traités, par exemple que les clés échangées sont comprises par les deux parties et qu’elles ne provoqueront donc pas d’erreur lors des transactions.

Un autre aspect de la sécurité des paiements par carte bancaire passe par la mise en œuvre de la norme PCI DSS (Payment Card Industry Data Security Standard) qui vise à protéger les clients contre l’utilisation frauduleuse de leurs données. Celle-ci va fortement influencer les tests, car elle impose notamment que les données sensibles ne soient plus accessibles directement dans les systèmes mais fassent l’objet de cryptages. Cryptages qu’il va falloir être en mesure de reproduire sur les environnements de test tout en s’assurant que les données restent utilisables par les équipes de test.

5) Le serveur d’autorisation est un système temps réel

Le paiement d’une marchandise via un terminal ou un site internet interroge en direct les serveurs d’autorisation et délivre immédiatement l’autorisation. Qui pourrait imaginer en effet s’entendre dire par le commerçant : « Bon je saurai demain si votre paiement a été accepté, revenez à la même heure et je vous donnerai vos achats ! » Comme tout système fonctionnant en temps réel, cela implique un haut niveau de disponibilité de l’applicatif, qui ne peut jamais être au repos. C’est pour cela que ce type de logiciel est le plus souvent dupliqué afin d’éviter une panne générale en cas de pépin. Cependant, dans le cas où un système de backup est effectivement présent, il sera important de vérifier les processus de duplication des données en temps réel entre les différents sites, qui peut être source de bugs importants en cas de bascule. Par ailleurs, comme tout système temps réel, la supervision de la production va être primordiale afin d’assurer une qualité de service optimale.

6) Le serveur d’autorisation acquéreur est un super-traducteur

Vous l’aurez compris, le serveur d’autorisation peut être autant notre allié que notre pire ennemi lors d’un achat. Mais alors comment s’assurer qu’il prendra toujours des décisions mûrement réfléchies ?

Plaçons-nous d’abord du côté de l’acquéreur, c’est-à-dire la banque du commerçant. Le plus grand défi d’un serveur d’autorisation acquéreur va être de savoir jouer l’interprète. En effet, comme nous l’avons déjà évoqué, la transaction va devoir transiter par un réseau bancaire avant d’atteindre le serveur d’autorisation émetteur, mais le terminal de paiement ou TPE, lui, parle son propre langage. Il s’agit donc ici d’effectuer des conversions de protocole tout en gardant intacte l’essence du message transactionnel. Le monde de l’acquisition est de ce fait fortement dépendant des contraintes protocolaires imposées par les réseaux, et va devoir s’adapter en continu aux évolutions de ces derniers. Celle-ci font en effet l’objet de certifications indispensables et régulières de la part des réseaux : pas de certification, pas de flux transactionnel. Ces évolutions règlementaires peuvent survenir plusieurs fois par an dans certains cas et nécessitent donc une constante évolution des serveurs d’autorisations qui les implémentent, et donc un effort de test conséquent et régulier.

7) Le serveur d’autorisation émetteur respecte une collection de règles métiers

Regardons maintenant de plus près côté émetteur, c’est-à-dire la banque du porteur de carte. Contrairement à l’acquéreur, l’émetteur, lui, parle en général le langage du réseau auquel il est connecté. La dépendance protocolaire est donc moins complexe à prendre en compte, même s’il reste soumis aux évolutions règlementaires. En revanche, parce que les banques souhaitent fournir toujours plus de services à leurs clients, c’est au niveau des règles fonctionnelles qu’il va falloir concentrer l’effort de test. Une des causes de refus courantes sur un serveur d’autorisation est le dépassement des plafonds. La multitude des plafonds proposés, en montant, durée ou type de transaction peut en effet relever du défi en termes de tests. Ces dernières années, de nouveaux types de paiement ont également fait leur apparition, notamment le paiement mobile, qui ont nécessité la mise en place de nouvelles règles de gestion sur les serveurs d’autor’, et donc de nouveaux tests.

8) Des outils de tests spécifiques sont nécessaires

L’utilisation de simulateurs transactionnels disponibles sur le marché (par exemple Galitt ou FIS) est indispensable lors des tests d’un serveur d’autorisation, elle permet de générer des transactions en appliquant les règles protocolaires et sécuritaires spécifiques à un réseau et à un type de transaction donné. L’idée ici est de se substituer au réseau bancaire, soit d’un point de vue acquéreur, soit d’un point de vue émetteur, par exemple en paramétrant un type de transaction particulier (paiement sans contact, avec ou sans code PIN, paiement internet, etc.). Ces simulateurs sont notamment utilisés lors des phases de certification avec les réseaux, où ils permettent d’assurer la cohérence des données transmises, chaque réseau favorisant l’utilisation d’un simulateur préalablement certifié par ses soins.

S’agissant de systèmes fonctionnant en temps réel, les phases de tests de régression, nécessitant un pool de transactions significatif, seront également cruciales afin de s’assurer que la mise en production d’une nouvelle évolution ne bloquera pas les porteurs aux quatre coins du monde. Une approche courante est la création de templates déclinés par type de transaction et qui représenteront un ensemble significatif de cas métier. On peut par exemple imaginer que cet ensemble serait constitué de transactions de type paiement contact, sans contact, mobile, avec ou sans saisie du code pin, etc. Toutes ces caractéristiques vont influer sur les règles de gestion mises en œuvre sur les serveurs d’autorisation et sont donc indispensables à prendre en compte lors de tests de régression.

Conclusion

Comme vous l’aurez compris, même s’il n’est pas visible du grand public, le serveur d’autorisation est un élément particulièrement sensible de la chaîne du paiement électronique et nécessite donc une attention toute particulière pour le testeur. Que ce soit en phase de tests unitaires, d’intégration, d’acceptation ou lors de phases de certification ou de régression, il devra être capable d’anticiper les comportements des futurs utilisateurs afin de prévenir les défauts qui pourront avoir des conséquences pour l’acheteur (impossibilité d’obtenir sa marchandise ou ses billets) ou le commerçant (impossibilité de se faire payer). Une bonne connaissance des moyens de paiements et de leur spécificité sera alors un atout particulier pour le testeur, et lui permettra d’avoir une vision globale du système et de ces interactions pour en déceler au plus tôt les failles potentielles.

~ Coralie Ipotesi, ingénieure test applicatif chez Hightest

Si vous voulez aller plus loin dans la découverte de la monétique, nous vous conseillons de faire un tour sur ce blog.

Et si vous avez soif de découvrir d’autres univers de la qualité logicielle, nous vous conseillons notre notre saga des tests audiovisuels !

Intégrer les résultats de tests automatisés TestNG sur Xray

Posted on 18 novembre 2021 | by hightest | 2 commentaires

Vous gérez vos tests à l’aide de Xray, et vous avez des tests automatisés. Vous souhaitez que les résultats des tests automatisés remontent automatiquement dans Xray ? Vous êtes au bon endroit !

Avant de rentrer dans le vif du sujet, présentons rapidement l’outil Xray !

Xray est un plugin de test de Jira. Il permet de gérer la partie qualification d’un projet :

Planification de campagnes de tests
Création de cas de test avec possibilité de les lier à une User Story (exigence d’un produit)
Exécution des tests
Génération de rapports de tests

“Très bien ! Mais moi je veux suivre les résultats de mes tests automatisés via Xray !”, me direz-vous.

Eh bien, ça tombe bien ! Parce que c’est possible ! Et, cerise sur le gâteau, c’est justement l’objet de cet article !

A noter que Xray peut importer plusieurs types de format de résultats de tests. Ce tutoriel utilisera le framework TestNG. Si vous souhaitez utiliser un autre framework, la logique sera la même mais il faudra adapter les dépendances et la configuration du plugin maven-surefire en conséquence.

Ce tutoriel est un complément à la documentation technique de Xray (disponible ici)

Pré-requis

Avoir un compte Jira avec le plugin Xray (logique mais je le précise quand même 😉)
Avoir un compte git et savoir l’utiliser
Avoir une instance Jenkins disponible et utilisable
Avoir un test automatisé fonctionnel utilisant le framework TestNG et pouvant être exécuté par un système Linux (pour en savoir plus sur TestNG, c’est par ici)
Gérer le développement des tests automatisés avec Maven (pour en savoir plus, c’est ici)
Avoir le plugin maven-surefire présent dans le fichier pom.xml du projet de tests automatisés.

Pour information, l’IDE que j’utilise aujourd’hui pour créer ces tests automatisés est IntelliJ IDEA Community (disponible ici).

Nous pouvons maintenant attaquer les choses sérieuses !

Etapes de ce tutoriel

Etape n°1 : Modifications du fichier pom.xml
Etape n°2 : Modification du fichier testng.xml
Etape n°3 : Ajout des annotations Xray dans les tests automatisés
Etape n°4 : Configuration de Jenkins
Etape n°5 : Configuration du fichier Jenkinsfile
Etape n°6 : Lancement du job de Jenkins et vérification des résultats

Retrouvez toutes les étapes de ce tutoriel en vidéo et si vous préférez lire (et peut-être, avouez-le, utiliser la fonction copier-coller !), les étapes sont également détaillées ci-dessous !

Etape n°1 : Modifications du fichier pom.xml

Commençons par ouvrir le fichier “pom.xml” de notre projet :

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>exoauto</groupId>
    <artifactId>webdriver_java</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.0.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-chrome-driver</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-support</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>com.googlecode.json-simple</groupId>
            <artifactId>json-simple</artifactId>
            <version>1.1.1</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.0.0-M5</version>
                <configuration>
                    <testFailureIgnore>true</testFailureIgnore>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Afin de lui ajouter les dépendances nécessaires pour profiter de l’extension Xray de TestNG !

Qu’est ce que c’est que cette histoire “d’extension Xray” ?

C’est très simple, il s’agit de donner la possibilité à l’automaticien de test d’ajouter des annotations TestNG spécifiques à Xray. Cela permet de définir 3 types d’informations :

requirement : permet d’associer le test automatisé à l’exigence (User Story) que l’on souhaite,
test : permet d’associer le test automatisé à un test présent dans Xray,
labels : permet d’associer une étiquette (label) au test.

Ainsi, lors de la remontée des résultats des tests dans Xray, les différentes associations seront effectuées automatiquement ! Elle est pas belle la vie ?

Petite précision, il n’est pas obligatoire de mettre les 3 paramètres. Par exemple, si vous ne souhaitez pas associer d’étiquette, vous n’êtes pas obligés d’utiliser l’attribut “labels”.

Voici notre “pom.xml” avec l’ajout des dépendances Xray-TestNG :

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>exoauto</groupId>
    <artifactId>webdriver_java</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.0.0</version>
            <scope>test</scope>
        </dependency>
<!--===========================AJOUT DEPENDANCE XRAY-TESTNG============================================================--> 
        <dependency>
            <groupId>com.xpandit.xray</groupId>
            <artifactId>xray-testng-extensions</artifactId>
            <version>1.1.0</version>
            <scope>test</scope>
        </dependency>
<!--===================================================================================================================-->
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-chrome-driver</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-support</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>com.googlecode.json-simple</groupId>
            <artifactId>json-simple</artifactId>
            <version>1.1.1</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.0.0-M5</version>
                <configuration>
                    <testFailureIgnore>true</testFailureIgnore>
                </configuration>
            </plugin>
        </plugins>
    </build>
<!--===============================AJOUT REPOSITORY POUR XRAY=========================================-->
    <repositories>
        <repository>
            <id>xpandit</id>
            <name>xpand-releases</name>
            <url>http://maven.xpand-it.com/artifactory/releases</url>
            <releases>
                <enabled>true</enabled>
            </releases>
        </repository>
    </repositories>
<!--=================================================================================================-->
</project>

A la fin de ce fichier “pom.xml”, on peut constater l’ajout d’un “repository”. En effet, le “repository” par défaut est le “maven repository”, or ici la dépendance “com.xpandit.xray” ne se trouve pas dans le “maven repository” mais à l’url “http://maven.xpand-it.com/artifactory/releases« .

Configuration du plugin maven-surefire

Il faut maintenant configurer le plugin maven-surefire pour :

spécifier que l’on souhaite utiliser le fichier “testng.xml” (cf. https://testng.org/doc/documentation-main.html#testng-xml ) pour lancer le ou les tests,
prendre en compte les “attributes”, c’est à dire les paramètres requirement, test et labels lors de la génération du rapport des résultats (le fichier testng-results.xml)

Ce qui nous donne ceci :

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>exoauto</groupId>
    <artifactId>webdriver_java</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.0.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.xpandit.xray</groupId>
            <artifactId>xray-testng-extensions</artifactId>
            <version>1.1.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-chrome-driver</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-support</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>3.141.59</version>
        </dependency>
        <dependency>
            <groupId>com.googlecode.json-simple</groupId>
            <artifactId>json-simple</artifactId>
            <version>1.1.1</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.0.0-M5</version>
                <configuration>
                    <testFailureIgnore>true</testFailureIgnore>
<!--=============================== PARTIE AJOUTER DANS LA CONFIGURATION : =======================================================================================-->
                    <suiteXmlFiles>
                        <suiteXmlFile>testng.xml</suiteXmlFile>
                    </suiteXmlFiles>
                    <properties>
                        <property>
                            <name>reporter</name>
                            <value>org.testng.reporters.XMLReporter:generateTestResultAttributes=true,generateGroupsAttribute=true</value>
                        </property>
                    </properties>
<!--==============================================================================================================================================================-->
                </configuration>
            </plugin>
        </plugins>
    </build>
    <repositories>
        <repository>
            <id>xpandit</id>
            <name>xpand-releases</name>
            <url>http://maven.xpand-it.com/artifactory/releases</url>
            <releases>
                <enabled>true</enabled>
            </releases>
        </repository>
    </repositories>
</project>

Etape n°2 : Modification du fichier testng.xml

Lors du lancement des tests, il faut spécifier à TestNG que l’on souhaite utiliser et prendre en compte des annotations spécifiques (dans notre cas les annotations Xray). Il faut donc ajouter le “listener” de Xray qui se nomme “XrayListener” dans le fichier “testng.xml”.

Fichier “testng.xml” avec ajout de la partie “<listeners>” :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite thread-count="1" name="Surefire suite" verbose="0">
    <listeners>
        <listener class-name="com.xpandit.testng.annotations.XrayListener"></listener>
    </listeners>
    <test thread-count="1" name="Surefire test" verbose="0">
        <classes>
            <class name="com.projet.istqb.BaseTests"/>
            <class name="com.projet.istqb.TestCpc"/>
        </classes>
    </test> <!-- Surefire test -->
</suite> <!-- Surefire suite -->

N.B : pour avoir une petite astuce de génération du fichier “testng.xml”, vous pourrez vous référer à la vidéo tuto que nous allons partager sur ce sujet 😉

Etape n°3 : Ajout des annotations Xray dans les tests automatisés

Maintenant, ouvrons le code source de notre test automatisé TestNG, qui pour le moment ne contient que des annotations classiques de ce framework…

package com.projet.istqb;

import org.testng.annotations.Test;
import pages.AnswPage;
import pages.IstqbPage;
import pages.MailboxPage;
import pages.ToolboxPage;

import static org.testng.Assert.assertEquals;

/* Classe TestCpc :
 * Navigateur cible : Google Chrome.
 * Cette classe représente le test "Cent pout Cent" qui consiste à vérifier que le mail reçu, de la part de
 * "contact@hightest.nc", contient bien la phrase : "Vous avez bien répondu à 20 question(s) sur 20, soit 100 %
 * de réussite. Félicitations, vous avez obtenu le score maximal !". Cette phrase est écrite uniquement en cas de
 * résussite à 100 %.
 */
public class TestCpc extends BaseTests{
    private String expResult = "Vous avez bien répondu à 20 question(s) sur 20, soit 100 % de réussite. Félicitations, vous avez obtenu le score maximal !";
    private String email = "neoanderson@yopmail.com";

    /* Méthode testSucessfulCpc :
     * Cette méthode permet d'exécuter le cas de test avec le scénario suivant :
     * Etape 1 - Cliquer sur "Toolbox"
     * Etape 2 - Cliquer sur le lien vers le quiz ISTQB Fondation en français
     * Etape 3 - Cliquer sur les bonnes réponses du test
     * Etape 4 - Cliquer sur le bouton "Terminer!"
     * Etape 6 - Entrer une adresse e-mail yopmail.com (ne pas cocher la case pour la newsletter)
     * Etape 7 - Cliquer sur "OK"
     * Etape 8 - Ouvrir la page "www.yopmail.com"
     * Etape 9 - Vérifier que le mail reçu de la part de "contact@hightest.nc" indique bien la phrase attendue :
     * "Vous avez bien répondu à 20 question(s) sur 20, soit 100 % de réussite. Félicitations, vous avez obtenu
     *  le score maximal !".
     */
    @Test
    public void testSucessfulCpc(){
        ToolboxPage toolboxPage = homePage.clickToolboxLink();
        IstqbPage istqbPage = toolboxPage.clickLinkByHref();
        AnswPage answPage = istqbPage.clickRadio();
        MailboxPage mailboxPage = answPage.emailResult(email);
        String result = mailboxPage.getResult();
        assertEquals(result,expResult);
    }
}

… et ajoutons maintenant l’annotation Xray avec les informations que l’on souhaite :

// ne pas oublier d'ajouter tout en haut de la page : 
// import com.xpandit.testng.annotations.Xray;

    @Test
    @Xray(requirement = "HTUTO-34", test="HTUTO-35")
    public void testSucessfulCpc(){
        ToolboxPage toolboxPage = homePage.clickToolboxLink();
        IstqbPage istqbPage = toolboxPage.clickLinkByHref();
        AnswPage answPage = istqbPage.clickRadio();
        MailboxPage mailboxPage = answPage.emailResult(email);
        String result = mailboxPage.getResult();
        assertEquals(result,expResult);
    }
}

Ici le test automatisé sera associé à l’exigence dont la clé (identifiant dans Xray) = HTUTO-34 et au test dont la clé = HTUTO-35. Attention : le test présent dans Xray avec la clé HTUTO-35 est un test de type “Generic” car on souhaite identifier ce test comme un test automatisé.

Bien ! Notre test est prêt à être exécuté ! Alors faisons-le avec la commande suivante :

mvn surefire:test

Un rapport est généré dans le dossier “surefire-report” et devrait se nommer “testng-results.xml”.

Ouvrez ce fichier, vous devriez voir à l’intérieur un nœud nommé “attributes”. Si ce n’est pas le cas, c’est qu’il y a une erreur de configuration quelque part ! Faites bien attention aux versions des dépendances que vous utilisez (par exemple, la version TestNG 7.1.0 n’a pas fonctionné avec mon projet) !

Exemple de fichier “testng-results.xml” :

Une fois que vous avez vérifié que votre fichier “testng-results.xml” est correctement généré, vous pouvez passer à la configuration de Jenkins pour l’intégration continue des résultats des tests dans Xray.

Etape n°4 : Configuration de Jenkins

Connectez-vous sur votre instance Jenkins, cliquez sur “Administrer Jenkins” puis sur “Gestion des plugins”.

Cliquez sur l’onglet “Disponibles” et recherchez “Xray”. Vous devriez avoir parmi vos résultats le plugin “Xray – Test Management for Jira Plugin”. Installez-le et redémarrez Jenkins !

Cliquez sur “Administrer Jenkins” puis sur “Configurer le système” ; vous devriez voir maintenant une partie intitulée “Xray Configuration”.

Comment remplir “Xray Configuration” ?

Il faut d’abord demander à votre administrateur Jira préféré la génération d’une clé API. Si vous êtes l’administrateur, bravo, vous pouvez générer la clé API sans rien demander à personne 🙂 !

La génération d’une clé devrait vous fournir les paramètres suivants : Client ID et Client Secret.

Ces 2 paramètres sont à enregistrer dans la partie “Credentials”. Il suffit de cliquer sur “ajouter” et d’insérer la donnée Client ID dans le champ “Username” (Nom utilisateur, pas “ID”) et Client Secret dans le champ “Password”.

Vous devriez obtenir une “Configuration ID” qui sera à insérer dans le script du pipeline (cf. fichier “Jenkinsfile” présenté un peu plus loin).

Exemple de configuration :

Créez un job de type pipeline avec le nom que vous souhaitez (si le type “pipeline” n’est pas disponible parmi vos items, c’est qu’il manque un ou plusieurs plugins dans votre instance Jenkins !).

Comment configurer mon pipeline ?

Voici un exemple de configuration du pipeline :

Partie “Général” :

La case “Supprimer les anciens builds” est cochée : cela permet de demander à Jenkins de conserver un nombre limité de builds (à configurer à l’aide du champ “Nombre maximum de builds à conserver”).

Partie “Build Triggers” :

La case “Construire périodiquement” est cochée : cela permet d’exécuter le script du pipeline à une fréquence déterminée (vous pouvez cliquer sur le point d’interrogation de “Planning” pour en savoir plus).

Partie “Pipeline” :

Dans le champ “Repository URL” : insérez l’URL de votre dépôt git.

Dans le champ “Credentials” : cliquez sur “Ajouter” puis enregistrer le login et le mot de passe de votre utilisateur git.

Dans le champ “Branch Specifier” : insérer la branche où se trouve votre “Jenkinsfile” (master par défaut).

Dans le champ “Script Path” : insérer le chemin où se trouve le script du pipeline (nommé “Jenkinsfile”) dans votre répertoire git (en général on met le “Jenkinsfile” à la racine du projet)

Il ne reste plus qu’à cliquer sur “Apply” puis “Sauver” !

Voilà, votre job Jenkins est prêt pour l’action !

Mais… il ne manque pas quelque chose ? (Là, c’est le moment où on voit si vous avez suivi !)

Effectivement, nous avons spécifié à Jenkins où se trouve le script du pipeline mais nous ne l’avons pas encore créé !

Alors allons-y !

Etape n°5 : Configuration du fichier Jenkinsfile

Par défaut, le script de configuration du pipeline se nomme “Jenkinsfile”. Ce script va servir à exécuter un test automatisé puis envoyer les résultats à Xray.

Script Pipeline : Jenkinsfile

pipeline {
    agent any

    tools {
        // Installation Maven selon le nom donné dans la configuration globale de Jenkins
        maven "Maven"
    }

    stages {
        stage('Pre Build'){
            steps{
                sh "chmod +x driver/chromedriver"
            }
        }
        stage('Build') {
            steps {
                // Exécuter Maven (version pour un système Unix)
                sh "mvn -Dmaven.test.failure.ignore=true clean"
                sh "mvn install"
            }
        stage('Import results to Xray') {
            steps {
                step([$class: 'XrayImportBuilder', endpointName: '/testng', importFilePath: 'target/surefire-reports/testng-results.xml', importToSameExecution: 'true', projectKey: 'HTUTO', serverInstance: 'fd45sd-dq7856-dsdd5656ytz'])
            }
        }
        }
    }
}

Description de la partie “stages” :

“Pre Build” : sert à permettre l’exécution de “chromedriver” (version linux)
“Build” : sert à effacer les résultats des tests précédents, compiler et exécuter le test automatisé, ici « TestCpc »
“Import results to Xray” : sert à envoyer les résultats à Xray.

Etape n°6 : Lancement du job de Jenkins et vérification des résultats

Enfin ! Nous allons pouvoir constater le fruit de notre labeur 🙂 !

Il y a deux façons de faire : soit vous attendez que Jenkins lance un build automatiquement (puisque nous avons configuré un lancement périodique à l’étape n° 3), soit vous lancez le job manuellement en cliquant sur “lancer un Build”.

Une fois le Build lancé, cliquez sur “Console Output” du build en cours et vérifier qu’il n’y a pas eu d’échec d’exécution.

Ensuite, allez sur votre projet Xray pour vérifier que le résultat du test automatisé a bien été importé.

Exemple d’un résultat de test automatisé dans Xray :

Voilà ! Vous savez maintenant intégrer les résultats de vos tests automatisés de manière continue dans un projet Xray !

J’espère que ce tutoriel vous aura été utile 🙂 !

~ Jérôme Liron, ingénieur test applicatif chez Hightest

Le Data Driven Testing, l’approche reine pour un ROI immédiat !

Posted on 30 septembre 2021 | by hightest | Leave a Comment

« L’automatisation des tests, ça coûte cher ! »

Voilà une idée reçue qui freine bon nombre de personnes au moment de mettre en place une démarche d’automatisation des tests.

Il est vrai que les écueils existent, mais certaines démarches permettent de limiter ces risques et de mettre en œuvre, rapidement, des projets d’automatisation couronnés de succès. Dans cet article, nous allons présenter un moyen simple et efficace de maîtriser ces coûts… voire d’obtenir un ROI immédiat.

Le DDT, qu’est-ce que c’est ?

DDT est l’appellation courte de dichlorodiphényltrichloroéthane, mais nous ne parlons pas aujourd’hui de chimie et nous n’allons pas non plus vous suggérer de pulvériser de l’insecticides sur les bugs… car c’est aussi l’acronyme du Data Driven Testing !

Pourquoi implémenter le Data Driven Testing ?

Cette pratique présente au moins 3 avantages.

Le code est plus clair et plus concis. Finis les doublons, finies les données en dur !
L’ensemble des parties prenantes peut consulter et modifier les données sans avoir à lire le code. Cela rend ainsi plus accessible le sujet d’automatisation des tests aux personnes qui ne savent pas ou ne souhaitent pas développer.
Et surtout… Ça permet de gagner beaucoup de temps.

Dans quel contexte mettre en œuvre cette pratique ?

Dans notre article précédent, nous donnions des axes de réflexion pour choisir quels tests automatiser. L’un des axes consiste à déterminer quels tests sont les plus répétitititititi…tifs. Vous voyez l’idée : vous avez un unique formulaire, des centaines de manières différentes de le remplir, et une ribambelle de champs à vérifier en sortie. Réaliser ces tests des heures d’affilée peut relever du supplice intellectuel, et les déléguer à quelqu’un d’autre n’est pas beaucoup plus sympathique.

Dans ce contexte, le Data Driven Testing est tout particulièrement pertinent.

Génial ! Par quoi commencer ?

Quitte à faire une lapalissade, rappelons que le Data Driven Testing est… piloté par les données. Alors le mieux pour commencer, c’est de lister les jeux de données des tests que l’on va vouloir automatiser.

(Et si vous ne savez pas quels cas de test automatiser, nous vous suggérons de jeter un œil à cet article !)

Prenons un exemple simple : un cas de test dont l’objectif soit de vérifier qu’un champ de recherche fonctionne bien. Dans ce contexte, on peut créer un tableur, par exemple au format CSV, contenant ces 12 requêtes et leur résultat attendu.

Voici le contenu du fichier de jeux de données (qu’on appellera, pour la suite, requetes.csv) :

requete	nb_resultats_attendus
Sandra Geffroid	1
Sandra	2
Sandra Géffroid	1
Sandr	2
Sandr Geffr	1
Sandro Geffroid	1
Sandro Geffroio	0
Sandrawa Geffroidwa	0
SANDRA GEFFROID	1
sandra geffroid	1
s a n d r a g e f f r o i d	10
S_a_n_d_r_a_G_e_f_f_r_o_i_d	0

Ce fichier peut être rempli par les testeurs, les acteurs métiers, le PO, ou toute partie prenante souhaitant s’impliquer dans les tests. L’avantage du format tableur, c’est qu’il permet de collaborer en toute simplicité. On est bien loin de l’image intimidante d’une automatisation des tests « trop technique », inaccessible à la majorité de l’équipe projet !

Maintenant, à quoi ressemble le script ?

Nous avons listé 12 requêtes à vérifier dans le fichier dont on parlait précédemment. Il suffit maintenant de déclarer ce fichier comme source de données pour le test automatisé.

Voici un exemple sur JUnit 5, qui utilise l’annotation @ParameterizedTest :

@CsvFileSource(files = "src/test/resources/requetes.csv")
@ParameterizedTest
public void recherche_simple(String requete, int nb_resultats_attendus){
    lancerRecherche(requete);
    verifierNbResultatsAttendus(nb_resultats_attendus);
}

12 tests en un… c’est merveilleux, non ? 🙂

10, 100, 1000 cas de test… quelle est la limite ?

L’enfer est pavé de bonnes intentions

Vous l’aurez compris, avec le DDT, le coût de développement sera le même pour 10, 100 ou 1000 jeux de données. Dans cette mesure, il peut être séduisant de lancer l’automate sur le plus de cas possible.

Nous avons développé le test en 1 heure, il va jouer 1000 tests qui durent chacun 1 minute, nous aurons donc forcément atteint notre ROI au bout de la première exécution du 61^ème test ! C’est vertigineux !

Halte là ! Une belle peau de banane vient de se mettre dans votre chemin : l’envie (consciente ou non) de prouver le ROI à tout prix.

Dans l’exemple précédent, nous vérifions que la requête « Sandrawa Geffroidwa » ne remonte aucun résultat. Il serait possible, au même coût de développement, de vérifier aussi que « Sandrawo Geffroidwo » produit le même résultat, et ainsi de suite avec n’importe quel suffixe.

De même, on pourrait imaginer un test de création d’utilisateur avec comme pseudo « Julie », et un autre identique, avec cette fois un pseudo différent, « Marie ». Pourquoi pas… mais pourquoi ? Les 2 pseudos tiennent sur 5 caractères ASCII, quel intérêt cela apporte-t-il de tester ces deux cas ?

Rien ne sert de gonfler artificiellement le nombre de jeux de données, même si cela donne l’impression d’atteindre plus vite le ROI.

Les risques à avoir en tête

Certains paramètres doivent en effet être pris en compte en-dehors du coût de développement :

Le test va mettre un certain temps à s’exécuter. Peut-être quelques secondes… mais une flopée de tests inutiles peut faire perdre à la longue de précieuses minutes voire de longues heures !
Le test va produire des résultats que des personnes vont analyser, surtout si le test est en erreur. Or, dans cet exemple, les deux tests produiront (très très certainement) le même résultat. Il n’est pas question de faire perdre de temps d’analyse sur ce type de tests en doublon.
Comme les résultats seront identiques, le rapport global des tests sera biaisé.
Le test va vivre et devra être maintenu… peut-être par une autre personne que vous. Cette personne va devoir se plonger dans les jeux de données afin de savoir pour quelle raison ils ont été conçus comme tels, et se demandera pourquoi tant de tests se ressemblent.

Bref, avec ou sans DDT, l’automatisation des tests reste en grande partie une pratique d’optimisation du temps de cerveau humain, et il ne faut pas perdre de vue cet aspect !

Solution simple

Nous préconisons donc de donner un nom à chacun des jeux de données, afin que quiconque soit en mesure de comprendre son sens et son utilité. Et si vous vous apprêtez à créer un jeu de données à faible valeur ajoutée, vous vous en rendrez compte d’autant mieux.

Votre tableur ressemblera donc plutôt à cela :

nom_test	requete	nb_resultats_attendus
Prénom et nom	Sandra Geffroid	1
Prénom seul	Sandra	2
Prénom et nom avec accent superflu	Sandra Géffroid	1
Prénom tronqué	Sandr	2
Prénom et nom tronqués	Sandr Geffr	1
Prénom incorrect et nom correct	Sandro Geffroid	1
Prénom et nom incorrects	Sandro Geffroio	0
Prénom et nom corrects mais accolés d’un suffixe	Sandrawa Geffroidwa	0
Prénom et nom en majuscules	SANDRA GEFFROID	1
Prénom et nom en minuscules	sandra geffroid	1
Prénom et nom éclatés par des espaces	s a n d r a g e f f r o i d	10
Prénom et nom éclatés par des soulignés	S_a_n_d_r_a_G_e_f_f_r_o_i_d	0

Et voilà, la peau de banane est écartée !

Quels outils permettent de faire du DDT ?

Cette approche est tellement efficace que rares sont les outils d’automatisation des tests qui ne permettent pas de la mettre en œuvre. De notre côté, nous l’utilisons aussi bien sur nos projets Selenium (avec JUnit 5), UFT, Protractor, Postman…

Si vous voulez un tutoriel pour mettre en oeuvre le Data Driven Testing avec JUnit 5, nous vous conseillons cette vidéo présente sur Test Automation University.

Le Data Driven Testing est une pratique incontournable : l’essayer, c’est l’adopter.

Et vous, utilisez-vous le Data Driven Testing ?

3 questions essentielles pour bien démarrer en automatisation des tests

Posted on 27 août 2021 | by hightest | 12 commentaires

L’automatisation des tests est une piste que vous voulez investir. Vous souhaitez, par cette démarche, maîtriser les coûts associés à la qualité, bénéficier d’une meilleure couverture des tests, ou encore mettre en œuvre des recettes plus courtes et efficaces. Très bien, mais par où commencer ? Qui affecter à ce chantier ? Quels tests faut-il automatiser ? Quels KPI suivre ? Quel outil choisir ?

Une fois qu’on a répondu « oui » à la question « faut-il automatiser les tests ? » c’est effectivement une autre ribambelle de questions qui se présentent, comme si on avait ouvert une boîte de Pandore. Pire encore : en répondant mal à ces problématiques, l’automatisation des tests pourrait se solder par un échec.

Dans l’article précédent, nous donnions 10 bonnes raisons d’automatiser les tests. Aujourd’hui, nous vous offrons des clés pour mettre en œuvre concrètement un tel chantier. Accrochez-vous, car les pièges sont nombreux, mais le jeu en vaut la chandelle !

1) Quels challenges et difficultés pose l’automatisation des tests ?

Des challenges autant techniques qu’organisationnels, et la bonne nouvelle c’est qu’il est possible d’en anticiper certains avec un minimum d’effort.

Il est important, avant de se lancer, d’avoir en tête les principales difficultés associées à l’automatisation des tests. Commençons donc par cela, en nous basant sur l’édition 2020-2021 du World Quality Report.

Selon cette source, la problématique la plus fréquente (52 %) est le manque de personnel suffisamment qualifié pour mener à bien l’automatisation des tests. C’est la question du « QUI ».

La deuxième difficulté la plus fréquente (42 %), est liée aux lacunes au niveau des environnements de test et des jeux de données. Un exemple à la fois simple et très fréquent ? L’environnement dédié aux tests automatisés est parfois aussi utilisé par des testeurs humains, qui modifient ou suppriment des ressources dont les tests automatisés ont besoin. Ces actions peuvent provoquer des faux positifs et donner du fil à retordre au moment où on analyse les résultats des tests automatisés. Cette difficulté pointe du doigt une réalité : l’automatisation des tests est un enjeu d’équipe ; si des environnements spécifiques et des données séparées sont requises, il est important d’impliquer l’ensemble des parties prenantes concernées (administrateurs systèmes, métiers…) Automatiser « dans son coin » n’est pas envisageable.

Problème suivant ? 41 % des entreprises rencontrent des difficultés à définir une bonne stratégie d’automatisation. C’est la question du « QUOI ».

D’autres challenges sont également évoqués ; le classique « on n’a pas assez de temps ! » est invoqué par 37 % des entreprises (cela prend en effet du temps de s’arrêter au bord de la route pour remplacer ses roues carrées par des rondes !), juste avant « on n’a pas les bons outils » (32 %).

Au sein de cet article, nous aborderons spécifiquement les questions du QUI et du QUOI, qui constituent la base d’une bonne stratégie d’automatisation des tests.

2) Qui est responsable de l’automatisation des tests ?

Plusieurs leaders possibles

Bien plus de personnes qu’on pourrait l’imaginer de prime abord !

Nous disions plus haut que 52 % des entreprises déclarent manquer de personnel qualifié pour l’automatisation des tests. Les « testeurs automaticiens » sont en effet comme des trèfles à quatre feuilles : ils existent (contrairement aux moutons à 5 pattes…), mais il y en a peu. Restent donc, classiquement, 3 possibilités.

Faire monter en compétences les testeurs en automatisation des tests
- CONTRE :
  Le développement n’est pas la tasse de thé de tous les testeurs ; une telle montée en compétences nécessite des efforts importants et une bonne dose de motivation
- POUR :
  L’automatisation des tests produit des informations dont les testeurs seront en général les premiers bénéficiaires, et ce sont les mieux placés pour savoir ce qui doit être automatisé
Déléguer l’automatisation aux développeurs
- CONTRE :
  L’automatisation des tests est une activité de test, les développeurs peuvent avoir du mal à adopter l’état d’esprit critique qui rend les tests efficaces
- POUR :
  L’automatisation des tests est une activité de développement, les développeurs sont naturellement en mesure de s’y adonner
Externaliser la mise en place de l’automatisation des tests
- CONTRE :
  Cette démarche peut être moins féconde si vous la décorrélez totalement des autres activités de test ; même « externes », les automaticiens auront besoin de s’immerger dans la vie du projet
- POUR :
  Les prestataires aguerris connaissent les principaux écueils et les évitent plus facilement ; leur œil extérieur leur permet de questionner la démarche et de proposer une solution sur mesure.

Mais il ne suffit pas de répondre à cette question pour se tirer d’affaire ; c’est un arbre qui cache une forêt. Il faut ouvrir un autre tiroir de questions !

Des responsabilités multiples

En effet, l’automatisation des tests recouvre une multitudes d’activités, et l’implémentation des tests automatisés n’est qu’une d’entre elles.

Nous préconisons de réaliser une matrice des responsabilités (ou matrice RACI) afin d’établir, en amont du projet, qui interviendra sur quoi, et de répondre aux questions suivantes :

Qui choisira les tests qu’il faudra automatiser ?
Qui implémentera les tests automatisés ?
Qui lancera les tests automatisés ?
Qui analysera les résultats et rapportera les anomalies ?
Qui consommera les reportings des tests automatisés ?
Qui maintiendra les tests automatisés ?
Qui assurera la disponibilité des environnements dédiés aux tests automatisés ?
Qui produira les jeux de données nécessaires ?
(Et enfin, la question qui tue !) Qui sera responsable de la réussite de la démarche d’automatisation des tests ?

Il est important de répondre à ces questions, car elles permettent également de se rendre compte qu’il y a souvent plus de personnes qu’on l’imagine qui sont impliquées dans la démarche.

3) Quels tests faut-il automatiser ?

Pour trouver la meilleure liste de tests à automatiser, il faudra encore une fois se poser les bonnes questions.

Cette partie est dédiée aux 41 % qui peinent à établir une stratégie d’automatisation efficace !

Comme de bons tests prennent leur source dans de bonnes questions, voici celles que nous préconisons pour aider à définir le périmètre des tests automatisés :

Quels tests sont les plus critiques ?

Cette question est la plus évidente. Les tests révélateurs de la santé de l’application sont souvent les premiers que l’on souhaite automatiser. On les appelle les « smoke tests », par analogie à des tests que l’on ferait sur une machine industrielle par exemple : si vous appuyez sur le bouton de marche et que de la fumée sort de la machine, vous aurez détecté un bug bloquant en quelques secondes.

Quels sont les modules ou fonctionnalités qui, historiquement, sont les plus buggées ?

Cette question vaut surtout quand on initie tardivement le projet d’automatisation, et qu’il faut sécuriser les « nids à bugs ».

Quand on lance le projet d’automatisation en même temps que le projet de développement (une bonne pratique permettant de maximiser le ROI des tests automatisés), on peut se baser sur son expérience de projets similaires, puis étudier a fil de l’eau les modules où les bugs se concentrent.

Quels sont les tests les plus répétitititititi…tifs ?

Vous avez peut-être en tête ce formulaire qui compte 36 champs, ces champs pouvant être remplis de diverses manières, et chacune de ces manières devant être testée. L’œil est vigilant au premier remplissage, il persiste au deuxième, tient encore bon au troisième, puis il se perd, on ne sait plus ce qu’on a déjà rempli, on se trompe, on s’ennuie, et on a vraiment envie de passer à autre chose. Dommage, c’est à ce moment-là qu’on aurait pu détecter un joli bug.

Ces problèmes sont étrangers aux scripts de tests automatisés, c’est pourquoi les tests très répétitifs sont souvent de bons candidats à l’automatisation.

Quels sont les tests les plus rejouables ?

Il y a des tests qu’on ne peut jouer qu’une fois par an, qu’une fois par trimestre, ou encore une fois par jour. Il y a le fameux « batch de 4 heures du matin », la « moulinette du dimanche soir » et le « programme du 31 décembre ». Est-il vraiment intéressant d’automatiser les tests associés ? Pas sûr. Autant que possible, il est intéressant d’automatiser les tests facilement rejouables.

Quels sont les tests les plus difficiles à comprendre ?

Dans l’article précédent, nous parlions du fait que les tests automatisés constituent une documentation vivante du fonctionnement de l’applicatif. C’est un avantage quand ce fonctionnement est complexe. Un test difficile à comprendre sera peut-être mal effectué par un humain néophyte ; en l’automatisant, on se prémunit contre ce risque, et on donne en même temps plus de visibilité sur le fonctionnement précis du système à tester. Coup double !

Quels sont les tests qui seraient les plus faciles à implémenter ?

Il est souvent mal vu de commencer par le plus facile, de « choisir la facilité ». Ce n’est effectivement pas le premier critère à prendre en compte, mais la facilité d’implémentation est tout de même un élément important à avoir en tête. On veut des quick wins, pas des challenges insurmontables qui pourraient décourager l’équipe !

Synthèse des 6 questions

Comment utiliser efficacement ces 6 questions ? Afin de définir le périmètre à automatisés, il est nécessaire de :

Pondérer l’importance de chacune des questions
Répondre, pour chaque test ou suite de tests, à ces questions (sur une échelle de 1 à 5 par exemple)

En faisant une moyenne de ces scores, pondérée par l’importance des questions, on est alors en mesure de construire un périmètre à automatiser de manière solide et argumentée.

Chez Hightest, nous nous servons d’un modèle de tableur afin d’effectuer ce travail ; nous le partageons avec plaisir sur simple demande.

Tant d’autres questions…

Au sein de cet article, nous nous sommes concentrés sur QUI intervient dans la démarche d’automatisation des tests, et QUOI automatiser.

Nous pensons sincèrement que ces trois questions sont trop peu souvent posées, et que cela constitue une source importante d’échecs dans les projets d’automatisation des tests.

D’autres questions viendront ensuite, mais attention à ne pas mettre la charrue avant les bœufs ! En voici quelques-unes :

Quels KPI mettre en œuvre pour mesurer l’efficacité de la démarche d’automatisation des tests ?
Quelles mesures qualitatives surveiller en complément ?
Et le grand classique, la question qu’on a tendance à poser en premier et qui détrône toutes les autres… Quel outil choisir ?

« Quel outil choisir »… Il faudrait un article dédié (voire, plutôt, une série d’articles) pour répondre à cette question ! En attendant, voici quelques articles de notre blog qui vous donneront des éléments.

Selenium, ses logs, ses relative locators et sa certification.
HP UFT, et sa comparaison avec Selenium
Cypress, un concurrent redoutable de Selenium
Jenkins, sa gestion des paramètres, son intégration avec JMeter
Katalon, outil d’automatisation des tests mobiles
Pywinauto, outil gratuit et open source d’automatisation des applications lourdes

Nous espérons que cet article vous aura apporté des éléments utiles à votre démarche. A bientôt pour de nouveaux articles sur ce sujet passionnant qu’est l’automatisation des tests !

10 bonnes raisons d’automatiser les tests

Posted on 28 juillet 2021 | by hightest | Leave a Comment

Nos organisations reposent d’ores et déjà presque toutes sur des systèmes d’informations ou d’autres outils numériques sans qui elles ne peuvent clairement plus fonctionner correctement.

Au-delà des enjeux professionnels, quand une population entière repose sur un logiciel, les enjeux deviennent parfois des enjeux de santé publique (santé, énergie, télécommunication, etc).

C’est de cette dépendance aux outils numériques et aux risques associés qu’est née la notion de qualité logicielle et la discipline du test logiciel.

Pourquoi automatiser ses tests ?

Recettes à rallonge, coûts non maîtrisés, testeurs épuisés, résultats de test insatisfaisants, difficiles à interpréter, incomplets… Sortir une application ou un logiciel est trop souvent douloureux au sein des organisations.

L’automatisation des tests a le vent en poupe et fait fantasmer un avenir où les bugs seront gommés, sans aucun effort. Au-delà de l’utopie, de nombreuses raisons peuvent effectivement interroger sur la pertinence de cette démarche dans un contexte d’amélioration de sa qualité logicielle.

Vous êtes impactés au quotidien par la non-qualité et cherchez désespérément une solution pour limiter ses effets sur votre équipe et votre portefeuille ? Cet article liste 10 bonnes raisons d’engager une démarche d’automatisation des tests.

Les 10 raisons d’automatiser ses tests

L’automatisation des tests est une pratique susceptible de décupler l’efficacité des tests, de multiples façons différentes. Si l’on reprend le document de référence de la certification d’automatisation des tests A4Q Selenium Tester Foundation, ainsi que l’édition 2020-2021 du World Quality Report, les avantages de l’automatisation des tests sont les suivants :

#1 – Réduction du temps nécessaire à l’exécution des tests

C’est le plus évident, et le plus impactant pour les structures où les compétences et la charge coûtent cher, avec des délais pas forcément en adéquation avec les ressources ! Certaines vérifications longues et répétitives qui seraient effectuées en quelques heures par un humain, peuvent l’être en quelques secondes par un robot.

Le World Quality Report, qui se base sur 1750 témoignages d’entreprises du monde entier, tous secteurs confondus, a démontré que 65 % des entreprises constataient un réel gain de temps grâce à l’automatisation des tests.

#2 – Réduction des erreurs humaines

Lors de la répétition des tests de régression notamment (vous savez, ceux qu’il faut jouer et rejouer à chaque fois pour s’assurer que les nouveaux développements n’ont pas cassé les anciens !), des erreurs peuvent être commises par des testeurs lassés ou distraits. On ne peut d’ailleurs pas leur jeter la pierre, des biais cognitifs puissants sont à l’œuvre, qui rendent très difficile de se concentrer sur des tâches répétitives ! Par chance, les scripts de tests automatisés répètent inlassablement et minutieusement les mêmes actions, avec un meilleur résultat : 57 % des organisations constatent une meilleure détection des défauts grâce à l’automatisation des tests (World Quality Report 2020-2021).

#3 – Réduction des coûts alloués aux tests

La réduction des coûts : cette raison fait partie des motivations récurrentes pour se lancer dans l’automatisation des tests ; selon le World Quality Report, ce bénéfice est constaté par 62 % des organisations.

Attention, cela ne signifie pas que le test dit « manuel » soit rendu caduc par l’automatisation des tests ; simplement, l’automatisation va aider à se concentrer sur les tests des nouvelles fonctionnalités, tester de manière plus ciblée et plus créative.

#4 – Augmentation de la confiance envers le produit

Une version testée automatiquement permet d’augmenter la confiance que nous portons au produit. Ce niveau de confiance évoluera au fil du temps : les premiers tests automatisés permettront en quelques minutes de confirmer qu’une version est testable ; un arsenal plus complet pourrait aller jusqu’à justifier un déploiement continu.

#5 – Exécution de tests impossibles à jouer manuellement

C’est le cas, par excellence, des tests de charge ou de performance. L’automatisation rend presque infinie les possibilités de scenarios de test, sans à avoir à se soucier de la charge humaine.

#6 – Gain de valeur pour les testeurs humain

Eh oui, l’époque où les machines domineront le monde est encore loin. Néanmoins, libérés d’une partie des tests de régressions, les testeurs peuvent exécuter des tests manuels plus intéressants et plus complexes. Ils peuvent par exemple s’adonner à des sessions de test exploratoire, qui permettent de quadriller l’application à tester de manière ciblée et intelligente.

#6 – Exécution des tests plus tôt

Grâce à l’automatisation, les tests peuvent être exécutés plus tôt dans le processus. C’est typiquement le cas quand les tests sont joués dans la chaîne d’intégration continue ; si on le souhaite, dès que de nouveaux « bouts de code » sont déployés, immédiatement des tests sont déclenchés. Cela répond à un des 7 principes généraux du test logiciel : « Tester tôt » !

#7 – Tester en-dehors des heures de travail !

Il est satisfaisant de commencer sa journée sachant que des tests ont « tourné » pendant la nuit et qu’il n’y a plus qu’à analyser leurs résultats. En outre, il peut être commode de libérer un environnement en journée, pour n’y effectuer de tests que lorsque personne ne travaille dessus.

#8 – Augmentation de la fréquence d’exécution des tests

Le temps imposé aux tests peut contraindre à laisser certains cas de côté quand les délais sont courts ; les tests automatisés permettent d’éviter ou raréfier ces raccourcis. Ils permettent même d’augmenter le périmètre de ce qui est testé (c’est ce qu’on appelle la couverture des tests).

Selon le World Quality Report, 58 % des organisations interrogées constatent que l’automatisation des tests leur a permis d’augmenter la couverture de leurs tests.

#9 – Transparence accrue des activités de test

Les tests automatisés produisent des rapports de test générés à la volée, qui sont souvent partagés automatiquement aux parties prenantes concernées. Le niveau d’information est alors le même pour tout le monde et cela contribue à créer un climat de confiance au sein de l’équipe. Ce gain est constaté par 69 % des organisations interrogées pour le World Quality Report.

#10 – Création d’une documentation vivante

Les tests automatisés ne se contentent pas de constituer un inestimable filet de sécurité ; ils représentent aussi, à un instant T, une documentation fine de la façon dont une application est censée fonctionner. Convenablement mis à jour et versionnés, les tests automatisés gardent ainsi la trace des différentes façons de fonctionner du système concerné. Un bénéfice inattendu, qui peut s’avérer bien utile !

L’automatisation des tests, une pratique désormais standard

La discipline a déjà derrière elle des dizaines d’années, puisqu’il existait déjà des outils d’automatisation des tests à la fin des années 1990. Astra Quicktest, l’ancêtre d’UFT, un des logiciel d’automatisation des tests les plus connus, a été créé en 1998.

A ce jour, selon le State of Testing de 2020, 89 % des entreprises ayant une démarche qualité logicielle pratiquent l’automatisation des tests.

Bien que les formations initiales en automatisation des tests soient rares, il existe des certifications qui permettent de standardiser les pratiques. La certification A4Q Selenium Tester Foundation, créée en 2018, en est un bon exemple, de même que les certifications ISTQB Analyste technique de test et Automatisation des tests.

L’automatisation des tests est donc aujourd’hui une pratique fortement implantée dans le paysage de l’IT, et on comprend pourquoi.

Comment initier l’automatisation des tests dans ma structure ?

Si vous souhaitez vous lancer, de nombreuses ressources sont disponibles pour vous aider. Nous recommandons la lecture du syllabus A4Q Selenium évoqué plus haut, car ce document fournit une première vue d’ensemble des problématiques propres à l’automatisation des tests.

Prochainement sur notre blog, nous partagerons des bonnes pratiques pour mettre en œuvre l’automatisation des tests au sein de votre structure.

Et surtout n’oubliez pas, la question n’est pas de savoir si l’automatisation fournit réellement des avantages, mais plutôt de savoir quels sont les objectifs que vous souhaitez atteindre au sein de votre projet en utilisant l’automatisation des tests. Tous les bénéfices ne s’appliquent pas, ou du moins pas immédiatement, à tous les projet. C’est en les ciblant spécifiquement que vous multiplierez vos chances de les atteindre !

A bientôt !

Crédit image : Miguel Á. Padriñán