Tests de portabilité de navigateurs : le défi du gratuit avec BrowserStack

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 image contenant texteDescription générée automatiquement

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 :

Une image contenant texteDescription générée automatiquement

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

Une image contenant texteDescription générée automatiquement

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 !

pCloudy en 9 questions-réponses

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 !

La certification A4Q Selenium Tester Foundation en 12 questions-réponses

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 !

Chronométrer ses étapes de tests automatisés (Java)

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 :

Date Ouverture du navigateur et accès à telle URL Affichage du formulaire d’inscription Remplissage Validation du formulaire d’inscription Total
2020-07-30-01-37-15 2 4 6 8 20
2020-10-22-03-05-40 2 4 6 8 20

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 !

Squash TM : 8 astuces et bonnes pratiques

Développé depuis 2011 par Henix, une ESN française spécialisée dans la qualité logicielle, Squash TM est un outil de gestion des tests, ou test management, gratuit et open source. Très pratique, il permet à la fois de concevoir les tests, de les exécuter et de communiquer leurs résultats. Si vous souhaitez structurer ces activités et jeter à la poubelle vos antiques fichiers Excel, Squash TM est une solution intéressante à envisager !

Squash TM s’intègre dans une suite de logiciels conçus pour interagir ensemble, et qui constitue une véritable boîte à outils pour aider les testeurs dans leurs activités. Cette suite peut s’adapter à tout contexte métier ou technique, et peut accompagner la pratique de tests tant fonctionnels que non-fonctionnels. Dans cette suite, on compte également Squash TA (pour Test Automation) ou encore Squash CLI (pour Command Line Interface).

Nous utilisons Squash TM au quotidien auprès d’un grand nombre d’organisations qui l’ont intégré dans leur système d’information.

Cependant, même si cet outil est plutôt user-friendly, nous avons constaté qu’il n’était pas toujours utilisé à la hauteur de son potentiel. Voici donc aujourd’hui quelques astuces que nous avons adoptées au fil du temps et qui nous permettent d’augmenter drastiquement la performance des tests !

EDIT du 09/03/2022 : les captures d’écran visibles dans cet article ne reflètent pas la nouvelle interface de Squash TM. Toutefois, les astuces restent d’actualité ! Bonne lecture !

Astuce #1 : Les copier-coller, tu éviteras

Ça, c’est une méta-règle, à retenir avant toute chose. 

En programmation, le principe DRY (“Don’t Repeat Yourself”, en français “Ne vous répétez pas”) est un principe de développement logiciel qui consiste à éviter tout doublon dans un projet et ainsi améliorer le code, la lisibilité, la maintenance et le changement de celui-ci.

Eh bien, il est important aussi de l’appliquer aussi en gestion des tests afin de faciliter la maintenance du patrimoine de tests

Les bonnes pratiques qui suivent vous aideront à respecter ce principe.

Astuce #2 : Des jeux de données, tu utiliseras

Pour éviter les redites, le moyen le plus efficace est d’utiliser la fonctionnalité des jeux de données de Squash TM. Trop de personnes passent à côté de cette jolie fonctionnalité qui pourtant est tellement efficace !

Des cas de test sans jeux de données

Imaginons une entreprise qui classe ses clients dans des segments aux noms poétiques. En fonction de son segment, chaque client a une page d’accueil personnalisée. Voici à quoi ressembleraient des tests rédigés sans utiliser la fonctionnalité des jeux de données :

On répète le nom de chaque segment 3 fois : dans le titre, dans l’action et dans le résultat attendu. Et les textes de l’action et du résultat attendu sont répété 6 fois, car il y a 6 segments. Super redondant ! Et maintenant, regroupons tout cela en un petit paquet bien rangé.

Un cas de test, plusieurs jeux de données

Vous voyez la syntaxe dollar/accolades ? Quand vous l’utilisez, l’onglet « Paramètres » du cas de test ajoute automatiquement le paramètre renseigné (ici, « segment »). Voyons à quoi ça ressemble, une fois qu’on a renseigné quelques valeurs possibles pour le paramètre « segment » :

Quand on ajoute dans une campagne ce cas de test comprenant 6 jeux de données, 6 « lignes » sont alors créées.

Attention à une chose toutefois : logiquement, vos 6 jeux de données auront tous la même importance (la métadonnée associée au cas de test lui-même). Si vous avez des degrés d’importance différents, il vaut mieux avoir autant de cas de test. Par exemple, si « Grenat » est un segment qui n’est plus utilisé que par une poignée de clients, qui représentent ceux qui sont en retard de paiement depuis plus de deux ans… on peut certainement considérer que l’importance du test est moindre.

Astuce #3 : Tes jeux de données, clairement tu nommeras

Quand vous créez un jeu de données, vous devez lui ajouter un titre, qui s’affichera dans la colonne « Jeux de données » (voir copie d’écran ci-dessus). Ne négligez pas cette étape. Au fil du temps en effet, vous n’aurez sans doute plus besoin d’exécuter vos cas de test en ouvrant la popup d’exécution et en lisant attentivement chacune des étapes. Il vous suffira de lire le nom de vos cas de test et celui de vos jeux de données. C’est pour cas que vous devez bannir les titres cryptiques tels que « JDD1 » et nommer vos jeux de données le plus précisément possible.

Astuce #4 : Tes cas de test, clairement tu nommeras aussi

Le nom d’un cas de test doit être descriptif et transmettre les informations nécessaires pour savoir ce qui est réellement testé. Il doit également être concis, afin d’être facile à comprendre. L’écriture d’un mauvais nom de scénario de test peut vous nuire de plusieurs façons :

  • Il peut réduire la qualité de l’exécution des tests, car les testeurs ne comprennent pas correctement l’enjeu et testent finalement autre chose
  • Il peut ralentir l’exécution des tests, car les testeurs ont besoin de se concentrer davantage pour comprendre la finalité du test
  • Il peut rendre plus difficile la maintenance du référentiel de tests, pour les mêmes raisons.

Voici quelques exemples de mauvais noms de cas de test :

  • Page de connexion
  • Mail de relance
  • Liste des utilisateurs
  • Graphique de suivi

Pourquoi ce sont de « mauvais noms » ? Parce qu’ils parlent de fonctionnalités, mais pas de comportements attendus. Un cas de test est un scénario que l’on exécute en attendant un résultat, et le nom du cas de test doit donner une idée de ce résultat attendu… Ce faisant, cela permet de comprendre rapidement l’importance et l’enjeu de ce cas de test.

En effet, un test nommé « Page de connexion » peut recouvrir des enjeux très importants ou tout à fait mineurs. Voici, pour la liste précédente, quelques exemples de reformulation pour des cas de test d’importance très haute !

  • Affichage de la page de connexion par défaut lorsque l’utilisateur n’est pas connecté
  • Réception du mail de relance suite à une relance en masse
  • Affichage de tous les utilisateurs au sein d’une liste
  • Cohérence du graphique de suivi dans le temps

Et maintenant, voici quelques exemples de cas de test d’importance faible :

  • Présence d’un tooltip au survol du champ « Enregistrer le mot de passe » sur la page de connexion
  • Changement de couleur au survol du bouton de connexion présent dans le mail de relance
  • Possibilité de saisir manuellement le nombre d’éléments affichés par page dans la liste des utilisateurs
  • Conformité du code couleur du graphique de suivi

Le nom de certains cas de test vous semble un peu longuet ? C’est possible ! Mais c’est toujours plus pratique que d’avoir à ouvrir le cas de test et de fouiner dans ses étapes. Un exemple ci-dessous !

