Catégorie : Outils

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.

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.

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.

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 :

1. 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.
2. 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.
3. Au moment de la conception de la campagne de test, proposer un parcours complet pour profiter au mieux de la plateforme (ROI)
4. Disposer impérativement d’un PO (et donc d’une vision produit très claire)
5. 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.
6. 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 :

1. Se connecter sur Google Analytics
2. Déplier l’onglet « Audience »
3. Déplier l’onglet « Mobile »
4. Cliquer sur « Appareils »
5. 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.
6. Afficher le nombre maximum de lignes pour ce tableau (il est possible d’afficher jusqu’à 5000 lignes)
7. 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.

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.

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 ?

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.

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…

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 ?

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.

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 ! 

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.

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

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

« 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) :

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 :

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 ?

Dans notre dernier article, nous abordions l’un des aspects non-fonctionnels de la qualité les plus critiques en ce contexte d’explosion du choix des devices : la portabilité. Saviez-vous que des sociétés aussi inattendues que Land Rover (oui, le constructeur de 4×4 !) proposaient des smartphones ? Il est désormais virtuellement impossible de tester toutes les configurations existantes.

Ce phénomène est désigné sous le terme de fragmentation. Mais il ne concerne pas seulement les devices ; il touche aussi les systèmes d’exploitation (OS), la diversité des navigateurs web, ainsi que les différentes moutures et version de chacun des éléments cités.

Techniques de test de portabilité

Dans ce contexte, les équipes de test ne baissent pas les bras, car il existe de nombreuses solutions pour répondre à cette problématique.

La plus classique : posséder sur site des moyens de tester telle ou telle configuration. Ça peut être un tiroir rempli de téléphones de test (qui à la longue pourrait plutôt tenir lieu de musée du rétrophoning). Certaines entreprises conservent également des machines avec des OS anciens, comme Windows 7 ou Vista, avec de vieilles versions d’Internet Explorer.

Si l’on veut s’affranchir de ces contraintes et augmenter le nombre de configurations testables, il existe des fermes de devices qui permettent de tester sur des environnements réels tout en n’ayant pas à les acquérir chez soi. pCloudy fait partie de ces services, de même que BrowserStack dont nous allons parler ensuite.

Des émulateurs permettent, quoi qu’il en soit, d’avoir un premier niveau d’information. Si on arrive à reproduire un bug vu en production sur un émulateur, il n’y a pas forcément besoin de pousser le test plus loin pour pouvoir commencer à corriger le bug.

Enfin, pour les besoins croisés de tests de portabilité et d’utilisabilité, le crowdtesting est une stratégie tout indiquée.

Situation

Vous avez besoin de reproduire rapidement un bug sur un navigateur particulier ?

Vous souhaitez avoir un aperçu rapide d’un site web sur un grand panel de navigateurs ?

Dans ces situations, ce qui suit vous intéressera !

Tester rapidement et gratuitement un navigateur

BrowserStack est, si on traduit mot à mot, un « tas de navigateurs », mais cette simple traduction est trompeuse, car il est aussi possible d’interagir directement avec des téléphones réels. Tout comme pCloudy, BrowserStack propose une formule gratuite et des formules payantes. Ce qu’il est intéressant de noter, c’est que si la version gratuite de pCloudy propose un choix de devices restreint, celle de BrowserStack suit une stratégie différente : c’est le temps de chaque session qui est limité !

Si votre scénario prend une minute ou moins, rendez-vous sur BrowserStack et vous serez en mesure de profiter du service d’un grand nombre de navigateurs.

Rendez-vous sur la page d’accueil de BrowserStack, cliquez sur « Free trial », et choisissez votre environnement !

Une minute, c’est peut-être un peu court pour tester chacune des fonctionnalités offertes, en revanche elles sont bien là, même en version gratuite :

Par exemple, le rapport de défaut sur Slack permet d’envoyer en un clic les informations essentielles :

Et voilà, vous êtes maintenant en mesure d’exécuter rapidement et simplement des tests sur un grand nombre de navigateurs, et ce gratuitement.

Et si vous souhaitez un jour passer en version payante, les prix sont tout à fait raisonnables pour le service rendu. Il existe en outre un tarif réduit pour les freelances et, cerise sur le gâteau, une gratuité les projets open source !

