Vous souhaitez provoquer des discussions de fond sur le thème de la qualité logicielle, entre des personnes qui travaillent ensemble mais n’ont peut-être jamais eu l’occasion d’en parler directement ? Cet atelier est fait pour vous !
Lors de cet atelier, les personnes vont :
Exprimer des représentations, besoins, ressentis et autres visions subjectives de la qualité logicielle
Apprendre à mieux se connaître les unes les autres
Prendre conscience des différences de points de vue, pour mieux travailler ensemble au quotidien
Eventuellement corriger des idées reçues, en bonne intelligence
Avertissement important : c’est un atelier qui est là avant tout pour que les membres d’une équipe se connaissent mieux professionnellement, pas pour juger dans l’absolu « qui a raison » !
Cet atelier n’est pas forcément recommandé aux équipes qui traversent de fortes tensions. Dans tous les cas, sa facilitation nécessite un soin particulier. Votre équipe en ressortira grandie.
Préparation de l’atelier
Pour mener à bien cet atelier en présentiel, il vous faudra :
3 personnes + 1 guide de jeu. S’il y a plus de 3 personnes, compter 3 équipes de N personnes + 1 guide de jeu.
Des cartes « Visions de la qualité », faites maison c’est mieux ! Le principe : chaque carte contient une phrase plus ou moins clivante sur le thème de la qualité logicielle.
Une salle avec une table centrale, pour y poser les cartes « Visions de la qualité »
La posture de guide de jeu
La personne qui endosse le rôle de guide de jeu se prépare à :
Faciliter les échanges en établissant un cadre d’ouverture et de respect
Faire en sorte que la parole soit équitablement répartie
Prendre des notes pendant l’atelier
Faire une synthèse de ce qui a été exprimé pendant l’atelier
Déroulement de l’atelier
Les cartes « Visions de la qualité » sont réparties en tas thématiques au milieu de la table, face cachée.
Lors de la première session, l’équipe 1 pioche une carte sur la pile de son choix et la lit à voix haute. L’équipe se concerte rapidement pour choisir de défendre ou contredire ce qui est écrit, puis se lance. En fonction du temps dont vous disposez, cette prise de parole peut être limitée, à 2 minutes par exemple.
A la fin de ce « plaidoyer », l’équipe 2 doit tenter de défendre l’avis contraire à l’équipe 1.
L’équipe 3 doit ensuite synthétiser le débat et attribuer le point à l’équipe qui, selon elle, a été la plus convaincante.
Pendant tout cet échange, la personne qui endosse le rôle de guide de jeu prend des notes. Elle pourra ensuite envoyer une synthèse des résultats de l’atelier.
Ensuite, ça tourne ! Ainsi, lors de la deuxième session, l’équipe 2 tire une carte et fait son plaidoyer, l’équipe 3 contredit et l’équipe 1 arbitre.
Autant de sessions que de cartes peuvent avoir lieu, mais en pratique les débats peuvent prendre un peu de temps et ce n’est pas forcément possible de tout parcourir en une fois. Pas grave : conservez les paquets de cartes et proposez un nouvel atelier quelques mois plus tard !
Exemples de cartes
Pour confectionner vos carte « Visions de la qualité », vous pouvez noter des phrases que vous avez entendues au fil du temps ; des phrases auxquelles vous adhérez mais aussi des phrases avec lesquelles vous n’êtes pas d’accord. Vous pouvez bien sûr créer d’autres catégories ou remanier celles présentes ci-dessous.
Gestion de projet
« Le test représente souvent un goulet d’étranglement dans un projet. »
« Pour un projet donné, on ira plus vite avec 5 personnes qui développent, plutôt que 4 qui développent et une qui teste. »
« Le test est à un projet ce qu’un complément alimentaire est à un corps humain : sympa, mais pas essentiel. »
« Le nombre de cas de test joués est un bon indicateur de performances. »
« La véritable mission des tests est de prévenir les bugs, plutôt que simplement les trouver. »
Pratiques de test
« Les tests d’une fonctionnalité commencent quand elle a été développée. »
« Il est important de suivre strictement les scénarios de test sans dévier. »
« Les tests sont déduits logiquement des spécifications fonctionnelles. »
« Vérifier et valider, c’est la même chose, ce sont des synonymes. »
« Le test ne peut avoir lieu que si les spécifications sont complètes. »
Rôles et responsabilités
« Comme les devs connaissent bien le produit, ce sont ces personnes qui sont les plus à même de trouver des tests pertinents à faire. »
« Dans un projet agile, c’est à l’équipe de test de rédiger les tests d’acceptation d’une User Story. »
« Dans un esprit d’agilité, c’est plutôt l’équipe de développement qui fait les tests. »
« Les tests fonctionnels sont du ressort du métier, et les tests techniques sont du ressort des profils techniques. »
« L’équipe de test est garante de la qualité logicielle. »
« Pour bien tester, il faut avoir accès à la base de données de l’appli. »
Tech
« Les tests à automatiser sont ceux qui couvrent les fonctionnalités les plus critiques. »
« L’automatisation des tests doit démarrer juste après la première mise en production d’une application donnée. »
« L’objectif premier des tests automatisés est de réduire la durée des campagnes de test. »
« C’est à la fin du projet qu’il est le plus pertinent de procéder à des tests de charge. »
« Les tests manuels deviennent peu à peu obsolètes à l’ère de l’automatisation. »
« Les tests de sécurité constituent un domaine à part et ne concernent pas les profils de test lambda. »
« Une bonne qualité de code suffit à éliminer la plupart des bugs. »
Bonne session de jeu ! Envoyez-nous votre feedback, et aussi si vous le souhaitez, les phrases que vous avez rajoutées !
Vous testez un logiciel contenant un formulaire qui demande de saisir un RIB ? Voici quelques éléments pour vous aider !
Les différentes parties d’un RIB
Un RIB se compose de 23 caractères répartis en 4 éléments :
Le code banque (5 chiffres)
Le code guichet (5 chiffres)
Le numéro de compte (11 chiffres et/ou lettres)
La clé RIB (2 chiffres)
Peut-on « inventer » un RIB ?
Oui et non.
Non, parce qu’on ne peut pas « imaginer » un RIB de tête, parce que la clé RIB doit être le résultat d’un calcul que vous ne ferez pas facilement de tête !
Oui, parce qu’il n’y a pas besoin que le RIB existe « dans la vraie vie » pour valider le formulaire de saisie.
Tout est donc dans la clé RIB.
Quelques exemples de RIB et IBAN fictifs et bien formés
Ces RIB sont destinés à réaliser des tests passants de validation de RIB. N’effectuez pas de transactions en utilisant ces RIB et IBAN. Si vous devez effectuer des tests de virements réels, constituez votre propre jeu de données en bonne intelligence avec le reste de votre équipe.
Faux RIB avec le code banque de la BCI (Banque Calédonienne d’Investissement) : 17499 12345 12345678901 53
Cette année 2023, la plateforme de crowdtesting Testeum, dont Hightest a posé les fondations, offre une campagne par mois à un projet calédonien innovant !
Vous trouverez dans cet article un nouveau témoignage, de la part des personnes en charge du site web Agripedia.
Pour rappel, un premier témoignage a été produit concernant une application mobile, celle de Domaine NC.
Qui êtes-vous ?
Je suis Estelle Bonnet-Vidal, consultante en communication scientifique (Lincks), prestataire pour l’institut agronomique néo-calédonien (IAC), AMO et rédactrice scientifique pour le site internet Agripedia depuis 2018. Je suis accompagnée de Christina Do, rédactrice scientifique pour Agripedia et assistante de communication à l’IAC. Nous sommes mandatées par Laurent L’Huillier, le directeur de l’IAC, qui est à la tête de la création d’Agripedia.
À quoi sert le site Agripedia et à qui s’adresse-t-il ?
Agripedia met à disposition des fiches techniques sur l’agriculture locale au sens large. Le site compte actuellement plus de 220 fiches techniques dans des domaines très variés : les plantes utiles (alimentaires, ornementales, médicinales, revégétalisation), les animaux d’élevage, la lutte contre les ravageurs, les auxiliaires de culture…
Notre volonté est d’en faire un site de référence régional, une encyclopédie qui permet aux agriculteurs, aux agricultrices et à tous ceux qui jardinent de trouver des informations précises, utiles, faciles à trouver, faciles à lire pour qu’ils puissent cultiver et mener à bien leurs productions et gagner un temps précieux. C’est un enjeu important de sécurité alimentaire dans un contexte de dérèglements globaux et de transition agroécologique.
Crédit : Midjourney
À quelle(s) question(s) vouliez-vous que la campagne de crowdtesting réponde ?
Nous voulions savoir si les contenus mis en ligne étaient agréables et faciles à lire et si les internautes naviguaient agréablement dans le site et trouvaient facilement certaines fonctionnalités innovantes, telles que les filtres et les PDF.
Je vous mets les questions que nous avons posées (nldr : ci-dessous sont les objectifs de test saisis dans Testeum) :
Vérifiez que la navigation est intuitive et agréable
Vérifiez que vous trouvez comment faire une recherche multicritères avec plus de 5 critères et que les résultats vous paraissent cohérents
Vérifiez que vous trouvez facilement quelles sont les plantes ornementales en fleurs pour le mois d’avril
Vérifiez que vous arrivez à générer et télécharger le PDF d’une fiche sur plusieurs thématiques différentes
Vérifiez la clarté du contenu, à savoir si les fiches sont faciles à lire et à comprendre
Qu’avez-vous pensé des retours des crowdtesters ?
J’ai été étonnée par la rapidité des réponses, moins de 24 h. Les crowdtesteurs nous ont signalé plusieurs bugs (à 75 % mineurs) que nous n’avions pas vus et ils le font avec sérieux. Cela nous a permis de nous conforter dans les pistes d’amélioration que nous avions en tête.
Qu’avez-vous pensé de la plateforme elle-même ?
Tout d’abord, je tiens à remercier toute l’équipe Testeum de nous avoir offert cette campagne. J’ai vraiment apprécié de découvrir cette plateforme que je ne connaissais pas. Je l’ai trouvée facile à prendre en main et on peut aisément interagir avec les crowdtesteurs.
Tiens, c’est quoi qui brille par terre ? Une lampe ? HA, voici le génie de Testeum, vous pouvez faire 3 vœux de nouvelles fonctionnalités sur la plateforme !
Selon moi, je pense que pour tout achat de la première campagne, vous devriez offrir une campagne-test, par exemple avec trois crowdtesteurs. Cela permettrait de découvrir la plateforme, la prendre en main, et surtout de voir comment il faut formuler correctement nos questions aux internautes. C’est très stratégique et cela demande de comprendre comment l’outil marche pour ensuite formuler nos questions avec précision.
Je pense également qu’il faudrait offrir la possibilité d’interagir en visio, via une petite fenêtre vidéo avec un ou deux crowdtesteurs. Les rapports des crowdtesteurs sont pertinents mais ils sont courts et on aimerait creuser un peu pour aller plus dans les détails. Les échanges humains par messagerie se concentrent sur les bugs et ne permettent pas de détecter la palette d’émotions qui accompagnent la découverte d’un site. Est-ce qu’il est agacé de ne pas trouver certaines infos ? est-ce qu’il est heureux d’avoir appris des choses ?
Avoir la possibilité de poser plus de questions avec le forfait proposé.
Dernier point, je pense qu’un PDF qui résume l’ensemble des bugs trouvés par les crowdtesteurs et que l’on peut ensuite archiver serait pertinent.
Quel conseil donneriez-vous à une personne qui envisagerait une démarche de crowdtesting pour tester son produit ?
De bien réfléchir aux questions à poser. C’est la clé pour avoir des réponses pertinentes et améliorer ensuite son site.
Crédit : Midjourney
_________________________
Merci à Estelle et Christina d’avoir misé sur la qualité logicielle, et d’avoir pris le temps pour ce témoignage ! Vous voulez jeter un oeil à la campagne Testeum d’Agripedia ? En voici l’adresse !
Et si vous voulez vous inscrire sur Testeum pour réaliser des tests et obtenir un revenu complémentaire, c’est par ici !
L’image mise en avant contient des photos générées par Midjourney.
En 2023, ChatGPT est un nom qui revient sur toutes les lèvres ! Depuis peu, Bard vient un peu lui voler la vedette. Ces IA surpuissantes vont-elles remplacer les QA, les devs, le monde entier, personne ?
Cet article n’est pas là pour répondre à cette question, mais pour présenter quelques réponses erronées et amusantes des robots conversationnels les plus affolants de ce début d’année ! De quoi dédramatiser un peu.
Les IA font leur cinéma
Le cinéma du coin propose les offres promotionnelles suivantes :
Gratuit le jour de l’anniversaire de la personne (valable uniquement pour la personne et pas pour celles qui l’accompagnent)
-50 % pour les personnes de moins de 18 ans
-25 % pour les 18-25 ans et pour les plus de 60 ans
Ce cinéma ouvre sa billetterie en ligne où le tarif s’adapte en fonction de l’âge de la personne inscrite.
La question que l’on se pose, et que même un enfant trouverait très simple, est la suivant : Regina fête ses 54 ans aujourd’hui ; aura-t-elle droit à une réduction ?
Réponse courte : bien sûr, une réduction de 100 %, puisque c’est son anniversaire !
Une réponse plus longue préciserait que cette réduction (ou plutôt, exonération) ne s’applique que sur sa place.
ChatGPT : la règle de gestion de trop
ChatGPT n’est pas de cet avis.
Bard : « et » au lieu de « ou »
Fun fact, Bard aussi se trompe ! (Nous lui avons posé la question en anglais vu que le français n’était pas encore supporté lors de l’expérience)
Bard comprend que la gratuité le jour de l’anniversaire n’est valable que si la personne se trouve dans l’une des tranches d’âge sujettes à des promotions. Ce qui est évidemment erroné.
Dates : l’ambiguïté classique
« Jusqu’à » est une expression qui met la communauté du test en émoi.
Est-ce que cela veut dire qu’on inclut ce qui suit, ou qu’on l’exclut ?
ChatGPT ne veut pas que j’aille à la plage
ChatGPT ne partage pas cette anxiété et répond comme s’il n’y avait pas d’ambiguïté.
Bard m’incite à sécher le travail
Après avoir posé la même question à Bard (en anglais toujours), force est de constater que cette IA comprend l’inverse de ChatGPT et ne voit pas de problème à ce que j’aille à la plage. Une fois encore, l’ambiguïté du terme n’est pas relevée !
Le défi des trous de paille
« Combien de trous a une paille ? » est une question simple qui permet de se rendre compte de la diversité des points de vue. Il n’y a pas de bonne réponse, ou plutôt, toutes les réponses ci-dessous sont bonnes.
2 trous : une entrée et une sortie !
1 trou : car il n’y a qu’un « chemin » dans cette paille
0 trou : sinon la paille aurait des fuites !
ChatGPT tombe dans le piège
ChatGPT ne se trompe pas vraiment dans sa réponse, mais elle ne détecte pas le piège que constitue l’ambiguïté de la question.
On ne la fait pas à Bard
En revanche, Bard a su détecter la feinte, puisant dans les innombrables ressources accessibles via Google et évoquant cette question épineuse.
Compte les QA
Une liste de 26 prénoms féminins est fournie, et les IA doivent les compter. Facile ou pas ?
ChatGPT ne sait pas compter.
Hélas, ChatGPT n’en compte que 25. Ce n’était même pas cela le piège envisagé 😀
Bard débloque
Le même exercice traduit en anglais est fourni à Bard. Pourquoi compte-t-il 18 prénoms au lieu de 25 ? Et surtout, quelle est la logique derrière « The names you provided are all female names, so we can assume that they are all testers. » ? Un sentiment d’étrangeté émane de cette réponse.
Deuxième chance : testeuse ou testeur
Une autre liste est fournie, et cette fois-ci le compte est bon. Toutefois, le raisonnement qui suit a de quoi semer la confusion !
Le même exercice ne peut pas être fourni à Bard, étant donné que le mot anglais « tester » peut se traduire aussi bien par « testeuse » ou « testeur ».
Conclusion
Les IA sont impressionnantes. Ce sont d’excellents outils qui permettent de nous accompagner dans nos tâches les plus diverses, mais ils contiennent, comme tout logiciel, des défauts. C’est aussi en prenant conscience de ces défauts que nous devenons capables de les utiliser au mieux !
(On leur repose les mêmes questions d’ici un an ? Il est bien possible que leurs réponses soient plus pertinentes quelques mois !)
_________________________
L’image de couverture a été générée avec Midjourney.
Cette année 2023, la plateforme de crowdtesting Testeum, dont Hightest a posé les fondations, offre une campagne par mois à un projet calédonien innovant !
Vous trouverez dans cet article le témoignage des porteurs du premier projet ayant utilisé Testeum dans ce cadre, à savoir l’application Domaine NC.
Qui êtes-vous ?
Nous sommes Adrien Sales, product manager de l’application mobile et de l’API de domaine.nc, et Laurent Schaeffer, développeur de l’application mobile Domaine NC Mobile.
A quoi sert l’appli Domaine NC ?
LS : Pour faire simple, cette application sert à consulter de manière mobile et très compacte les noms de domaines de Nouvelle-Calédonie. Cela permet de visualiser les différentes informations d’un nom de domaine et de recevoir des notifications en cas de d’expiration prochaine de celui-ci.
AS : Nous avons produit une expérience utilisateur disruptive pour faciliter une gestion qui auparavant était plutôt faite à la main… avec des risques d’oubli. Lequel a un impact important sur notre business digital car si votre nom de domaine expire, vous disparaissez du web et donc vous perdez de la visibilité, ou pire : des transactions. Nous voulions mettre en avant la valeur de ces données et leur potentiel.
Une page de résultats de recherche sur l’application mobile Domaine NC
Quels sont les risques qualité de cet applicatif ? Qu’est-ce qui pourrait « mal tourner » ?
AS : Un des risques est d’avoir une UX non optimale/trop compliquée. On redoutait aussi d’avoir de mauvais temps de réponse… ou pire : pas réponse (une vilaine 500 par exemple) !
A quelles questions vouliez-vous que la campagne de crowdtesting réponde ?
LS : Il fallait s’assurer que chaque utilisateur puisse accéder facilement aux informations qui l’intéressent.
AS : Effectivement, nous voulions nous assurer de la facilité de prise en main par un néophyte. Nous voulions aussi savoir si nos performances étaient passables, bonnes ou excellentes (nous visions une recherche et un affichage instantanés).
Comment avez-vous organisé vos campagnes de test ?
AS : On a d’abord figé un périmètre très réduit de fonctionnalités (notre MVP) via une milestone dédiée sur GitHub, puis on a organisé une première campagne très simple pour récupérer des feedbacks des testeurs sur un jeu très restreint de features.
LS : Suite aux corrections opérées en sortie de cette première session de test, on a lancé d’autres campagnes : une par fonctionnalité.
Qu’avez-vous pensé des retours des crowdtesters ?
LS : Nous avons découvert un point de vue différent du nôtre, qui nous a permis d’améliorer l’application sur un plan UX et fonctionnel.
AS : On a découvert des scénarios de test très pertinents. Par exemple, une personne a cherché la taille maximale acceptée par notre champ de saisie de nom de domaine. Certains tests nous ont même permis d’améliorer la sécurité de notre API ! Nous avons eu de nouvelles idées de simplification d’usage, par exemple l’ajout de placeholders guidant davantage les utilisateurs.
Nous avons aussi eu un retour sur un bug bête et méchant : la recherche automatique ne devait se déclencher qu’à partir de 3 caractères saisis, mais ce n’était pas le cas. Nous avons donc amélioré au passage la vitesse de l’appli et réduit le nombre d’appels de l’API.
Un exemple de rapport de bug trouvé pendant l’une des campagnes de l’application mobile Domaine NC
Qu’avez-vous pensé de la plateforme elle-même ?
AS : Les dashboards sont beaux et très faciles à exploiter ! Tout est prêt à l’emploi. On a pu les copier-coller tels quels pour organiser notre travail en équipe, avec très peu d’efforts.
LS : La plateforme est facile d’utilisation et permet de bien organiser ses campagnes de manière optimale.
Une partie du dashboard accessible durant une campagne de test (et conservé une fois qu’elle est terminée)
Pour vous, comment une démarche crowdtesting devrait s’articuler avec les autres pratiques de test ?
AS : De ce que j’ai pu en voir, je trouve que cela arrive par exemple pour tester des RC (release candidates) ou des bêtas, et en conditions réelles (sur une infra cible). J’ai par exemple pu mesurer l’impact sur les perfs de l’API et voir si toute la chaîne tenait bien le coup : c’était vraiment de bout en bout ! Génial et terriblement efficace.
Je verrai bien une description d’organisation, qui intégrerait le crowdtesting avec toutes les autres phases de test et la partie release planning.
Je pense que left-shifter une campagne ferait sens dans une approche LEAN, ce qui privilégierait le Time To Market, la qualité et plus généralement toute la chaîne de delivery. Nous avons implémenté une chaîne de CI complète qui nous permettait de déployer avec une simple release la version sur les stores… et de manière sémantique. Ainsi on peut se concentrer sur des périmètres compacts et boucler très rapidement et avec une grande qualité logicielle. Nous avons tout fait via des outils cloud GitHub/Fastlane.
Quel conseil donneriez-vous à une personne qui envisagerait une démarche de crowdtesting pour tester son produit ?
AS : Je lui conseillerais de :
Sensibiliser son équipe : lui présenter les concepts clés de la plateforme à son équipe et de la sensibiliser au Left-Shifting. Lui montrer des exemples de campagnes : les wins, les fails, des exemples très concrets, présenter les approches (une grosse campagne de test VS plusieurs petites) voire diffuser des témoignages.
Sensibiliser sur le fait que le test d’une feature fait parties des coûts de dev… et que donc cela doit être pris en compte dès le début.
Au moment de la conception de la campagne de test, proposer un parcours complet pour profiter au mieux de la plateforme (ROI)
Disposer impérativement d’un PO (et donc d’une vision produit très claire)
Embarquer l’équipe (Devs, Scrum Master) afin que le crowdtesting soit une phase projet comme une autre… et si possible des newbies complets à l’équipe qui ne connaissent rien au domaine métier.
En bonus : créer un club d’utilisateurs qui ont utilisé la plateforme et qui pourraient créer un guide de best practices.
Tiens, c’est quoi qui brille par terre ? Une lampe ? HA, voici le génie de Testeum, vous pouvez faire 3 voeux de nouvelles fonctionnalités sur la plateforme !
LS : On en a 3 chacun ? J’en fais 2 pour ma part : 1) La possibilité d’exporter les données de test vers d’autres platformes (style GitHub ou autre) ou au format JSON, et 2) Fournir une API pour récupérer les données de test et/ou d’autre données.
AS : J’en fais 3 ! 1) Pouvoir trigger des Webhooks pour pousser les retours directement en issues (Github) ou déclencher des workflows (IFTTT, Zapier, Power Automate, …), en mode événementiel, ou à des chaînes de CI. 2) Fournir une API pour consommer les données des feedbacks et des campagnes à des fins d’intégration B2B ou de reporting. 3) Pouvoir targetter des profils professionnels (en plus des critères actuels : âge, sexe, pays et type de matériel possédé).
Merci à Adrien et Laurent pour ce témoignage ! Pour en savoir davantage sur la génèse de leur projet, vous pouvez visionner cette vidéo.
Vous pouvez également consulter deux de leurs rapports de test Testeum : celui-ci et celui-là !
Vous avez un site web et vous voulez vous assurer qu’il peut être utilisé correctement depuis n’importe quelle combinaison machine + système d’exploitation + navigateur ? Laissez tomber tout de suite, c’est impossible ! Les configurations sont trop nombreuses pour être toutes testées, il faut donc abandonner l’idée de faire des tests de portabilité.
Mais non, c’était une blague… Aujourd’hui, on va voir ensemble comment se servir des données collectées par Google Analytics pour construire une base pour des tests de portabilité utiles et suffisamment couvrants.
Extraction de la liste des appareils les plus courants
Les étapes pour obtenir la liste des appareils mobiles utilisés par les visiteurs du site sont les suivantes :
Se connecter sur Google Analytics
Déplier l’onglet « Audience »
Déplier l’onglet « Mobile »
Cliquer sur « Appareils »
Un tableau de bord s’affiche ; modifier la plage de dates à volonté. Par exemple, observer les 3 derniers mois pour avoir davantage de matière, tout en conservant des données suffisamment récentes.
Afficher le nombre maximum de lignes pour ce tableau (il est possible d’afficher jusqu’à 5000 lignes)
Cliquer sur le bouton « Exporter » pour obtenir un fichier Excel listant l’ensemble des devices utilisés. Remarque : il est fort possible que le premier élément de la liste regroupe tous les iPhones sans distinction de version…
C’est tout ! Vous avez désormais un peu de matière pour commencer vos tests de portabilité mobile.
Utilisation de la liste
Sur la liste extraite, vous pouvez par exemple calculer combien de lignes de devices vous permettent de couvrir 80% des utilisateurs. Pour le site Hightest, nous avons fait l’exercice. Sur 595 devices, 167 nous permettent de couvrir 80 % des utilisateurs. Plus saisissant encore, 26 nous permettent d’en couvrir 50 % ! Ce type de données permet vraiment de cibler l’effort de test.
Et vous, utilisez-vous ce type de données issues de l’utilisation réelle pour orienter vos tests ?
Mettez-vous en œuvre des tests de portabilité sur vos projets, ou d’autres tests non fonctionnels ?
Si vous voulez profiter d’autres tutos pour accompagner votre quotidien de QA, abonnez-vous à notre page LinkedIn !
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 !
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 !
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 :
Afin de lui ajouter les dépendances nécessaires pour profiter de l’extensionXray 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 :
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 :
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)
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
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 ?
On vous partage
notre expertise !
Abonnez-vous à notre newsletter pour suivre toute l’actualité du test !