Astuce #5 : Tes cas de test, brièvement tu écriras

A l’inverse du nom du cas de test…

La meilleure façon d’écrire vos scénarios de test est d’avoir des étapes fort brièvement décrites, et d’aller à l’essentiel. Restez concis.

Cela vous aidera à aller droit au but, ce qui vous permettra de détecter plus facilement les anomalies.

Bousillons calmement une idée reçue

Vous l’avez sûrement déjà lu des milliers de fois : les cas de test sont une forme de documentation. Pour autant, ils ne visent pas :

  • à décrire de manière exhaustive tout ce qui est attendu de l’application
  • à se substituer à une formation !

« Il faut que les cas de test puissent être exécutés par n’importe qui. » Quand vous entendez cette phrase, vous êtes donc en droit de frémir.

Vous utilisez Squash TM dans une organisation fermée ; ses collaborateurs ne sont pas « n’importe qui ». Une nouvelle recrue n’est pas non plus n’importe qui. Si elle est amenée à tester un applicatif, il est essentiel de lui expliquer la raison d’être de cet applicatif, comment il fonctionne, ce qu’il est important de tester, ce qu’on aimerait savoir à la fin d’une campagne de test. L’étape d’acclimatation fonctionnelle passe à la trappe ? Dans ce cas, ce n’est pas un profil de testeur que l’on intègre dans l’équipe, c’est un profil d’automate, et on se prive d’un précieux cerveau.

Quand on passe une heure à écrire un cas de test en entrant dans les moindres détails, c’est une heure entière que l’on passe à ne pas tester l’application. Et par la suite les testeurs nécessiteront… combien ? Cinq minutes de lecture ? Dix ? Autant de temps qui ne sera pas utilement consacré, et qui sera multiplié d’itération en itération.

Pire peut-être, si le cas de test est trop long, les testeurs fatigueront plus vite, les liront en diagonale, et passeront peut-être à côté de vérifications essentielles.

A vous donc de trouver l’équilibre parfait entre clarté et concision.

Astuce #6 : Des appels de cas de test, intelligemment tu feras

Combinée à l’utilisation des jeux de données, cette fonctionnalité vous fera faire des merveilles. Pour appeler un cas de test dans un autre, c’est-à-dire de l’ajouter comme une étape, il suffit de faire un glisser-déposer du cas de test depuis l’arborescence.

Pour reprendre l’exemple précédent : dès lors qu’un cas de test nécessitera une connexion, nous pourrons appeler le cas de test « Connexion client en fonction de son segment ». Dans l’exemple ci-dessous, nous reprenons un jeu de données renseigné précédemment, mais nous aurions pu aussi le configurer directement dans le cas de test (option « paramètres délégués »).

Un cas de test peut en appeler un autre qui en appelle un autre qui en appelle un autre… aucune contrainte à signaler à ce sujet. Il est également possible d’appeler plusieurs cas de test au sein d’un seul.

Désormais, il y a beaucoup moins de raisons de se répéter !

Cas pratique : une gestion mutualisée des jeux de données

Avez-vous remarqué que sur la page « Informations » d’un cas de test Squash TM, il est possible de renseigner un champ dédié aux prérequis ? Malheureusement, il n’est pas possible de mutualiser ces informations entre plusieurs cas de test ayant besoin des mêmes prérequis.

Nous avons donc parfois recours à un mode de fonctionnement qui nous a permis d’économiser pas mal de temps : au lieu de remplir ce champ de pré-requis (avec le risque d’avoir à maintenir X fois ce champ en cas de changement), nous créons un dossier de cas de test « utilitaires » à appeler à volonté en première étape des cas de test en guise de prérequis.

Il arrive que les jeux de données de certains cas de test soient le résultat d’une requête SQL à lancer au préalable ; c’est donc bien plus pratique de n’avoir à modifier ce script SQL qu’à un seul endroit.

C’est là que la zone « Cas de test appelé par » s’avère très utile ! Dès qu’il faudra changer la requête, il sera possible d’effectuer une revue des impacts possibles, et de s’assurer que la nouvelle requête convient bien à tous les cas de test concernés.

Astuce #7 : Tes cas de test, tu qualifieras

Quand on crée un cas de test sur Squash TM, son champ « Importance » est par défaut alimenté avec la valeur « Faible ».

Si vous ne savez pas quels cas de test sont cruciaux, vous risquez de vous retrouver en difficulté au moment de la conception de votre campagne de test.

Avec Squash TM, il est facile de garder la trace des cas de test les plus importants et de ceux que vous pouvez déprioriser. Faites en sorte que vos cas de test reflètent ce qui est vraiment vital – et ce qui ne l’est pas.

Cela doit devenir un réflexe : ajustez l’importance du cas de test dès sa création !

Astuce #8 : Des périphrases, tu utiliseras

Un dernier coup de pouce pour la rédaction. Si votre interface contient du texte et que ce texte n’est pas l’objet du test, il est inutile de l’indiquer directement dans les étapes du cas de test, sous peine d’occasionner des rapports d’anomalie à faible valeur ajoutée.

Le bouton de validation d’une pop-in peut être amené à changer au fil du temps : il peut en particulier changer d’intitulé (« Ok », « Valider », « Je comprends », « Oui », « D’accord », « Certes », « Pourquoi pas » ou « Tout me va »). Si cela se produit, vous n’avez pas envie d’avoir à mettre à jour une longue liste de tests. Il est donc plus pratique de désigner ce bouton comme « le bouton de validation » (donc, en utilisant une périphrase), plutôt que « le bouton ’Ok’ » ou « le bouton ‘Valider’ ».

Idem pour les messages d’erreur ! « Le message d’erreur indiquant à l’utilisateur que son mot de passe est erroné » est plus robuste que « le message ‘Mot de passe erroné’ », qui pourrait devenir « le message ‘Votre mot de passe est incorrect, merci de le saisir de nouveau’ ».

Conclusion

Quelle que soit votre utilisation de Squash TM, n’oubliez pas que l’objectif est de refléter vos objectifs qualité de la meilleure façon, pour obtenir des référentiels de test pertinents et efficaces. Concentrez-vous donc sur l’optimisation à chaque étape du processus et ce que vous construirez offrira à vos clients ou équipes la meilleure valeur ajoutée possible.

Ces bonnes pratiques ont pour but de vous aider à être plus efficace en travaillant avec ; n’hésitez pas à compléter avec vos propres astuces !

Cypress en 13 questions-réponses

« Selenium c’est terminé, maintenant c’est Cypress ! »

Voilà une terrifiante affirmation quand on utilise Selenium au quotidien et qu’on adore ça ! Mais rien ne sert de se recroqueviller dans ses douillettes habitudes, retroussons nos manches et partons à l’assaut de cette étoile montante, dont on entend si souvent parler.

Cet article s’appuie sur :

  • Des questions que nous nous sommes posées avant et pendant notre exploration de cet outil
  • Le tutoriel Cypress de l’excellente Test Automation University
  • L’hypothèse que si on peut faire une chose avec Selenium, on aura envie de faire la même chose avec Cypress
  • L’espoir inavouable de mettre Cypress en défaut… mais à la loyale !

Mais pour commencer, posons les grosses questions qui fâchent !

Cypress est-il payant ?

Etudions cette question en premier car c’est un point crucial pour certaines équipes !