Quoi qu’il en soit, bons tests à vous !

Qu’est-ce que pCloudy ?

pCloudy est une plateforme qui donne accès des machines (physiques ou virtuelles) situées en Inde ou aux Etats-Unis, et avec lesquelles il est possible d’interagir. Un grand nombre de smartphones et de tablettes sont proposées, de multiples constructeurs différents et avec une large gamme de versions d’Android et d’iOS. Des navigateurs sont également disponibles.

Ce type de service est parfois désigné sous l’expression de ferme de devices.

A quoi sert ça sert ?

La plateforme pCloudy permet de récolter de précieuses informations sur la portabilité des applicatifs. Parfois négligés, les tests de portabilité sont pourtant essentiels ; ils permettent de comprendre comment les utilisateurs finaux verront l’interface. Pourront-ils interagir correctement avec cette interface, quel que soit leur navigateur, leur système d’exploitation et la version de ce dernier ? Les éléments d’affichage seront-ils harmonieusement répartis, quelle que soit la taille de leur écran ? Est-on vraiment responsive ? Au même titre que les autres tests non-fonctionnels, cet aspect passe malheureusement souvent au second plan, faute de temps, de moyens et souvent, de sensibilisation.

On a déjà des téléphones de test, est-ce utile de tester aussi sur pCloudy ?

Ha, les fameux téléphones de test… Les développeurs et les testeurs se chamaillent pour les avoir, on ne sait jamais qui a emprunté le Google Pixel 2, on cherche partout ce fichu câble (« non pas celui-là, l’USB C tu sais ») et on doit gentiment attendre son tour pendant que Boniface monopolise l’unique iPhone de l’équipe (« Attends encore deux minutes s’il te plaît. Enfin, deux autres minutes… »).

Autre problème : la couverture. Vous avez 10 téléphones de test ? Bravo, c’est davantage que beaucoup d’équipes projet. Mais combien de téléphones différents ont vos utilisateurs ? C’est un autre ordre de grandeur. Effectuer des sanity checks sur un grand nombre de machines vous donnera une confiance bien plus solide dans la qualité de votre applicatif.

Enfin, dernier problème : la reproductibilité. Un utilisateur de prod se plaint de ne pas pouvoir réaliser telle ou telle action, vous avez besoin de reproduire « son » bug pour comprendre de quoi il en retourne. Sur un de nos derniers projets, il y avait un bug majeur que l’on pouvait reproduire sur OnePlus 7, mais pas sur OnePlus 6, avec la même version d’Android ! Il est donc bien pratique d’avoir un pool important de machines pour maximiser ses chances de reproduire des bugs marginaux.

En conclusion : qui peut le plus peut le moins ; pas besoin de jeter au compost vos téléphones de test, en revanche pCloudy pourrait vous apporter un coup de boost considérable.

Comment ça marche ?

Voici un petit aperçu de l’usage le plus basique que l’on peut avoir de pCloudy : le test « manuel » d’applications mobiles.

Premièrement, dans l’onglet « My app / data », téléverser un fichier APK ou IPA.

Puis, dans l’onglet « Devices », choisir un téléphone ou une tablette.

Après quelque secondes, on se retrouve face à l’écran du téléphone et on peut librement interagir avec.

Libre à nous alors d’installer une application, de changer les paramètres du téléphone, de retourner l’écran… et de réaliser tous les tests souhaités !

Combien de machines sont mises à disposition ?

Sur la liste des devices, en février 2021, s’affichaient 267 devices physiques. Selon nos calculs, cela représente bien 40 kilos de smartphones et tablettes ; qui dit mieux ?

Est-il possible d’utiliser pCloudy dans une démarche d’automatisation des tests mobiles ?

Oui. pCloudy s’interface avec plusieurs solution d’automatisation des tests mobiles : Appium, Espresso, Opkey, Calabash et XCTest.

Combien ça coûte ?

Une quinzaine de devices peuvent être librement utilisés sans abonnement payant. Pour pouvoir accéder à l’ensemble des devices proposés, un abonnement doit être acheté, au mois ou à l’année (voir le détail des prix).

Le support est-il réactif ?

Oui : un chat est proposé au sein du site et le support pCloudy répond dans la minute. C’est en tous cas ce que nous avons pu constater dans notre timezone particulière ; une confirmation métropolitaine serait la bienvenue !