Pour répondre à cette question, il va falloir faire la différence entre 2 produits : l’exécuteur de tests (Test Runner) et le service de reporting associé (Dashboard service). Le premier est totalement gratuit et open-source. Le second est facultatif, et payant à partir de 500 exécutions de tests par mois. En plus des tableaux de bord, il permet de gérer la parallélisation des tests, facilite la mise en place de l’intégration continue (qui reste possible même sans), s’intègre avec Slack, injecte du feedback dans Github… Bref, un super assistant, mais dont on peut se passer s’il le faut.

Quels langages supporte Cypress ?

Le JavaScript, et c’est tout. Vous avez l’habitude de tel ou tel autre langage avec Selenium ? Tant pis, vous apprendrez, ce serait dommage que ce détail vous empêche d’aller plus loin ! D’autant que Cypress offre un DSL (Domain Specific Language) particulièrement fourni. On y reviendra.

Quels navigateurs supporte Cypress ?

Au départ, seul Google Chrome était pris en charge, mais cela a bien changé. A partir de Cypress 4.0, il est possible désormais d’interagir avec Firefox et Edge, et de manière générale cette problématique est inscrite dans la roadmap de Cypress. Restez en veille !

Quid de la documentation et de la communauté Cypress ?

Côté documentation, le site de Cypress est plutôt généreux. Et sa communauté StackOverflow n’est pas en reste, avec plus de 6700 questions sur le sujet. Ce n’est rien comparé à Selenium (bientôt 78 000 questions), mais c’est tout de même un bon signe, surtout si on tient compte de la relative nouveauté de l’outil.

La communauté Cypress est par ailleurs assez active sur Github, et il existe par exemple des initiatives open-source de nature et d’ampleurs assez diverses visant à combler les manques de Cypress. Un exemple ? Cet utilitaire qui permet d’interagir avec la touche de tabulation !

La liste des plugins Cypress (développés ou non par Cypress) est visible ici.

Poursuivons maintenant avec des questions sur le fonctionnement de l’outil.

Cypress, c’est encore une surcouche de Selenium ?

Hé non ! Selenium communique avec le navigateur, alors que Cypress tourne directement dans le navigateur. Voyez le script Cypress confortablement assis dans le code HTML de la page d’accueil de Testeum !

Cela peut d’ailleurs occasionner des comportements inattendus, par exemple des protestations de votre antivirus qui s’emmêle les pinceaux dans les certificats (Kaspersky par exemple ; avec Avast nous n’avons pas rencontré de problème).

Sur quel framework s’appuie Cypress ?

Cypress s’appuie sur le framework de test Mocha (prononcer « moka »), d’où il tire notamment la syntaxe « describe » / « it ». Vous avez peut-être déjà croisé ce framework en JavaScript au détour d’un projet Protractor !

L’identification des objets est-elle similaire à celle à l’œuvre dans Selenium ?

Par défaut, seuls les sélecteurs CSS sont gérés. Heureusement, il existe une librairie permettant d’utiliser les xPaths, qui sont tout de même bien pratiques dans certains cas.

Comment configure-t-on l’environnement de test et ses paramètres ?

Ça se passe dans le fichier qui permet d’indiquer tous les paramètres, à savoir le fichier cypress.json. Là, on indique par exemple la taille souhaitée de la fenêtre de navigateur, les différents time-out, éventuellement une URL de base qui servira de préfixe à chaque appel de page web. Tous ces paramètres sont listés ici.

Peut-on mettre en œuvre le design pattern du Page Object Model avec Cypress ?

Le bon vieux Page Object Model, qu’on retrouve si souvent dans les (bons ?) projets de tests Selenium, permet entre autres de ne déclarer qu’une seule fois tous les éléments d’une page, et d’ainsi réduire son temps de maintenance. Qu’en est-il avec Cypress ?

C’est possible

Le tutoriel de la Test Automation University, tout comme cet article, expliquent comment mettre en œuvre ce design pattern. Si vous venez du monde de Selenium, le dépaysement sera donc minimal si vous souhaitez poursuivre avec cette pratique.

Cypress propose autre chose

Au sujet du Page Object Model, le blog Cypress met en revanche les pieds dans le plat et conseille d’abandonner cette pratique, considérée trop risquée et coûteuse en maintenance (on peut être d’accord ou non !). Ce qui est proposé, c’est de passer directement par les actions de l’application pour la mettre dans l’état qu’on souhaite avant d’opérer la vérification.

Mettons par exemple que l’on souhaite valider la réponse d’un formulaire. Un script de test classique effectuerait d’abord les actions permettant de remplir le formulaire, en « mimant » les actions de l’utilisateur.

Comme Cypress injecte du code JavaScript directement dans le navigateur, une autre possibilité serait de modifier directement le DOM pour que le formulaire soit déjà pré-rempli. L’article donne un exemple intéressant, qui démontre la robustesse et la rapidité de cette méthode. Celle-ci suppose cependant un niveau plus élevé en développement JavaScript. N’oublions pas que Cypress a été développé originellement par des devs front-end pour des devs front-end !

Mais au fait, pourquoi ça s’appelle Cypress ?

Les feuilles du cyprès sont vertes toute l’année et ne tombent jamais. C’est ce que souhaitent à nos tests les créateurs de Cypress !

Maintenant que nous avons fait le tour des questions de base autour de Cypress, pesons maintenant les pours et les contres !

Qu’est-ce qui est indiscutablement mieux que Selenium ?

Son interface de lancement interactif

Cette fonctionnalité est plutôt sympathique, on se croirait dans un cockpit (avec moins de boutons). Il est possible de générer le code de capture d’un objet en cliquant simplement dessus.

 

Au lancement des tests, toutes les requêtes effectuées sont affichées dans un panneau à gauche de l’écran. Un code couleur permet d’identifier d’un coup d’œil les différents statuts des requêtes. Une fois les tests terminés, ce panneau permet de « remonter le temps » ; on clique sur une des étapes, et l’écran affiché au milieu revient dans l’état spécifié.

Il est bien sûr possible de lancer les tests sans ouvrir cette fenêtre interactive, avec la commande « npx cypress run ». Les tests se jouent alors en mode headless.

En fait, c’est comme si Cypress avait voulu prendre le meilleur de Selenium Webdriver et Selenium IDE (oui, car Selenium IDE a des atouts, et si vous pensez que non c’est que vous n’avez peut-être pas appris ce qui lui est arrivé ces dernières années !).

Sa gestion du temps

Vitesse d’exécution

Cypress est réputé notamment pour sa rapidité, et d’après nos quelques essais, cela semble mérité !

Attente des éléments

Le fait que l’outil gère tout seul l’attente des différents éléments de l’interface est extrêmement confortable.

Voyage dans le passé

Le fait de pouvoir « rembobiner » le test dans l’interface de lancement interactif est aussi très pratique. On peut ainsi savoir exactement à quel moment a eu lieu l’erreur, et se rejouer ce moment à volonté, en ayant en plus accès à l’inspecteur du navigateur !

Ses captures vidéo

Certes, avec Selenium il est possible de se débrouiller pour prendre des screenshots et des captures vidéo, de les stocker où on veut, etc. Ce que Cypress apporte nativement, c’est des enregistrements de vidéos de tous les tests joués, qui sont enregistrés dans un dossier dédié (avec la commande « npx cypress run »). Les vidéos sont nommées à partir du titre des scripts de test, bien clairement. Le dossier des vidéos est par défaut purgé à chaque lancement, mais il est possible de paramétrer cela (toutes les infos ici).

Et ce qui est vraiment sympa, c’est que les vidéos montrent le même panneau d’exécution que dans la fenêtre interactive. On reste dans le cockpit en toutes situations !

Cypress offre quelques possibilités de configuration de cette fonctionnalité.

Ses screenshots

En cas d’échec, un screenshot est aussi automatiquement pris (toujours avec la commande « npx cypress run ») et stocké dans un dossier dédié. Les paramètres de configuration sont listés ici.

De même que pour les vidéos, on voit à la fois l’écran du système à tester et l’interface de lancement, ce qui permet de visualiser quelle erreur a été détectée.

Sur l’exemple ci-dessous, le jeu de données du test génère un faux positif : on attend une page d’accueil avec un H1, mais on reste sur la page de connexion.

Son DSL

Le DSL de Cypress s’appuie sur Chai, qui est particulièrement bien fourni. Nul besoin de créer ses propres fonctions pour vérifier le texte d’un élément, la valeur d’un de ses attributs, la longueur d’une liste d’éléments, et bien d’autres choses encore. Dépendamment de l’IDE utilisé, l’autocomplétion rend la tâche particulièrement réjouissante. Ceci étant dit, n’oublions pas qu’il est aussi possible d’intégrer Chai à Selenium (au parfum JavaScript) et de profiter de ses fonctionnalités.

Cypress ajoute cependant certaines commodités : la syntaxe {enter} (qui permet de simuler un appui sur la touche « Entrée »), {pageup}, {selectall}… Tout est listé ici. Par exemple, on pourrait valider un formulaire aussi simplement que ça : cy.get(‘#input-password).type(« un password incorrect{enter} »);

A l’inverse, quels sont les défauts de Cypress ?

« Il n’y a ni défauts ni qualités, seulement des caractéristiques. » -Un vieux sage

Cypress a une page dédiée à ses limitations, qui sont plutôt présentées comme des choix fonctionnels assumés (on ne peut pas tout faire !) Les voici donc en bon français.

Son périmètre réduit

Ce n’est pas forcément un défaut mais c’est bien d’avoir ça en tête. Cypress n’est pas un outil d’automatisation généraliste. Il se distingue en cela de Selenium, dont la phrase d’introduction est « Selenium automate browsers. That’s it! What you do with that power is entirely up to you. »

Celle de Cypress est plus ciblée : « Cypress can test anything that runs in a browser. »

Sa dépendance au navigateur

Les commandes Cypress tournent dans le navigateur. Cela implique que les contraintes liées au navigateurs doivent être prises en compte en plus des contraintes liées à Cypress même. Notamment, cela complique (un peu) les interactions avec le back-end et les bases de données, mais cela reste tout de même possible.

Sa politique « 1 test = 1 navigateur, 1 onglet, 1 domaine et 1 port »

Cypress ne prévoit pas de gérer plusieurs onglets de navigateurs au sein d’un test, ni de permettre d’utiliser plusieurs navigateurs au sein d’un même test, ni d’interagir avec plus d’un domaine au sein d’un même test, ni plus d’un port de cette adresse. Cela peut être problématique pour jouer certains tests de bout en bout. Noter toutefois qu’il est possible d’interagir avec des sous-domaines différents d’un même nom de domaine.

Sa gestion des iframes

A l’heure actuelle, la gestion des iframes n’est pas simple. Ça peut être un peu embêtant (dans le cas d’un champ de texte riche, comme CKEditor), ou carrément critique (si l’interface de l’application se présente comme une série d’iframes en poupées russes).

C’est donc un point à bien avoir en tête avant de se lancer. En revanche, ne baissons pas les bras, d’autres se sont penchés sur le problème avant nous et ont trouvé des moyens de contournement.

Alors, verdict ?

L’envie était grande de crier à l’effet de mode et d’écrire une nouvelle ode à notre très cher Selenium. Mais face à tant de belles fonctionnalités, il est drôlement tentant de vouloir aller plus loin. Certes, cet article témoigne d’un début d’exploration, il y a sans doute de vilaines embûches que nous n’avons pas encore rencontrées. Quoi qu’il en soit, longue vie à Cypress et bon courage à tous les automaticien.ne.s qui nous lisent, que vous soyez gaga de Selenium, de Cypress, ou des deux !

Bonus : un mot des diplômés de la Wild Code School

Cypress est un outil enseigné à la Wild Code School au sein de la formation des QA. Comme l’indique Mimoun Kissi, responsable pédagogique de cette formation, « Cypress occupera une grande place dans le monde de l’automatisation. Sa facilité d’installation est un élément essentiel pour être utilisé par des profils juniors ou avec des compétences de bases en programmation. » Nous avons rencontré 3 diplômés de la promotion 2020 afin qu’ils nous donnent leur point de vue sur cet outil : Devillers Poaty-Meaty, Soufiane Hannane et Boussad Ouaked.

Selenium VS Cypress

A choisir entre Selenium et Cypress, les trois testeurs interrogés sont unanimes ; Cypress les a séduits par sa simplicité d’installation et de configuration. Devillers Poaty-Meaty explique : « Avec quelques lignes de commandes, je peux lancer mon projet et je peux en plus effectuer des tests d’API et charger les données de test à partir d’une source. »

S’il fallait changer quelque chose à Cypress

Soufiane Hannane rappelle que Cypress supporte simplement le JavaScript, et que cela pourrait pénaliser une personne plutôt habituée à d’autres langages. Il souligne également le fait que Cypress ne soit pas encore compatible avec Internet Explorer et Safari.

Les challenges liés à Cypress

Les trois testeurs mentionnent des challenges liés à la nature même de Cypress, qui n’est pas un outil codeless. Bien qu’il soit simple d’installation et de configuration, et qu’il permette nativement d’éviter un certain nombre de faux positifs, il nécessite un temps de prise en main, en particulier pour concevoir un projet maintenable et scalable (et c’est important…).

Ce temps d’apprentissage est indispensable aussi bien pour des profils débutant en JavaScript, que par exemple pour Boussad Ouaked, qui avait déjà réalisé des projets de développement en utilisant ce langage.

Merci à eux pour ces témoignages !

_____________________________________________

L’automatisation des tests vous intéresse, vous intrigue ou vous passionne ? Ce récap est là pour vous fournir une vue d’ensemble sur ce sujet.

Bâtir sa qualité de code avec les ateliers craft de Promyze

Si les logiciels étaient des personnages de la mythologie grecque, SonarQube serait sans doute Cassandre. De même que cette princesse troyenne ne trouvait jamais d’oreille attentive à ses prophéties, il existe des instances SonarQube qui besognent vaillamment sur des serveurs oubliés, sans que les innombrables défauts qu’ils identifient ne soient jamais étudiés.

Bonne nouvelle, des solutions existent ! Et Promyze (anciennement Themis), outil phare de la société du même nom, offre bon nombre de fonctionnalités permettant d’animer de manière agile et collaborative ce sujet glissant qu’est la qualité de code. Dans cet article, nous parlerons en particulier du tout nouveau module de l’applicatif, les Ateliers Craft. Un module qui a été testé par Testeum, mais c’est une autre histoire !

Les Ateliers Craft, comment ça marche ?

Les Ateliers Craft se présentent un peu comme des salles de travail numériques dans lesquelles on peut entrer et sortir à sa guise. La collaboration s’y déroule de manière asynchrone, selon une fréquence déterminée (mensuelle ou hebdomadaire).

Que se passe-t-il dans ces ateliers ? Quelques fichiers, par défaut les 5 ayant été les plus modifiés récemment, sont posés sur la table. Chaque participant effectue une revue de ces fichiers, et met en exergue les passages qu’il trouve les plus exemplaires, ou au contraire les plus risqués. Pour ce faire, par un système de drag’n’drop, on associe les bouts de code à des étiquettes correspondant à des bonnes pratiques.

A la fin de la session, un bilan de l’atelier est dressé. Les extraits sélectionnés par les participants peuvent être conservés afin d’illustrer les bonnes pratiques de manière pérenne.

Comment sont déterminées les bonnes pratiques ?

Quelques bonnes pratiques généralistes et consensuelles sont proposées par défaut par Promyze. Il est possible de les supprimer, et surtout d’en ajouter de nouvelles : celles propres à notre organisation.

A vous de formaliser par exemple si l’anglais, le français voire le franglais sont à privilégier dans le nommage, et de créer une bonne pratique intitulée, disons, “Respect de la langue”. Au sein d’un atelier craft, vous aurez ensuite la possibilité de placer l’étiquette de bonne pratique “Respect de la langue” juste au-dessus de la méthode getSizeListeElements() présente dans un fichier, pour indiquer si c’est un bon nommage ou non.

Facteurs de réussite

Votre équipe est déjà sensibilisée à l’esprit de Software Craftmanship ? Vous devriez vous régaler. Dans le cas contraire, il est important de garder à l’esprit que le but de Promyze est de construire collectivement, et dans un esprit de confiance et d’humilité, la qualité de code de son organisation. Sa vocation n’est pas de permettre de pointer du doigt les fauteurs de bugs. Ce sont des Ateliers Craft, pas Cafte… Chaque personne contribue via son expérience personnelle, son parcours, ses connaissances techniques, et tout le monde interagit ensemble. Les Ateliers sont des sessions à ritualiser dans les équipes, il est donc important, surtout au démarrage, que des personnes soient identifiées comme des leaders sur le sujet pour créer et animer les premiers ateliers.

Conclusion

Nous avons beaucoup aimé découvrir Promyze. La convivialité de l’expérience et la possibilité de personnaliser les bonnes pratiques sont des atouts très intéressants. Ca donne envie de s’y mettre, en complément des autres fonctionnalités de Promyze, comme les plans d’actions automatiques et les suggestions personnalisées qui facilitent la mise en oeuvre d’une stratégie d’amélioration continue.

La gamification de la gestion de la dette technique identifiée par SonarQube (entre autres) est également une partie qui nous intéresse beaucoup (nous avons écrit une série d’articles sur le sujet !).

Aaaaah on les veut toutes !!!!!!

Au fait, pour finir, saviez-vous pourquoi personne ne croyait Cassandre ? Apollon, qui lui avait donné son précieux don de prophétie, espérait de sa part quelque remerciement grivois. Comme elle refusa, vengeur, il lui cracha dans la bouche (beurk). Un crachat qui lui ôta toute capacité de persuasion. Si Themis, déesse de la justice, avait été dans le coin, elle aurait peut-être rappelé les rudiments du consentement au capricieux Apollon… et rendu la parole à Cassandre. La boucle est bouclée !

La semaine prochaine, nous resterons avec Promyze, qui répondra à quelques question sur les Ateliers Craft. N’hésitez pas à en poser en commentaire d’ici-là !

Crédit images

Lego computer, Matt Brown

Cassandre, peinture d’Evelyn de Morgan, 1898

Promyze

TestMethodOrder : un coup de pouce à utiliser avec précaution

JUnit et son ordre fantasque

Dans certains contextes techniques, nous pouvons choisir simplement l’ordre d’exécution des tests automatisés. Par exemple, Test Batch Runner permet de lancer une suite de tests UFT selon l’ordre indiqué dans le fichier mtb (modular test batch) associé.

En revanche, quand on utilise JUnit, par défaut, ce n’est pas le cas. Le nom des méthodes de test sont hashées, puis les tests sont lancés par ordre alphabétique de hash. Nous nous retrouvons donc à chaque fois avec le même ordre d’exécution, mais à première vue celui-ci ne rime à rien. Ça peut même être assez agaçant au début quand on découvre l’outil !

Un test d’indépendance

Si vos tests autos respectent une des bonnes pratiques capitales en la matière, à savoir qu’ils sont tous indépendants les uns des autres, cela ne devrait cependant pas vous poser problème. En principe, ils devraient pouvoir être joués dans n’importe quel ordre.

Le fait que JUnit lance les tests dans cet ordre particulier peut donc être apprécié, et utilisé comme une manière de vérifier que les tests sont bien indépendants les uns des autres. Du coup, pourquoi ne pas aller encore plus loin ?

Soyons encore plus fous

Pour aller au bout de la logique, nous pourrions décider de jouer les tests dans n’importe quel ordre, cet ordre pouvant changer à chaque exécution. Pour cela, nous allons nous baser non plus sur le hash des noms de méthodes, mais sur l’ordre d’exécution de la JVM, qui n’est pas fixe. Pour ce faire, ajouter simplement « @FixMethodOrder(MethodSorters.JVM) » juste au-dessus de votre classe de test. Cette solution est compatible avec JUnit 4.

@FixMethodOrder(MethodSorters.JVM)
public class TestExemple {

    @Test
    public void test001(){
        System.out.println("1");
    }

    @Test
    public void test002(){
        System.out.println("2");
    }

    @Test
    public void test003(){
        System.out.println("3");
    }

}

Vos tests se joueront maintenant dans n’importe quel ordre, ce qui vous permettra de prouver qu’ils sont vraiment indépendants.

Un ordre fixe

Maintenant, il peut arriver que vous ayez besoin de lancer les tests dans un certain ordre. Si tel est le cas, il suffit simplement de remplacer « MethodSorters.JVM » par « MethodSorters. NAME_ASCENDING », et de ranger les tests par ordre alphabétique en fonction de l’ordre voulu. Cette solution est compatible avec JUnit 4.

D’autres méthodes sont arrivées avec JUnit 5. Par exemple, ceci affichera 1, 2, puis 3, en se basant sur les annotations @Order :

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)