Une astuce à donner ?

Oui, 2 pour le prix d’une !

Gestion d’une erreur commune

Lorsque vous tentez d’installer une application iOs (donc contenue dans un fichier IPA), il peut arriver que vous tombiez sur l’erreur « A valid provisionning profile for this executable was not found. » A ce moment-là, pour régler le problème, se rendre dans l’onglet « My app / data » et cliquer sur l’option « Re-sign » associée au fichier IPA.

La documentation pCloudy donne davantage d’informations sur ce comportement.

Attention aux Apple Id

Si vous saisissez votre Apple Id, pensez bien à vous déconnecter à la fin de votre session.

______________________________

Si vous souhaitez découvrir un autre service de tests de portabilité, vous pouvez aussi vous pencher sur BrowserStack.

Et vous, utilisez-vous une ferme de devices ? Qu’est-ce que cela vous apporte ? La section des commentaires est à vous. A bientôt !

Pourquoi passer la certification A4Q Selenium ?

Les certifications sont un sujet clivant. Certaines personnes en raffolent, d’autres considèrent cela d’un œil méfiant, tandis que rôdent les spectres du bachotage et du bourrage de CV. De notre côté, nous voyons cela comme une bonne manière de confirmer des acquis. Nous avons tendance à passer une certification après plusieurs années de pratique, plutôt que de démarrer from scratch par une formation intense et de passer l’examen dans la foulée, avant que les connaissances ne soient bien ancrées dans notre esprit. C’est dans cette optique que nous avons envisagé de passer la certification A4Q Selenium Tester Foundation.

Comme le contenu du syllabus est intéressant, le lire ne peut être que profitable et vous aidera à prendre du recul ; à vous de juger ensuite si passer la certification peut apporter à votre carrière.

A qui s’adresse cette certification ?

Le syllabus ne précise pas le public visé. Nous considérons que la certification serait profitable aussi bien aux QA en charge de l’automatisation des tests, qu’aux test managers ayant besoin d’avoir une vue d’ensemble sur les bonnes pratiques d’automatisation des tests.

Que contient le syllabus A4Q ?

Autant l’annoncer d’emblée : le contenu du syllabus est excellent. En plus des éléments techniques auxquels on s’attend, il contient également de très bonnes connaissances de fond (philosophie de l’automatisation des tests, facteurs de réussite, sensibilisation aux biais qui entourent cette discipline). De précieux conseils pour partir sur de bonnes bases !

Le syllabus A4Q apprend-il à mettre en place un projet Selenium ?

Oui et non, mais pour préciser les choses simplement, le syllabus n’est pas un tutoriel ! Si vous souhaitez apprendre Selenium, mieux vaut vous tourner vers des sites tels que Test Automation University. Le syllabus vous permettra d’ancrer tout ce que vous aurez appris, et vous apprendra peut-être aussi de nouvelles fonctions que vous ne connaissiez pas.

Quel « parfum » de Selenium est enseigné ?

Selenium dispose de connecteurs avec une dizaine de langages ; dans ce syllabus, c’est Python qui est utilisé.

Si vous avez l’habitude d’un autre langage, pas de panique, la transition est plutôt douce.

En vrai… la certification Selenium est-elle difficile à obtenir ?

Maîtriser le syllabus doit être votre priorité ; avoir de l’expérience sur l’implémentation de tests Selenium vous aidera aussi évidemment.

40 questions sont posées lors de l’examen, qui dure une heure, ce qui laisse quand même du temps pour réfléchir (c’est deux fois moins de questions que pour la certification PSPO et PSM par exemple !)

Le seuil de réussite est de 65 %, comme pour ISTQB Fondation. Toujours à titre de comparaison, PSPO et PSM exigent 85 % de réussite.

Peut-on passer la certification A4Q à distance ?

Oui. Préparez-vous à une surveillance assez stricte pendant l’examen : quelqu’un devra garder un œil sur vous via la webcam de votre ordinateur et via la caméra de votre appareil photo ; il vous faudra aussi montrer la pièce où vous passerez l’examen sous toutes les coutures (c’est le moment de mettre un peu d’ordre dans votre maison…) Attention aussi, un débit internet minimum est requis, il faudra vous assurer de disposer d’une excellente connexion pour éviter les pépins.