public class TestExemple {

    @Test
    @Order(2)
    public void ccc(){
        System.out.println("2");
    }

    @Test
    @Order(1)
    public void bbb(){
        System.out.println("1");
    }

    @Test
    @Order(3)
    public void aaa(){
        System.out.println("3");
    }
}

Pour conserver un ordre alphabétique et ne pas s’encombrer d’annotations, la syntaxe suivante peut être suivie :

@TestMethodOrder(MethodOrderer.Alphanumeric.class)

public class TestTmp {

    @Test
    public void bbb(){
        System.out.println("2");
    }

    @Test
    public void ccc(){
        System.out.println("3");
    }

    @Test
    public void aaa(){
        System.out.println("1");
    }

}

Celle-ci affichera 1, 2, puis 3.

Quelle que soit la notation choisie, si vous optez pour cette logique, pesez bien le pour et le contre avant de vous lancer.

Exemple de mauvaise utilisation

Une rangée de dominos peut tenir debout pendant des années. Mais il suffit que l’inscription de Boniface07 se déroule avec un petit accroc pour que tous les tests de cette classe se retrouvent en échec.

FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class TestExemple extends MaSuperAppliWebTest {

    @Test
    public void test001_inscriptionUtilisateur(){
        accesURL("https://masuperappliweb.com/inscription");
        inscription("Boniface07", "password");
        verifierMessageConfirmationInscription();
    }

    @Test
    public void test002_premiereConnexionUtilisateur(){
        accesURL("https://masuperappliweb.com/connexion");
        connexion("Boniface07", "password");
        verifierPageAccueilAffichee();
    }

    @Test
    public void test003_configurationCompte(){
        accesURL("https://masuperappliweb.com/connexion");
        connexion("Boniface07", "password");
        configurerCompte();
        verifierCompteBienConfigure();
    }

}

Un exemple de motif recevable

Le test X a besoin d’un jeu de données. Celui-ci peut être rapidement créé via une IHM, mais un traitement en back-office durant environ 15 minutes doit être effectué. Nous n’avons pas envie de gaspiller 15 précieuses minutes à attendre la fin de ce traitement ! Nous lançons donc cette création de données au début, nous jouons une flopée de tests ensuite, et seulement à la fin, le test devant utiliser le jeu de données. Des commentaires clairs font état de cette dépendance exceptionnelle. On pourrait même dire qu’on est en présence d’un seul scénario coupé en deux méthodes de test.

Ce n’est pas le seul motif recevable, mais cet exemple montre que cela doit rester exceptionnel et justifié.

A bientôt et bonne automatisation des tests !

Les Relative Locators de Selenium 4 : cas d’usage

16 ans déjà que Selenium existe ! Première version en 2004, Selenium 2 en 2011, Selenium 3 en 2016, et depuis le printemps 2019 il est déjà possible de s’amuser avec Selenium 4. Toujours en version alpha en février 2020, cette nouvelle mouture propose entre autres une nouvelle manière d’identifier les éléments d’une page web : les Relative Locators. Vous qui avez à coeur de faire de la veille sur les outils de test automatisé, c’est le moment de découvrir cette nouvelle fonctionnalité !

Que sont les Relative Locators ?

Vous connaissiez déjà les multiples manières proposées par Selenium pour identifier les objets : par attribut « id » ou « name », par « tag » (balise HTML), par xPath et par sélecteur CSS.

En plus de ces différentes manières, il est désormais possible de sélectionner des élément en fonction de leur position par rapport à d’autres éléments. Par exemple : l’image qui se trouve en-dessous du menu, le lien qui se trouve à gauche du logo, le bouton qui se trouve près (moins de 50 pixels) du footer. Seul l’élément par rapport auquel on se positionne nécessite un sélecteur ; pour l’élément cible, on n’indique que le nom de sa balise HTML.

Exemple de Relative Locator

// Avant
WebElement imageEnDessousDuMenu = driver.findElement(By.xpath("//div[@id=’menu’]//..//img")); // Ca ne vérifie pas que l’image est en-dessous du menu, juste qu’ils ont le même parent, par exemple une div

// Après
WebElement imageEnDessousDuMenu = driver.findElement(withTagName("img").below(By.id("menu")));

Les Relative Locators devaient d’abord s’appeler « Friendly Locators », et on comprend pourquoi : en intégrant dans le framework des notions visuelles, le code peut devenir plus simple à lire.

Sans vouloir jouer les trouble-fêtes…

Pour autant, nous n’avons pas réussi à nous souvenir de cas où ces localisateurs nous auraient vraiment sauvé la vie. Jusqu’à présent, nous avons toujours pu trouver des solutions satisfaisantes et robustes se basant sur les localisateurs historiques. Alors, les Relative Locators seraient-ils un ajout « sympa mais pas si utile » ?

Peut-on maintenant vérifier la position des éléments ?

Alors… si, il y a bien quelque chose qui pourrait être très utile : ce serait de vérifier la position relative d’un élément par rapport à un autre.

Comment ça, ce n’est pas ce qu’on vient de faire ?

Hé non, pas tout à fait. Certes, à chaque fois que notre code Selenium interagit avec un élément, cela nous permet de savoir qu’il existe. Pour autant, si le localisateur de notre « imageEnDessousDuMenu » renvoie une erreur « NoSuchElementException », on ne saura pas si c’est parce qu’il n’y a pas d’image sur la page, si le menu a changé d’ID, ou s’il y a bien la bonne image mais qu’elle n’est plus en-dessous mais au-dessus. Et parfois, on a besoin de savoir précisément si tel élément est bien situé par exemple à un autre. Par exemple, quand on teste le caractère responsive d’une page web.

Nous pensions que Selenium 4 arriverait avec des méthodes pratiques facilitant les assertions, du genre isElementBelow(WebElement unAutreElement), mais ce n’est pas (encore ?) le cas.

Cependant, il est bien sûr possible de s’en sortir avec des méthodes sur mesure.

Ce qui nous amène à notre exemple de mise en application !

Test de position des éléments avec Selenium 4

Cas d’usage : plein écran et demi-écran

Je visite le site https://service-public.nc/ depuis mon ordinateur portable, dont le système d’exploitation est Windows 10. La fenêtre de mon navigateur est au maximum. Ce que je lis est intéressant, je voudrais prendre des notes : je fais basculer mon navigateur en mode demi-écran, pour avoir le bloc-notes sur l’autre partie de l’écran.

Sur la page d’accueil du menu « Particuliers », en plein écran, les blocs se présentent ainsi :

En responsive, les blocs se réorganisent. Je souhaite évidemment que les éléments du site soient visibles et cohérents dans les deux affichages.

Vues différenciées

Vue desktop

Vue « demi-desktop »

Assertions à faire

Dans notre test automatisé Selenium 4, nous allons vérifier les assertions suivantes.

En mode desktop :

  • Le titre « Particuliers » est au-dessus de l’article 1
  • Le titre « Particuliers » est à la même abscisse (X) que l’article 1
  • Le titre « Particuliers » est à la même ordonnée (Y) que le bloc « Vos services en un clic »
  • Le titre « Particuliers » est à gauche du bloc « Vos services en un clic »
  • L’article 1 est à la même ordonnée (Y) que l’article 2
  • L’article 1 est à gauche de l’article 2.

En mode « demi-desktop » :

  • Le titre « Particuliers » est au-dessus de l’article 1 (ça ne change pas)
  • Le titre « Particuliers » est à la même abscisse (X) que l’article 1 (ça ne change pas)
  • Le titre « Particuliers » est au-dessus du bloc « Vos services en un clic »
  • Le titre « Particuliers » est à la même abscisse (X) « Vos services en un clic »
  • L’article 1 est au-dessus de l’article 2
  • L’article 1 est à la même abscisse (X) que l’article 2.

Allez, c’est parti !

Des méthodes de bas niveau pour vérifier la position des éléments

A gauche, à droite en haut ou en bas ?

A l’aide d’un enum, on liste seulement deux possibilités, histoire d’homogénéiser les choses dès le début. On n’a pas envie de se demander si c’est le menu X qui est à gauche du formulaire Y ou si c’est le formulaire Y qui est à gauche du menu X…

    public enum POSITION {
        A_GAUCHE_DE,
        AU_DESSUS_DE
    }

On utilise ensuite cet enum dans une méthode de bas niveau. Attention, cette méthode utilise l’objet « Selecteur » ; vous ne le connaissez peut-être pas encore, mais nous vous recommandons d’en créer un pour vos projets (pour plus d’infos, rendez-vous sur ce précédent article, qui explique les avantages du Selecteur).

On vérifie 3 choses dans cette méthode :

  • Premièrement, que les deux éléments existent
  • Deuxièmement, qu’il y a au moins un élément du même type que l’élément 1 dans la position souhaitée par rapport à l’élément 2
  • Troisièmement, que l’élément 1 fait partie de ces éléments