Peut-on passer la certification A4Q en candidat libre, sans formation préalable ?

Le syllabus est trompeur sur cette question :

« Les examens ne peuvent être passés qu’après avoir suivi la formation A4Q Testeur Selenium au niveau fondation, puisque l’évaluation par l’instructeur de la compétence du candidat dans les exercices fait partie de l’obtention de la certification. »

Malgré cette mention, il est tout à fait possible de passer la certification en candidat libre, sans avoir passé de formation au préalable.

Peut-on passer la certification A4Q Selenium en français ?

Bonne nouvelle pour les personnes qui redoutent les examens en anglais : il est possible de passer la certification A4Q en français.

Prenez tout de même quelque chose en compte : si vous choisissez de passer l’examen en anglais et que ce n’est pas votre langue maternelle, vous pourrez disposer de 15 minutes supplémentaires.

Cette certification est-elle valide à vie ?

Nous n’avons en tous cas pas trouvé de mention contraire.

Où peut-on s’entraîner en passant un test blanc A4Q Selenium ?

Un quiz en ligne A4Q Selenium est présent depuis peu sur notre site. Voici le lien vers le test blanc. Bon courage !

Quelques punchlines pour donner envie ?

Avec plaisir car on aime les punchlines ! En voici quelques unes :

L’importance d’une stratégie d’automatisation

« Une organisation n’a jamais construit par hasard un projet d’automatisation réussi. » Syllabus, partie 1.1

« Tous les tests manuels ne devraient pas être automatisés. Parce qu’un script automatisé nécessite plus d’analyse, plus de conception, plus d’ingénierie et plus de maintenance qu’un script manuel, nous devons calculer le coût de sa création. » Syllabus, partie 1.2

Chaque projet d’automatisation est différent

« Tous les avantages ne peuvent pas être obtenus dans tous les projets, et tous les inconvénients ne se produisent pas dans tous les projets. » Syllabus, partie 1.1

Cela rejoint le 6^ème des 7 principes généraux du test logiciel : les tests dépendent du contexte.

L’origine de la plupart des bugs

« Les êtres humains trouvent la plupart des bogues ; l’automatisation ne peut trouver que ce qu’elle est programmée pour trouver et est limitée par le paradoxe des pesticides. » Syllabus, partie 1.1

N’est-ce pas libérateur à lire ? Comme vous le voyez, le syllabus s’attache rigoureusement à détruire les fausses attentes attachées à l’automatisation des tests.

L’arbre qui cache la forêt

« Les organisations sont souvent tellement préoccupées par les tests via l’interface graphique qu’elles oublient que la pyramide des tests suggère que davantage de tests unitaires/composants soient effectués. » Syllabus, partie 1.4

Si vous souhaitez expliquer l’importance de ces tests aux décideurs de votre organisation, ce jeu de sensibilisation aux tests unitaires pourrait vous être utile !

L’importance des logs et des acteurs qui en ont besoin

« Il est primordial qu’un automaticien de tests soit attentif à la précision des logs. Une bonne gestion des logs peut faire la différence entre un projet d’automatisation qui échoue et un projet qui réussit à apporter de la valeur lorsqu’elle est réalisée. » Syllabus, partie 3.1

Nous approuvons fortement cette remarque et vous proposons d’aller plus loin avec cet article, qui propose un moyen d’écrire des logs en langage naturel. Le syllabus met aussi l’accent sur les personnes qui vont avoir besoin de logs et de rapports de qualité :

« Il est important que les automaticiens de test déterminent qui veut ou a besoin de rapports d’exécution des tests, et quelles informations les intéressent. » Syllabus, partie 3.1

Nous espérons que ces éléments vous auront été utiles et que vous vous faites désormais une idée plus précise de la certification A4Q. Bonne révisions si vous envisagez de la passer, et bonne lecture du syllabus dans tous les cas !

Vous avez un test fonctionnel automatisé en Java (Selenium ou autre), et vous souhaiteriez enregistrer dans un fichier CSV la durée de chacune de ses étapes. Cela peut être en effet très utile pour surveiller l’évolution des performances de l’applicatif à tester !

Pour comprendre à quoi cela pourrait nous servir, voici un cas d’usage.

Cas d’usage

Lundi, on lance le test automatisé chronométré. Le parcours d’inscription dure environ 40 secondes ; les durées de toutes les étapes sont enregistrées dans un rapport au format CSV. Le lendemain, un refacto du back a lieu. On relance le test, cette fois l’inscription dure 45 secondes. On observe le rapport CSV. On identifie l’étape où ça coince pour se concentrer dessus. On voit que le temps de réponse d’une API a augmenté de 7 secondes (mince !), et qu’un autre temps a diminué de 2 secondes (chouette !) Un correctif est livré, on relance le test. Le parcours dure maintenant 38 secondes. Ces résultats sont communiqués et l’équipe est congratulée. Tout est bien qui finit bien !

Qu’est-ce que ça change par rapport à d’habitude ?

On documente mieux les mauvaises nouvelles

« C’est plus lent qu’avant. » Voilà une phrase que tout le monde souhaite prendre au sérieux. Le problème est qu’elle est fort imprécise. Plus lent comment ? Il faut se baser sur les souvenirs d’une personne. Si elle est du genre à forcer le trait, on peut entrer dans de bien épineuses discussions. Et si on est plusieurs à s’y mettre… « Moi ça a toujours été lent, est-ce que c’est à cause de ma machine ? » Etc. Bref, on cherche à éviter au maximum ce genre d’inutiles échanges. D’autant que tout ça nous rappelle à quel point les exigences non-fonctionnelles ont été mises de côté, comme trop souvent…

Avec ce type de rapport, il va devenir très simple de porter un regard objectif sur la performance des applicatifs.

… mais aussi les bonnes !

Au détour d’une refonte, vous constaterez peut-être que certaines étapes durent moins longtemps qu’avant. Ce sera désormais plus simple de le prouver. Eh oui, en tant que QA, on peut aussi aussi remonter des effets de bord positifs ! Cela permet de donner le sourire à l’équipe et surtout de pouvoir capitaliser dessus.

Objection votre honneur !

« Ah oui certes, mais pourquoi ne pas utiliser un outil dédié à ce type de test, par exemple Gatling ? »

Loin de nous l’envie de réinventer la roue ! La solution que nous allons proposer a pour objectif de :

• S’intégrer à des tests existants en un rien de temps
• Répondre à un besoin d’enregistrement des performances très simplement
• Fournir un rapport frugal mais très clair
• S’intégrer à un parcours utilisateur en passant par le front

Nous vous invitons néanmoins à garder un point à l’esprit. La durée des étapes ne dépend pas seulement des performances de l’applicatif (et autres facteurs tels que son environnement technique, la connexion internet, etc.) ; elle dépend aussi de la vitesse d’exécution du webdriver, qui dépend en bonne partie de votre script lui-même !

Si jamais vous changez votre script de test, toutes vos métriques passées peuvent devenir obsolètes. Il est donc important de stabiliser vos tests, notamment en optimisant les temps d’attente des éléments de la page web, avant de vous lancer dans cette démarche.

Balance le code !

Ok, ok, le voici ! Copiez-collez-le sauvagement si ça vous chante. Et si vous voulez plus d’explications, rendez-vous après ce gros bloc de Java.

Le gros bloc de code que vous attendiez

import org.junit.Test;
import java.io.*;
import java.sql.Timestamp;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;

public class PerfTest {

    ArrayList<BaliseTemporelle> balisesTemporelles = new ArrayList<>();

    @Test
    public void exemplePourMontrer() throws InterruptedException {
        String nomScenario = "Création de compte";
        BaliseTemporelle init = new BaliseTemporelle("Initialisation de la première durée"); // Cette première balise temporelle n'apparaîtra pas dans le fichier.
        balisesTemporelles.add(init);
        Thread.sleep(2000); // Ici, mettre lesdites étapes de test. Pour une meilleure lisibilité, nous ne mettons que des temps de pause, qu'on pourra retrouver dans le fichier de rapport.
        BaliseTemporelle accesSite = new BaliseTemporelle("Ouverture du navigateur et accès à telle URL");
        balisesTemporelles.add(accesSite); // On ajoute l'étape une fois qu'elle est terminée
        Thread.sleep(4000);
        BaliseTemporelle affichageFormulaireInscription = new BaliseTemporelle("Affichage du formulaire d'inscription");
        balisesTemporelles.add(affichageFormulaireInscription);
        Thread.sleep(6000);
        BaliseTemporelle remplissageFormulaireInscription = new BaliseTemporelle("Remplissage");
        balisesTemporelles.add(remplissageFormulaireInscription);
        Thread.sleep(8000);
        BaliseTemporelle validationFormulaireInscription = new BaliseTemporelle("Validation du formulaire d'inscription");
        balisesTemporelles.add(validationFormulaireInscription);
        enregistrerDurees(nomScenario);
    }