A chaque vérification son message d’erreur spécifique.

Attention, la méthode ne vérifie pas si l’élément 1 est le seul à répondre au critère, ni s’il est le plus proche. A vous de voir si ce niveau de contrôle vous suffit, ou si vous souhaitez le renforcer.

    public void verifierPosition(String tagElement1, Selecteur element1, POSITION position, Selecteur element2){
        // Vérification 1
        Assert.assertTrue(element1.getNom() + " aurait dû être présent(e)", driver.findElements(element1.getChemin()).size() != 0);
        Assert.assertTrue(element2.getNom() + " aurait dû être présent(e)", driver.findElements(element2.getChemin()).size() != 0);

        // Vérification 2
        List<WebElement> elementsMemeTypeMemePositionRelative = null;
        if(position == POSITION.A_GAUCHE_DE) {
            elementsMemeTypeMemePositionRelative = driver.findElements(withTagName(tagElement1).toLeftOf(element2.getChemin()));
        } else if (position == POSITION.AU_DESSUS_DE) {
            elementsMemeTypeMemePositionRelative = driver.findElements(withTagName(tagElement1).above(element2.getChemin()));
        }

        Assert.assertTrue("au moins un élément " + tagElement1 + " aurait dû être présent à la position relative souhaitée (" + position.name() + ") par rapport à l'élément suivant : " + element2.getNom() + ")",
                elementsMemeTypeMemePositionRelative.size() >= 1);

        // Vérification 3
        WebElement webElement1 = driver.findElement(element1.getChemin()); //
        Assert.assertTrue(element1.getNom() + " aurait dû être affiché(e) dans la bonne position (" + position.name() + ") par rapport à l'élément suivant : " + element2.getNom(), elementsMemeTypeMemePositionRelative.contains(webElement1));
    }

Au passage, avez-vous repéré les méthodes Selenium 4, toLeftOf() et above() ? 🙂

Libre à vous ensuite de surcharger cette méthode de bas niveau afin d’améliorer la lisibilité de votre code :

    public void verifierElementAGaucheDe(String tagElement1, AbstractPage.Selecteur element1, AbstractPage.Selecteur element2){
        verifierPosition(tagElement1, element1, AbstractPage.POSITION.A_GAUCHE_DE, element2);
    }

    public void verifierElementAuDessusDe(String tagElement1, AbstractPage.Selecteur element1, AbstractPage.Selecteur element2){
        verifierPosition(tagElement1, element1, AbstractPage.POSITION.AU_DESSUS_DE, element2);
    }

Même abscisse ou même ordonnée

On commence encore d’abord par un enum pour déclarer les deux axes possibles :

    public enum AXE {
        ABSCISSE_X,
        ORDONNEE_Y
    }

On a encore 3 vérifications :

  • Les deux éléments existent
  • Il y a au moins un élément du même type que l’élément 1 qui ne soit ni à gauche ni à droite (ou ni en haut ni en bas) de l’élément 2
  • L’élément 1 fait partie de ces éléments
public void verifierMemeAxe(AXE axe, String tagElement1, AbstractPage.Selecteur element1, Selecteur element2){
    Assert.assertTrue(element1.getNom() + " aurait dû être présent(e)", driver.findElements(element1.getChemin()).size() != 0);
    Assert.assertTrue(element2.getNom() + " aurait dû être présent(e)", driver.findElements(element2.getChemin()).size() != 0);

    List<WebElement> elementsMemeType = driver.findElements(withTagName(tagElement1));
    if(axe == AXE.ABSCISSE_X){
        // Là, on liste les éléments à gauche et à droite de notre élément (ceux qui ont un X différent)
        List<WebElement> elementsAGauche = driver.findElements(withTagName(tagElement1).toLeftOf(element2.getChemin()));
        List<WebElement> elementsADroite = driver.findElements(withTagName(tagElement1).toRightOf(element2.getChemin()));
        // On supprime de notre liste initiale tous les élements qui ont un X différent de notre élément
        elementsMemeType.removeAll(elementsAGauche);
        elementsMemeType.removeAll(elementsADroite);
    } else if (axe == AXE.ORDONNEE_Y) {
        List<WebElement> elementsAuDessus = driver.findElements(withTagName(tagElement1).above(element2.getChemin()));
        List<WebElement> elementsEnDessous = driver.findElements(withTagName(tagElement1).below(element2.getChemin()));
        elementsMemeType.removeAll(elementsAuDessus);
        elementsMemeType.removeAll(elementsEnDessous);
    }
    Assert.assertTrue("au moins un élément " + tagElement1 + " aurait dû être présent à la même " + axe.name() + " que l'élément suivant : " + element2.getNom() + ")", elementsMemeType.size() >= 1);
    WebElement webElement1 = driver.findElement(element1.getChemin());
    Assert.assertTrue(element1.getNom() + " aurait dû être affiché(e) avec la même " + axe.name() + " que l'élément suivant : "
            + element2.getNom(), elementsMemeType.contains(webElement1));
}

Et les méthodes « surchargeantes » :

    public void verifierElementMemeOrdonnee(String tagElement1, Selecteur element1, Selecteur element2){
        verifierMemeAxe(AXE.ORDONNEE_Y, tagElement1, element1, element2);
    }

    public void verifierElementsMemeAbscisse(String tagElement1, Selecteur element1, Selecteur element2){
        verifierMemeAxe(AXE.ABSCISSE_X, tagElement1, element1, element2);
    }

Résultat final !

On a désormais tout ce qu’il nous faut pour effectuer automatiquement les vérifications évoquées plus haut. Et les voilà, au sein d’un objet page (encore une fois si ce concept ne vous parle pas, rendez-vous sur cet article qui explique l’intérêt d’avoir des objets page) :

public class ServicePublicPage extends AbstractPage {

    private final Selecteur ongletParticuliersMenu = new Selecteur("l'onglet 'Particuliers' du menu", By.xpath("//a[contains(., 'Particuliers')]"));
    private final Selecteur titreParticuliers = new Selecteur("le titre 'Particuliers'", By.id("page-title"));
    private final Selecteur blocVosServices = new Selecteur("le bloc intitulé 'Vos services en un clic'", By.id("block-gnc-services-services-menu"));
    private final Selecteur blocSanteSocial = new Selecteur("le bloc intitulé 'Santé - Social'", By.xpath("//article[contains(., 'Santé - Social')]"));
    private final Selecteur blocTravail = new Selecteur("le bloc intitulé 'Travail'", By.xpath("//article[contains(., 'Travail')]"));

    public void accesPartieParticuliers(){
        clickElement(ongletParticuliersMenu);
    }

    public void verifierMenuDesktop(){
        driver.manage().window().maximize();
        verifierElementAuDessusDe("h1", titreParticuliers, blocSanteSocial);
        verifierElementsMemeAbscisse( "h1", titreParticuliers, blocSanteSocial);
        verifierElementMemeOrdonnee( "h1", titreParticuliers, blocVosServices);
        verifierElementAGaucheDe("h1", titreParticuliers, blocVosServices);
        verifierElementMemeOrdonnee( "article", blocSanteSocial, blocTravail);
        verifierElementAGaucheDe( "article", blocSanteSocial, blocTravail);
    }