    // Ce qui suit est un ensemble de fonctions que vous devrez, de préférence, ranger ailleurs.

    private class BaliseTemporelle {
        String nom;
        Timestamp timestamp;

        public BaliseTemporelle(String nom){
            this.nom = nom;
            timestamp = new Timestamp(System.currentTimeMillis());
        }

        public Timestamp getTimestamp(){
            return timestamp;
        }

        public String getNom(){
            return nom;
        }
    }

    private ArrayList<Long> getDureesEtapes(){
        Timestamp premier = balisesTemporelles.get(0).getTimestamp();
        ArrayList<Long> durees = new ArrayList<>();
        for (BaliseTemporelle baliseTemporelle : balisesTemporelles) {
            Timestamp deuxieme = baliseTemporelle.getTimestamp();
            if (premier != deuxieme) {
                long diffTimeSecondes = (deuxieme.getTime() - premier.getTime()) / 1000;
                durees.add(diffTimeSecondes);
                premier = deuxieme;
            }
        }
        return durees;
    }

    public void enregistrerDurees(String nomScenario) {
        ArrayList<Long> durees = getDureesEtapes();
        StringBuilder sbDurees = new StringBuilder();
        Long total = new Long(0);
        for (Long duree : durees) {
            total += duree;
            sbDurees.append(duree);
            sbDurees.append(";");
        }

        try {
            File file = new File("src\test\java\utils\" + nomScenario  + ".csv"); // A remplacer par le chemin de votre choix...
            boolean creerFichier = file.createNewFile();
            BufferedReader br = new BufferedReader(new FileReader(file));
            FileWriter fw = new FileWriter(file.getAbsolutePath(), true);
            BufferedWriter bw = new BufferedWriter(fw);
            if(creerFichier){
                StringBuilder sbNomEtapes = new StringBuilder();
                balisesTemporelles.remove(0); // On n'a pas besoin d'afficher le nom de la première étape vu que ce sont les durées qu'on affiche (diff entre étape n et étape n-1.
                for (BaliseTemporelle etape : balisesTemporelles) {
                    sbNomEtapes.append(etape.getNom());
                    sbNomEtapes.append(";");
                }
                bw.write("Date;" + sbNomEtapes.toString() + "Totaln");
            }
            SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd-hh-mm-ss");
            String date = sdf.format(new Date());
            bw.write(date + ";" + sbDurees.toString() + total + "n");
            br.close();
            bw.close();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

}

Hé bien, c’était un gros bloc ! Mais rassurez-vous, c’est tout ce dont vous aurez besoin !

Quelques explications

Ce petit « cas de test » (vous l’aurez compris en lisant le code, il ne teste rien) va alimenter, à chaque exécution, un fichier nommé « Création de compte.csv ». Le nom de ce fichier dépend de la variable nomScenario.

Le contenu de ce fichier, ouvert dans Excel, ressemble à ça après deux lancements du test :

La durée qui s’affiche dans chacune des cellules est calculée en soustrayant l’horodatage d’une balise temporelle de la balise suivante (dans la fonction « enregistrerDurees »). Le nom de la première balise temporelle (voir la classe BaliseTemporelle) n’apparaît pas dans le tableau, car elle correspond au temps 0 du test.

Pas besoin de créer le fichier Excel à l’avance, le script gère tout seul la création et la modification. Assurez-vous simplement de supprimer le fichier Excel dès que vous souhaitez changer votre script, car les durées ne seront plus bonnes, et les noms des balises temporelles ne correspondront peut-être plus à celles d’avant. Vérifiez bien aussi que le chemin indiqué lors de l’initialisation de la variable « File » est valide, ou changez-le carrément.

C’est tout ce qu’il vous faut ! Bon chronométrage et n’hésitez pas à poser vos questions si vous en avez !