    public void verifierMenuDesktop_demiEcran(){
        driver.manage().window().maximize();
        int largeurEcran = driver.manage().window().getSize().width;
        int hauteurEcran = driver.manage().window().getSize().height;
        driver.manage().window().setSize(new Dimension(largeurEcran/2, hauteurEcran));
        verifierElementAuDessusDe("h1", titreParticuliers, blocSanteSocial);
        verifierElementsMemeAbscisse( "h1", titreParticuliers, blocSanteSocial);
        verifierElementAuDessusDe("h1", titreParticuliers, blocVosServices);
        verifierElementsMemeAbscisse( "h1", titreParticuliers, blocVosServices);
        verifierElementAuDessusDe( "article", blocSanteSocial, blocTravail);
        verifierElementsMemeAbscisse( "article", blocSanteSocial, blocTravail);
    }

}

Maintenant, vous n’avez plus qu’à utiliser ces méthodes dans vos tests !

public class testServicePublicNC extends AbstractTest {

    @DisplayName("Vérifier l'ordre du menu en mode desktop")
    @Test
    public void verifierOrdreMenu_desktop(){
        ServicePublicPage servicePublicPage = new ServicePublicPage();
        servicePublicPage.accesPartieParticuliers();
        servicePublicPage.verifierMenuDesktop();
    }

    @DisplayName("Vérifier l'ordre du menu en mode desktop - demi-écran")
    @Test
    public void verifierOrdreMenu_desktop_demiEcran(){
        ServicePublicPage servicePublicPage = new ServicePublicPage();
        servicePublicPage.accesPartieParticuliers();
        servicePublicPage.verifierMenuDesktop_demiEcran();
    }

}

Bonus : si vous devez attendre avant de monter de version

N’oublions pas que Selenium 4 est encore en version Alpha. En attendant qu’une version stable soit livrée, et si vous en avez besoin dans vos projets actuels, il est déjà possible de réaliser les vérifications évoquées dans l’article. Cet article fournit un tutoriel très clair, en Java également.

Test Automation University en 12 questions – réponses

1) Qu’est-ce que Test Automation University ?

Test Automation University est un service en ligne gratuit de formation à l’automatisation des tests. Il est rapidement devenu un grand classique dans le domaine de l’automatisation des tests.

2) Comment se déroulent les formations ?

Les cours se présentent comme des séries de vidéos et de textes, qui donnent lieu à des QCM réguliers. Des références complémentaires sont citées au sein des cours de façon à donner des pistes d’approfondissement.

Attention, vous ne pourrez plus accéder au contenu des questions une fois que vous aurez obtenu les résultats des QCM !

3) Les formations Test Automation sont-elles certifiantes ?

Un certificat nominatif est généré à la fin de chaque formation. La notation est généreuse, donc ne surestimez pas la valeur de tels certificats ! Toutefois, ils seront certainement utiles pour mettre en valeur la curiosité d’un candidat : si vous êtes en démarche de reconversion (de développeur à QA par exemple), c’est une piste intéressante qui donnera du corps à votre CV. N’oubliez pas également de jeter aussi un œil à notre article « Comment devenir QA » !

4) Combien de temps durent les formations ?

C’est très variable, mais sachez que certains cours peuvent être suivis en entier en moins d’une heure. Par exemple, « AI for Element Selection: Erasing the Pain of Fragile Test Scripts » se compose de 3 vidéos pour un total d’environ 30 minutes.

5) Qui sont les formateurs ?

Là, c’est une merveilleuse surprise. La plateforme est un projet porté par la société Applitools, on pourrait donc s’attendre à du contenu austère et dogmatique issu d’un quelconque éditeur en mal de visibilité. Ce n’est pas du tout le cas. Les formateurs sont tous des experts reconnus dans le monde du test, et sont indépendants les uns des autres. Comme indiqué dans le « cours » de présentation de la plateforme, l’esprit du site est de mettre en valeur une grande diversité de façons de voir l’automatisation des tests. Et ça fonctionne !

De notre côté, nous avons reconnu avec plaisir quelques-uns d’entre eux, dont Jason Arbon, un des co-auteurs de How Google Tests Software (dont nous parlions dans notre article sur les plans de test), et Dave Haeffner, auteur du blog Elemental Selenium, dont nous recommandons la newsletter.

6) Que faut-il attendre du Slack associé ?

Fin juin 2019, ce Slack comptait non moins de 1591 inscrits, pour un total de 6470 messages répartis sur 25 chaînes.

Certaines chaînes ont des thématiques générales, d’autres portent sur des cours de la plateforme. Les formateurs répondent directement aux questions des apprenants.

Quelques questions générales de testing donnent lieu à des discussions entre testeurs (sur des choix d’outils notamment). Certains partagent des ressources en rapport avec le contenu des cours (ce qui nous a permis notamment de découvrir ce joli petit exercice d’entraînement aux sélecteurs CSS, CSS Diner). Cette plateforme deviendra certainement plus active au fil du temps ; en tout état de cause, il y règne déjà une ambiance conviviale et sympathique.

Un canal de ce Slack se consacre uniquement aux petites anomalies présentes sur la plateforme !

7) Les formations sont-elles accessibles aux débutants ?

Sur la page d’accueil, on peut classer les cours de Test Automation University par niveau de difficulté ou par thématique. Les cours débutants sont accessibles aux « grands débutants », surtout si l’on tient compte de la communauté Slack qu’on peut solliciter en cas de problème.

Par exemple, le cours « Web Element Locator Strategies » (un sujet sur lequel nous vous avons mis à l’épreuve !) revient aux fondamentaux : structure des pages web, rôle du HTML, du CSS et du JavaScript, différence entre éléments et sélecteurs… Ce qui en fait un contenu accessible à tous.

8) La plateforme met-elle en œuvre de la gamification ?

A un niveau basique, oui, la plateforme propose une petite surcouche de gamification qui plaira à certains. Au fur et à mesure qu’il gagne des crédits en répondant correctement aux questionnaires, l’utilisateur progresse de niveau en niveau (de « licorne » à « kraken »). En revanche, ces niveaux ne donnent lieu à aucun privilège (fonctionnalités supplémentaires par exemple).

Sur la page de l’utilisateur se trouvent ses badges (un badge par cours, plus à l’heure actuelle un badge spécial) ainsi qu’un camembert représentant l’avancée globale de l’utilisateur sur la plateforme.

EDIT du 14/02/2022 : si vous vous intéressez au sujet de la gamification, vous aurez peut-être plaisir à découvrir notre série d’articles sur le sujet ! Voir le premier de cette série : « Pourquoi gamifier le métier du test logiciel ? »

9) Les vidéos ont-elles une transcription ?

Oui, et elles sont vraiment bien. Elles ne contiennent pas seulement le script que l’on peut entendre dans la vidéo, mais aussi le code qui s’affiche à l’écran (au format texte avec une bonne mise en forme). On peut donc noter un effort d’accessibilité.

10) Test Automation University est-il disponible en français ?

Tout le contenu du site est pour le moment en anglais.

11) Est-ce gratuit ?

Oui, et sans publicité envahissante. A l’heure actuelle il n’y a qu’un lien sponsorisé en bas de la page d’accueil. Les vidéos hébergées sur Youtube vous occasionneront peut-être quelques pubs par-ci par-là, mais cela n’est pas du ressort de la plateforme.

12) Les contenus sont-ils récents ?

À l’heure où nous écrivons cet article, oui ! Le service a vu le jour le 1er premier janvier 2019, avec un premier cours : « Setting the Foundation for Successful Test Automation ».

La plateforme est en effervescence, de nouveaux cours apparaissent quasiment chaque semaine.

Nous avons beaucoup aimé découvrir ce site et lui souhaitons de rencontrer tout le succès qu’il mérite.