Pourquoi gamifier le métier du test logiciel ?

En 2020, nous avons proposé une intervention à la Paris Test Conf sur un sujet qui nous tient à cœur depuis des années : la gamification. Vous l’avez d’ailleurs peut-être remarqué au fil des articles de ce blog : nous avons lancé un bingo permettant d’échanger sur les échecs fréquents lors des recettes, un jeu de plateau permettant de terminer un projet en beauté, ou encore un jeu de cartes permettant de sensibiliser aux tests unitaires.

Nous appréhendons la gamification comme l’art d’implémenter notamment dans notre activité professionnelle des ressorts motivationnels tels que l’on peut en trouver dans les jeux.

Si vous voulez vous replonger dans l’ambiance de la conférence, vous trouverez le replay en fin d’article. Ce sera d’ailleurs l’occasion de découvrir bien d’autres talks, animés par des personnes aussi talentueuses que passionnées ! Si vous préférez lire, vous trouverez au sein de cette série d’articles tous les points les plus importants de la présentation.

  1. Pourquoi gamifier le métier du test logiciel ?
  2. Chevaliers de la qualité ou esclaves des anomalies ?
  3. Tester pour le plaisir ou pour la gloire ?
  4. Le test, ma team et mes bugs
  5. Traqueurs de bugs ou explorateurs de la qualité ?

Merci à toute l’équipe d’organisation de la Paris Test Conf, en particulier à Diana Marimoutou pour ses bons conseils et son suivi assidu, ainsi qu’au public qui a bravé le sommeil pour s’adonner à la passion du test !

Gamification : au-delà des clichés

Le Robert définit la gamification (ou en bon français, ludification) comme suit : « Application de mécanismes ludiques à ce qui ne relève pas du jeu. » Une définition qui peut donner lieu à des interprétations hâtives : pour une gamification réussie, suffit-il d’ajouter des badges et des points à tour de bras ? Suffit-il d’ « appliquer », comme on applique une couche de peinture, un semblant ludique à une activité rébarbative « qui ne relève pas du jeu » ? Non.

Tout au long de cette intervention, nous nous avons plutôt pris appui sur l’approche définie par Yu-Kai Chou, référence du domaine, et à l’origine d’un schéma bien pratique pour concevoir et analyser des expériences gamifiées.

La gamification n’est pas ce que vous pensez !

Pour Yu-Kai Chou, la gamification ne devrait pas forcément porter ce nom ; il lui préfère l’expression de « human-focused design ». La raison pour laquelle on parle de jeu, c’est qu’un jeu doit obligatoirement être suffisamment motivant en tant que tel pour qu’une personne ait envie d’y consacrer du temps. Dès qu’on ne s’amuse plus, on s’arrête de jouer, car il n’y a aucun besoin de jouer à un jeu. La gamification consisterait donc à rendre une expérience aussi amusante et engageante qu’un jeu, le jeu étant donc une simple analogie.

Cette expression de « human-focused design » s’oppose au « function-focused design », qui se concentre avant tout sur les résultats opérationnels. Cependant, Yu-Kai Chou ne perd pas de vue ces résultats. Vous pourrez par exemple découvrir sur son site une liste de 90 exemples de gamification ayant démontré leur ROI.

Alors, comment enrichir la pratique du test et la rendre plus engageante, plus orientée vers les motivations humaines ?

Test et gamification

Un constat pour commencer : aux yeux des outsiders, le test logiciel est une activité qui souffre d’une assez piètre réputation. Des exemples ?

  • « Ce doit être ennuyeux, répétitif, rébarbatif ! »
  • « Concevoir et développer une application, ce doit être beaucoup plus motivant… car le test n’est pas une activité créative. »
  • « Le métier du test, c’est pour les personnes qui n’ont pas réussi à devenir dev. »

En toute honnêteté… il serait faux d’ailleurs de récuser en bloc la première affirmation, car il peut arriver de se lasser d’exécuter de longues et monotones campagnes de test. Alan Richardson a même écrit un poème sur le sujet afin d’inciter à toujours tester comme si c’était la première fois. Ce n’est pas une mince affaire !

Le test logiciel est donc une activité qui gagnerait à être (ré)enchantée. Que ce soit pour attirer de nouveaux talents dans cette profession, pour engager nos équipes autour de la qualité, ou tout simplement pour rester, soi-même, dans un état d’esprit positif.

Des leviers motivationnels universels

Yu-Kai Chou considère que tout ce que nous faisons, nous le réalisons parce qu’un ou plusieurs de nos 8 leviers motivationnels sont enclenchés. Ces leviers étant les suivants :

  1. Sens épique et vocation
  2. Développement et accomplissement
  3. Renforcement de la créativité et feedback
  4. Propriété et possession
  5. Influence sociale et connexion
  6. Rareté et impatience
  7. Imprévisibilité et curiosité
  8. Peur de la perte et évitement

Nos deux hypothèses :

  • Tous ces leviers sont actionnés par le métier du test.
  • Prendre conscience de ces leviers peut nous aider à nous développer professionnellement et à améliorer nos pratiques.

Ces 8 leviers seront donc présentés, deux par deux, dans les 4 prochains articles à venir, avec à chaque fois des exemples concernant le métier du test logiciel.

Bonne lecture ! Et si vous souhaitez plutôt visionner le replay de la conférence, le voici :

Webinar : Travailler dans l’IT en Nouvelle-Calédonie, c’est comment ?

Un échange exceptionnel en vue !

Il y a quelques mois, nous évoquions notre quotidien en tant que QA en Nouvelle-Calédonie. Une fois de plus, nous souhaiterions donner un coup de projecteur à ce territoire, où notre société est ancrée depuis maintenant 5 ans. Cette fois-ci, nous dépasserons le périmètre du test logiciel, pour aborder sous forme de webinar l’écosystème IT global calédonien. Vous y rencontrerez aussi nos partenaires Atlas ManagementTealforge ainsi que nos invités ; ensemble nous couvrirons les domaines du développement, de la gestion de projet, de la qualité logicielle, du coaching agile et de l’UX.

Cet échange est un événement rare et nous vous invitons vivement à y prendre part !

Au menu de ce webinar

Ce webinar sera l’occasion pour vous de découvrir différents aspects du monde de l’IT en Nouvelle-Calédonie, ainsi que de poser toutes vos questions.

Projets, technologies, opportunités, cadre légal, emploi local, ambiance au travail, niveau de vie… préparez vos questions liées à la vie pro, sachant que nous évoquerons aussi les aspects plus personnels comme l’emploi des conjoints, le rythme scolaire, les vacances, le coût de la vie, le climat et tous les autres sujets qui vous tiennent à cœur.

La Nouvelle-Calédonie est un territoire attractif à de nombreux points de vue. Mais nous ne parlerons pas ici des plages de rêve ni de la douceur de vivre au milieu du plus beau lagon du monde…

L’écosystème IT calédonien est en pleine effervescence, et des talents sont requis tous domaines confondus. Le lancement en 2020 de la French Tech Nouvelle-Calédonie a d’ailleurs mis en lumière la profusion de projets innovants qui caractérise le territoire. Plus que jamais, poursuivre sa carrière en Nouvelle-Calédonie représente une opportunité à saisir.

En un mot : on n’attend plus que vous !

Inscription au webinar

Les inscriptions sont d’ores et déjà ouvertes ; vous pourrez prendre part à l’événement à condition de remplir le formulaire suivant.

La date à retenir : mercredi 16 décembre à 21h heure française.

Le replay du webinar

Le webinar est désormais passé… et il est possible de le revoir à volonté ! Bon visionnage !

Les bugs lugubres d’Halloween

Connaissez-vous le site This Person Does Not Exist ? Ce service minimaliste propose à chaque rechargement de page une photo de personne générée automatiquement. La technique ? Un réseau antagoniste génératif : un dispositif composé de 2 réseaux qui s’affrontent à un jeu bien particulier. Le réseau A génère une image ressemblant à un être humain, et le réseau B, en se basant sur son apprentissage, essaye de deviner s’il s’agit d’une image générée ou d’une vraie photo de personne. Les images générées ayant trompé le réseau B sont ainsi susceptibles de tromper aussi un oeil humain. Le code est disponible en open-source.

Regarder ces portraits est une expérience aussi impressionnante que dérangeante ; comment ne pas ressentir de sympathie envers ces personnes imaginaires, qui arborent toutes un sourire jovial ?

Il serait presque tentant de croire que ces images n’ont pas été générées et représentent bel et bien et personnes réelles. Heureusement, les quelques bugs qu’il est possible de rencontrer contredisent cette supposition. Alors préparez-vous à une expérience étrange !

D’insolites portraits

On peut constater un regroupement des défauts au niveau des parties de la physionomie censées être (plus ou moins) symétriques : les dents, les yeux, les oreilles. Ci-dessous, ce sont les épaules qui posent problème.

Les cheveux semblent également être un challenge particulier, voir les cheveux-chapeau de ce personnage :

L’IA a également besoin d’entraînement sur les lunettes à monture transparente.

De manière générale, les accessoires sont moins bien générés que les parties distinctives d’un visage humain, comme ce bonnet qui semble à moitié transparent (en haut à droite).

De même, où commence et où finit l’écharpe sur la photo ci-dessous ?

D’autres visages d’apparence déformée, un brin voldemoresques, hantent également certaines photos.

Une V1 encore plus effrayante

La première version de cette IA, que l’on peut encore utiliser sur le site Which Face Is Real? est beaucoup moins performante. Versant souvent dans la vallée dérangeante, elle génère régulièrement des images à faire froid dans le dos. Cette jeune femme est-elle en train de déformer son environnement grâce à des pouvoirs spéciaux ?

Le visage de celle-ci est-il en train de se fissurer comme celui d’une poupée de porcelaine ?

On vous quitte sur cette photo de famille psychédélique !

Félicitations aux chercheurs d’Nvidia pour avoir créé et perfectionné cette incroyable IA, et joyeux Halloween !

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.

Faire du test à Nouméa, ça ressemble à quoi ?

Cet article est particulier car pour la première fois nous allons parler directement de nos expériences en tant que spécialistes du test à Nouméa, en Nouvelle-Calédonie. Un article qui répondra à pas mal de questions que se posent les personnes qui nous suivent depuis la métropole, et qui vous permettra aussi peut-être de voyager un peu (sauf bien sûr si vous vivez vous-mêmes à Nouméa !)

Avant de commencer de lire cet article, jouons à un petit jeu.

Sur la carte affichée dans la vignette de cet article, sauriez-vous dire dans quelle zone colorée se trouve la Nouvelle-Calédonie ?

Si vous l’ignorez, rassurez-vous : certains d’entre nous ne le savaient pas non plus il y a quelques années. Dans le cas contraire, bravo, et maintenant entrons dans le vif du sujet !

Qu’est-ce qu’on teste en Nouvelle-Calédonie ?

On nous demande souvent ce qu’on peut bien tester en Nouvelle-Calédonie. Eh bien figurez-vous que les applicatifs à tester ne manquent pas, loin de là !

Une île déserte ? Pas du tout !

La Nouvelle-Calédonie a son propre gouvernement, son propre système de santé, son propre réseau bancaire, son propre service postal, des lois particulières… C’est une collectivité française, certes, mais qui dispose d’une large autonomie. Quelques exemples ?

  • Nous ne payons pas de factures de chauffage en euros auprès d’EDF, mais des factures de climatisation en francs pacifiques auprès d’EEC (Electricité et Eau de Calédonie). Un euro équivaut à environ 119 francs pacifiques.
  • Quand nous achetons un kilo de pommes-lianes ou de miel de niaouli, nous ne payons pas la TVA, mais la TGC (taxe générale à la consommation).
  • Quand on se fait mal en kitesurf, nos bobos sont pris en charge non pas par la Sécurité Sociale mais par la CAFAT.
  • Nos colis remplis de cadeaux souvenirs des Îles Loyauté, nous ne les envoyons pas par la Poste mais via l’OPT (Office des Postes et des Télécommunications).
  • La société Hightest n’a pas de numéro de SIRET. En revanche, elle a un RIDET (Répertoire d’Identification des Entreprises et des Etablissements) !

Autant dire que pour gérer toutes ces particularités, il existe un nombre incalculable d’applicatifs, développés sur place ou en offshore. Et quand on est métropolitain, c’est un plaisir de découvrir cet univers.

Une terre d’innovations

Autant dans la sphère publique que privée ou associative, les projets innovants se multiplient, tous domaines confondus, accompagnés par un réseau de plus en plus dense d’organismes locaux et de réseaux internationaux. L’année 2020 n’a pas seulement été celle du Covid-19, mais aussi celle de la labellisation French Tech Nouvelle-Calédonie, portée par plus d’une centaine d’organismes.

Chez Hightest, nous ne sommes pas en reste, et développons depuis début 2019 une plateforme de crowdtesting, Testeum. Développée (et testée !) 100% en local, elle a néanmoins une ambition internationale.

Et le reste du monde ?

Nos interlocuteurs métropolitains sont souvent surpris quand on leur dit que nous travaillons essentiellement pour des organismes calédoniens. Vous comprenez maintenant pourquoi !

Ceci étant dit, il est vrai que la situation géographique de la Nouvelle-Calédonie en fait un spot idéal pour mettre en œuvre une démarche follow-the-sun. Les fuseaux horaires métropolitain et calédonien permettent à eux seuls de couvrir une grande amplitude de plages horaires. C’est un axe que nous proposons mais que nous n’avons encore jamais mis en œuvre à grande échelle. Ce chantier, nous l’avons appelé « You Sleep / We Test ».

A quoi ressemble le quotidien en mission ?

Préparez-vous maintenant à l’immersion, car dans ces paragraphes nous allons entrer dans les détails (parfois triviaux) de notre quotidien !

Profil type de la journée de mission

Un détail anecdotique pour commencer : en Nouvelle-Calédonie, il n’est pas rare de commencer sa journée de bureau à 7h30 et de la finir à 16h30. 7h30, ça peut sembler un peu tôt quand on vient de métropole ! Mais globalement, tout le monde s’y fait : comme le soleil se lève très tôt, notre horloge biologique s’adapte sans problème.

La plupart du temps, nous nous déplaçons chez nos clients. Il arrive que nous travaillions via VPN, mais c’est relativement rare. Exception faite de la période de confinement, qui n’a duré qu’un mois en Nouvelle-Calédonie.

Nous nous déplaçons majoritairement en voiture, les transports en commun étant relativement peu développés à Nouméa si on compare avec les grandes villes de métropole. La plupart du temps, les trajets du matin et du soir ne dépassent pas 15 minutes.

Il est courant de partir en pause déjeuner dès 11h30. La durée de la pause méridienne est sensiblement la même qu’en métropole. Comme les plages ne sont jamais bien loin, il est possible d’aller nager. La plage de la Baie des Citrons (ci-dessous) et à 6 minutes de voiture du siège d’Hightest.

A côté des autres solutions traditionnelles, certaines personnes ont recours à une institution bien calédonienne : les services de gamelles ! Il s’agit de services de livraison de repas complets au bureau ou à domicile, sur abonnement ou à l’unité. Pratique et assez économique, avec des menus qui changent d’une semaine à l’autre.

Nature et durée des missions

Nous intervenons sur des missions de toutes les durées, de quelques jours à plusieurs années. Les missions se suivent et ne se ressemblent pas ! Test agile, automatisation des tests, test management, test de charge, accompagnement, conseil, chaque mission est une aventure à part entière et nécessite de s’adapter en permanence. Les domaines fonctionnels sont également nombreux et ne permettent pas d’être tous détaillés dans cet article.

Tout cela apporte du challenge, et nous pouvons compter les uns sur les autres pour obtenir de l’aide et des conseils. Notre Slack, ainsi que nos repas d’équipe hebdomadaires au restaurant, nous permettent de garder le fil de l’équipe et d’organiser l’entraide. Nous organisons également une fois par mois un temps d’échange collectif autour de nos problématiques professionnelles, ce qui nous permet également d’échanger des bonnes pratiques et le fruit de nos veilles respectives.

A quoi ressemble le quotidien chez Hightest ?

Quand nous ne sommes pas en mission, une grande palette de possibilités s’offre à nous. Lorsque nous faisons de la veille durant ces périodes, nous avons soin de partager nos découvertes avec les autres membres de l’équipe, voire au-delà en passant par le blog (celui que vous êtes en train de lire !).

Par ailleurs, comme nous sommes peu nombreux, nous assurons en bonne intelligence une panoplie d’activités telles que le recrutement, la communication et l’animation commerciale. Nous aimons partager notre passion pour la qualité logicielle et nous le faisons au travers d’événements comme les petits déjeuners du test logiciel (qui nous ont donné l’occasion par exemple d’expérimenter le Bingo des Recettes à la Noix).

Le projet Testeum nous mobilise également : une plateforme de test se doit d’être vigoureusement testée !

Chacun mène ces activités soit chez soi, en télétravail, soit au siège. Nous partageons nos locaux (et bien plus !) avec deux autres sociétés, Tealforge et Atlas Management, respectivement une entreprise de développement et un cabinet de conseil en management de projets numériques, en performance des organisations et de formation professionnelle. Pour la petite histoire, c’est Tealforge qui a développé notre plateforme Testeum !

Les interactions entre nos trois entreprises sont fréquentes et très riches, et nous permettent d’ouvrir nos horizons vers d’autres connaissances.

Une « photo de famille » à l’occasion d’une journée inter-équipes (l’un d’entre nous n’y figure pas !)

 

Qui trouve-t-on dans l’équipe ?

L’équipe Hightest est formée à ce jour de 7 personnes, qui ont entre 4 et 12 ans d’expérience. A nous tous, on a presque 60 ans de test logiciel, ce qui ne nous rajeunit pas.

Nous nous ressemblons dans le sens où nous avions tous en entrant chez Hightest un bac + 5 et au moins un an d’expérience dans le test logiciel, dont au moins un an en automatisation des tests. Nous nous ressemblons aussi car nous avons tous une certification ISTQB, de niveau Fondation ou supérieure.

Mais nous différons par nos parcours divers, qui font toute la richesse de nos interactions : des études en mécatronique, développement, journalisme ou encore documentation, nous avons évolué dans des milieux variés qui nous ont apporté à chacun un lot de connaissances fonctionnelles que nous partageons avec plaisir : télécommunications, monétique, e-commerce, e-learning, SEO…

Nous recrutons sur profil, et sommes toujours à l’écoute des candidatures. Si ce que vous venez de lire a éveillé en vous l’envie de nous rejoindre, n’hésitez pas à nous contacter !

Important : nous organiserons bientôt un webinar sur la thématique « Travailler dans l’IT en Nouvelle-Calédonie« . Si vous souhaitez que l’on vous tienne au courant de ce projet, merci de laisser votre adresse e-mail dans ce formulaire !

L’automatisation des tests en 22 émotions

« Maintenant, on va automatiser les tests. »

La première fois que vous avez entendu cette phrase, vous avez certainement pensé que ce serait une bonne idée et que cela permettrait de consolider durablement la qualité des applicatifs concernés. Dans la plupart des cas, vous aviez raison. Mais à ce moment-là, pensiez-vous déjà à toutes les émotions que vous ressentiriez au cours de ce périple ?

Réjouissantes, mordantes, bouillonnantes, subtiles ou dévastatrices, on en voit de toutes les couleurs. En l’espace d’un quart d’heure, on peut passer de l’impression d’être une andouille à celle d’être un génie. Et vice-versa. Ce n’est pas de tout repos, surtout au début !

Un petit point sur la gamme d’émotions associée à l’automatisation des tests, car contrairement à nos bien aimés tests auto, on n’est pas des robots !

Cet article aborde 4 types d’émotions :

  • Celles qu’on ressent immanquablement au début, quand on découvre l’automatisation
  • Celles qui nous accompagnent dans la routine
  • Celles que l’on ressent dans les moments où on dresse des bilans
  • Les sonnettes d’alarme qui accompagnent les crises !

Frémissements des débuts

Emerveillement

C’est une des premières émotions qu’on peut ressentir quand on démarre en automatisation des tests. C’est un peu la même qu’on a eue, des années et des années plus tôt, quand on a joué pour la première fois avec une voiture télécommandée.

Pas la peine de s’en cacher, c’est merveilleux de voir un navigateur s’ouvrir tout seul et exécuter sagement tout ce qu’on lui a demandé de faire !

Fierté

Jusqu’alors, ça vous ennuyait qu’on vous qualifie de « testeur manuel » ? Il y a de quoi ; les activités de test nécessitent certes des mains (quoi que…) mais c’est un poil réducteur de réduire un testeur à ce qui lui permet de cliquer sur sa souris. On devrait peut-être parler davantage de « test cérébral »…

Mais bref, dans certains contextes, acquérir la casquette de l’automatisation peut sembler prestigieux.

On ne va pas bouder son plaisir, il y a de quoi ressentir de la fierté, tant qu’on se prémunit contre les maladies des tests automatisés ! Et tant qu’on se souvient que l’automatisation n’est pas une fin en soi, ni une raison de snober les collègues qui préfèrent développer d’autres compétences de test.

Confusion

« Pourquoi ça ne marche pas ? »

« Et surtout, pourquoi là ça remarche ? »

Bienvenue dans le monde occulte de l’automatisation des tests. Pour le meilleur et pour le pire, ça vous arrivera régulièrement et vous n’y comprendrez rien.

Si votre confusion a raison de votre bonne humeur et menace de vous poursuivre en-dehors du travail, prenez le temps de vous attarder dans la section « Pulsations des méandres ».

Illumination

C’est vrai, on aurait pu dire « Inspiration ». Mais il y a des moments où, sans crier gare, la solution que l’on cherchait s’impose enfin à nous. Elle nous délivre en une seconde d’un problème d’automatisation qu’on se traînait depuis des jours. Et dans ces moments-là, c’est toute notre âme qui se sent illuminée.

C’est beau, non ?

Bourdonnements de la routine

Flow

Vous êtes tellement à votre ouvrage que tout ce qui vous entoure disparaît. C’est un état exceptionnellement agréable, qui vous semble constitué de 90 % de concentration profonde et de 10 % d’euphorie. Profitez-en, vous êtes au max de votre productivité !

Attention toutefois, ce qui peut vous manquer dans ces moments où vous faites corps avec votre tâche, c’est votre esprit critique vis-à-vis de cette tâche. Avez-vous vraiment besoin d’automatiser tous ces comportements dans les moindres détails ?

Amusement

Nouvelle fonctionnalité, nouveau challenge ! Parfois, il vous suffit de jeter un œil aux spécifications pour que vous sachiez tout de suite : « Là, on va bien se marrer ! »

Et le mieux, c’est que vous pensez cela sans la moindre ironie.

Appréhension

Au moment d’appuyer sur le bouton de lancement, vous craignez que vos tests se cassent la figure, que les faux positifs se multiplient et que votre beau projet d’automatisation soit discrédité. Respirez un coup, rien n’est fait, et quand bien même, il faut voir au-delà du faux-positif… On y reviendra dans un prochain article !

Ennui

Le mythe : les tests automatisés vont abolir l’ennui du quotidien des testeurs, en leur épargnant de longs et fastidieux tests de non-régression.

Le scoop : automatiser les tests peut également être ennuyeux !

Au quotidien, il est aussi pertinent qu’épanouissant de jongler entre différentes activités de test : revue des spécifications, conception des scénarios de test, gestion des bugs, organisation d’ateliers, sessions de test exploratoire, veille technologique… Pour une bonne santé mentale, testez équilibré !

Gratitude

Il arrive que vous ayez besoin de tel ou tel bout de code qui fasse telle ou telle chose. Et là, vous vous rendez compte qu’il existe déjà, vous l’avez développé il y a quelques mois et vous l’aviez complètement oublié.

Frustration

Plus vite, plus vite !!! Qu’il est frustrant de voir un test automatisé exécuter certaines tâches plus lentement qu’un humain.

Double peine : non seulement vous vous faites du mal à attendre qu’il se déroule, mais vous perdez aussi de votre précieux temps ! Certaines fois, il n’y a rien à faire pour que ça aille plus vite, alors profitons simplement de pouvoir tester d’autres choses en parallèle.

Jubilation

L’automatisation des tests permet de trouver des bugs marrants, que ce soit lors de l’exécution de ces tests ou lors de leur conception. Ne boudez pas ce plaisir, au contraire c’est important que tout le monde sache que l’automatisation permet aussi cela. Vous pouvez trouver un moyen de conserver la liste des bugs que vous avez trouvés grâce à l’automatisation des tests, par exemple une métadonnée associée aux tickets d’anomalies. Cette liste pourra être dégainée en temps voulu.

Enthousiasme

Quoi de plus enthousiasmant que d’apprendre de nouvelles techniques et de les appliquer avec succès ? Cela fait aussi partie du quotidien quand on automatise des tests. Les technologies étant en constante évolution, vous aurez toujours de nouveaux chemins à explorer.

Soulagement

Ces derniers temps, les tests autos vous ont malmenés. Vous avez dû gérer une liste longue comme le bras de scripts KO, qui n’était pas due à des bugs réels mais à une inadéquation entre les automates et le système à tester. Un orage de faux positifs, ça ne fait jamais plaisir, même quand « c’est normal » (changement dans l’interface, modification des règles de gestion…). Alors c’est un profond soulagement que vous ressentez le jour où vous relancez vos tests, et que tous se déroulent correctement.

Vibrations des bilans

Tristesse

Vous avez passé un temps fou à automatiser cette suite de tests, vous y avez mis tout votre cœur et ça marchait du tonnerre.

Mais la sentence est tombée : la fonctionnalité testée va disparaître. Vos merveilleux automates ne pourront plus « tourner ». Respirez par le ventre et soyez philosophe, ça fait partie des déconvenues possibles !

En revanche, par pitié, ne commentez pas vos vieux bouts de code désormais inutiles. Supprimez-les, ça fait partie du deuil ça conservera propre votre projet d’automatisation.

D’ailleurs, ils seront toujours quelque part… non non, pas dans votre coeur, mais dans votre logiciel de gestion de versions !

Satisfaction

Mmmmmh, qu’il est doux de profiter du ronronnement bien huilé des tests auto. Vous voyez la liste des cas de test qui s’exécute et vous pensez « C’est moi qui ai fait ça. » Profitez de ces instants, vous savez qu’il y en aura d’autres moins agréables !

Sérénité

C’est une émotion à la fois discrète et très précieuse. Si, en lançant vos tests automatisés, vous ressentez de la sérénité, c’est que vous avez pris confiance en vos scripts, et que vous savez qu’ils vont vous apporter ce que vous attendez d’eux. Félicitations.

Sentiment de maîtrise

Ça y est, vous connaissez la chanson, vous l’avez jouée tant et tant de fois. Vous pourriez développer vos tests sans regarder l’écran (non, quand même pas). Vous savez assez précisément combien de temps vous prendra une tâche avant de la commencer. Vous vous sentez à l’aise, vous avez une bonne productivité, profitez-en !

Cependant, pas question de laisser ce sentiment vous empêcher d’explorer de nouvelles pratiques où vous serez moins à votre aise.

Joie

En prenant un peu de recul, vous constatez que l’automatisation a bel et bien accéléré la cadence de vos tests, que vous êtes maintenant en mesure de tester plus en profondeur, plus intelligemment, et de fournir toujours plus de retours intéressants sur la qualité. Mission accomplie.

Mettez tout en œuvre pour que cette joie n’ait pas de fin !

Pulsations des méandres

Désespoir

Quand ça marche pas, ça marche pas.

En vous lançant dans l’automatisation des tests, vous traverserez certainement de grands moments de solitude. Il faut s’y préparer ! Voici quelques situations que vous rencontrerez certainement :

  • Vous voulez interagir avec un certain élément d’une page web, mais vous ne trouvez aucun moyen de le faire !
  • Un script de test fonctionnel fonctionne une fois sur deux. Ou sur trois.
  • Les outils et/ou les dépendances que vous utilisez ne s’entendent pas, à cause d’un problème de compatibilité, ou autre couac que vous ne pensez pas être en mesure de résoudre.
  • Ça marche dans le tuto, ça devrait marcher chez vous aussi !!!

Parfois (et de plus en plus souvent avec le temps), vous arriverez à vous en dépatouiller. Mais d’autres fois, ce ne sera pas le cas. Des remèdes ?

  • L’entraide. Si dans votre organisation vous êtes en solo sur les tests automatisés, vous pourrez tout de même compter sur la communauté des testeurs (comment, vous n’êtes pas encore membre du groupe LinkedIn Le métier du test ?) et sur des sites tels que StackOverflow. N’hésitez pas à créer un compte et à poser vos questions, un jour ce sera à votre tour de « sauver la vie » de quelqu’un !
  • La communication. Si ça ne marche pas, parlez-en, même si personne n’est en mesure de vous aider. Si une tâche d’automatisation vous demande trop de temps en recherche, c’est peut-être qu’il vaut mieux ne pas l’automatiser tout de suite, que quelqu’un d’autre s’en charge. Ça ne sert à rien de se flageller dans son coin, vous allez juste vous faire du mal.

Honte

Wow, autant de tests en échec ? Le rouge vous monte aux joues. Des faux positifs, ça doit être une montagne de faux positifs

Vraiment, vous avez honte avant de savoir ce qui s’est vraiment passé ? Si ça se trouve, il s’agit d’une vraie anomalie ! Au fond c’est pour détecter des anomalies que vous avez automatisé ces tests, vous vous souvenez ?

Sentiment d’absurdité

Votre mission est d’automatiser des tests pour gagner du temps, pour faire plus de test cérébral. Mais depuis quelques temps, votre métier consiste davantage à maintenir de vieilles breloques supposément automatisées, qu’à fournir des informations à forte valeur ajouté sur la qualité de ce que vous testez. Ça ne tourne pas rond, tout ça…

Réagissez, ce sentiment d’absurdité vous informe que quelque chose doit changer !

Sentiment d’injustice

Vous venez d’atteindre le niveau le plus décadent de l’anthropomorphisme. Au fond de vous, vous savez bien que les tests auto n’ont pas de conscience, et qu’ils ne se mettent pas en échec pour vous faire souffrir.

Comme vu précédemment, pas la peine de vous laisser sombrer dans de telles considérations, prenez une pause, visiblement vous en avez besoin.

Conclusion

Le but de cet article est double :

  • Que nous prenions conscience de la place que les émotions occupent dans nos activités d’automatisation des tests, et
  • Que nous voyions mieux la valeur qu’elles peuvent nous apporter. En prenant un peu de recul, nous pouvons voir ces émotions comme des indicateurs. Si vous souhaitez donner le meilleur à un projet, vous gagnez à cultiver les émotions qui vous font réussir. Vous gagnez aussi à écouter certaines émotions qui vous font souffrir, si elles vous donnent des informations sur ce qui devrait être changé. Quant aux autres… même si c’est plus facile à dire qu’à faire… nous espérons que vous apprendrez à lâcher prise et les laisser partir.

Bon courage à toute la communauté des QA qui automatisent sans relâche et vivent ce faisant autant d’émotions diverses ! Il y a bien des cœurs qui battent derrière ces austères scripts.

Crowdtesting : qu’est-ce que ça apporte vraiment ? Côté éditeur

Ce qu’apporte le crowdtesting ? En tout premier lieu, un entraînement d’élocution, car c’est un des mots les plus rugueux que vous aurez à prononcer dans votre vie (mais pour votre bonheur, vous trouverez dans cet article des propositions alternatives plus francofluides).

Aujourd’hui, pour répondre à cette question, nous nous plaçons du côté des éditeurs. Cela regroupe à la fois, certes, les sociétés éditant des logiciels, mais aussi les organisations ayant fait développer un site ou une appli, en interne ou par un prestataire.

Vous avez déjà testé votre produit en interne et tous vos cas passants… passent. Et là, vous envoyez ces mêmes scénarios à une plateforme de crowdtesting (comme Testeum !), et vous découvrez que la validescouade ouvre des bugs sur ce qui fonctionnait à merveille. Quelle est cette sorcellerie ? Pourquoi les crowdtesteurs découvrent-ils des bugs que vous n’aviez pas vus ?

Les crowdtesteurs vous fournissent des paires d’yeux neufs

A force de voir votre produit à longueur de journée et à longueur d’année, votre regard s’est émoussé. Un élément du site vous semblait ambigu, étrange ou disgrâcieux au premier regard, puis vous avez pris l’habitude de le voir. Vous avez perdu la volonté de demander un changement. Le phénomène qui est à l’œuvre ici est le biais de simple exposition : il suffit de se trouver en présence d’une chose pendant assez longtemps pour que cette chose nous semble appréciable.

Les crowdtesteurs sont libres de ce biais, ils n’ont jamais vu votre produit et ne se gêneront pas pour vous dire tout ce qui les tracasse. Leur avis pourrait même avoir plus d’impact. Nul n’est prophète en son pays, et bien souvent, ça vaut aussi pour les remarques d’UX…

Les crowdtesteurs ont la motivation que vous n’avez plus

Même si des tests automatisés ont été rédigés pour votre applicatif, il y a certainement des tests de régression que vous continuez de jouer à la main, version après version, sprint après sprint si vous travaillez en Scrum. Et ces scénarios-là, vous en avez assez de les ruminer encore et encore.

Les crowdtesteurs ont la fougue de la découverte, la même que vous aviez la première fois que vous avez posé les yeux sur le produit. Le scénario qui désormais vous semble insipide et sans surprise, ils le joueront avec une attention que vous ne pouvez plus fournir aussi spontanément.

Les crowdtesteurs vous prêtent leur matériel (mais il s’appelle revient)

C’est une des promesses majeures du crowdtesting : déclencher des tests tout-terrain. On pourrait parler d’immensitest, ou de diversitest. Vous pourriez tomber sur :

  • Andrea, 18 ans, alternant, qui testera sur son vieux PC et une version obsolète de Chrome avec la connexion ADSL de sa résidence étudiante en Angleterre.
  • Betty, 68 ans, retraitée, qui testera sur sa tablette Samsung de seconde main dans le TGV avec la 3G.
  • Chafia, 34 ans, graphiste, qui testera sur son iPhone flambant neuf avec la Wifi d’un café en Australie.

Vous allez découvrir avec surprise que votre menu sandwich se comporte bizarrement sur certains devices, ou que votre panier se charge décidément trop lentement. Et tant d’autres choses encore…

Les crowdtesteurs ont chacun leur corps

Ça vous semble incongru de le rappeler ? Quand on imagine des tests IHM, on pense énormément au « I », mais pas assez au « H ». Or, dans notre exemple précédent :

  • Andrea est daltonien, et les graphiques bariolés que vous affichez si fièrement sur votre site vont souverainement l’agacer. Ne vous inquiétez pas, il vous expliquera tout dans son rapport de bug.
  • Betty aime bien en rire en disant qu’elle a « des gros doigts ». Pourtant, elle ne manquera pas de vous expliquer quels sont les éléments qu’elle a du mal à cliquer sur votre interface.
  • Chafia est entourée par les clients du café qui parlent et chahutent sans discontinuer. Elle vous signifiera que vos contenus vidéos sont impossibles à consulter dans ces moments-là… à moins que vous n’y ajoutiez des sous-titres.

Votre utilisateur idéal est une personne à l’aise avec l’informatique, valide, 100 % en forme, qui a du super matos, une super connexion, un navigateur à jour, du temps devant lui, un environnement calme et un tempérament patient et bon public. Vous ne risquez pas de le rencontrer de sitôt. En attendant, faites plutôt appel à des « gens de la vraie vie », qui massifouineront votre produit avec les moyens du bord.

Les crowdtesteurs sont aussi fous que vous

Plus on est de fous… plus il y a de folies. Dans votre équipe, certaines personnes remarquent immédiatement quels éléments d’une page web ne sont pas bien alignés. D’autres ne jurent que par l’orthographe et traqueront la moindre espace insécable. C’est grâce à cette diversité de lubies que votre qualité se consolide au fil du temps.

Les crowdtesteurs ont aussi leurs propres lubies. Un background SEO, et vous voilà avec des suggestions d’amélioration de vos titres. Un penchant pour l’édition, et vous récoltez des remarques sur les polices et les espacements de lignes.

Le crowdtesting, c’est comme une boîte de chocolats, il y a des saveurs de bugs à découvrir que vous n’auriez jamais imaginées.

Récapitulons : les crowdtesteurs vous offrent des paires d’yeux neufs, la motivation du commencement, des environnements et des profils utilisateurs inédits, et enfin des angles d’attaque que vous n’auriez pas anticipés. Voilà les principales raisons pour lesquelles les bugs issus du crowdtesting sont différents de ceux que vous trouvez déjà avec brio en interne. Si vous en avez constaté d’autres, dites-nous lesquelles en commentaire !

Promyze à la loupe : quelques questions pour aller plus loin dans la qualité de code

La semaine dernière, nous présentions Promyze (anciennement Themis), une plateforme collaborative agile et ludique permettant d’améliorer en équipe la qualité de code. Nous nous sommes penchés en particulier sur les Ateliers Craft, qui permettent aux équipes de développement d’échanger efficacement sur les bonnes et les mauvaises pratiques au sein de leurs applicatifs. Cette semaine, Promyze répond à quelques-unes de nos questions au sujet des Ateliers Craft.

Les Ateliers Craft au quotidien : quelle temporalité ?

H : Que conseillez-vous pour intégrer la routine des Ateliers Craft dans le quotidien des développeurs ? En Scrum par exemple, quels moments du sprint privilégier ?

P : La temporalité des ateliers va dépendre des cas d’utilisation. Le scénario qui revient régulièrement est celui d’une équipe qui organise des ateliers à chaque sprint, donc soit 1 fois par semaine ou toutes les 2 semaines. Les fins de sprint sont un bon moment pour organiser une rétrospective collective, prendre du recul sur les développements réalisés et échanger sur les pratiques. Ainsi, cela laisse plusieurs jours aux équipes avant la rétrospective pour trouver 10 minutes afin de déposer des tags et suggérer des bonnes pratiques. Les ateliers s’intègrent très bien dans une démarche agile, puisqu’on retrouve l’idée d’interactions collectives et fréquentes et d’amélioration continue. Surtout, cela ritualise un temps d’échange sur le sujet de la qualité de code.

Qui inviter aux Ateliers Craft ?

H : Une entreprise a 3 applications : A, B et C. Son équipe X travaille sur A et B, et son équipe Y travaille sur B et C. Conseillez-vous de laisser chaque équipe se mêler de la qualité de code de ses propres applicatifs seulement ? Ou au contraire conseillez-vous de laisser les ateliers ouverts à tous ?

P : Difficile de généraliser une réponse pour chaque contexte, mais pour les premiers ateliers je préconiserais que chaque équipe travaille sur son propre code, afin de s’approprier le fonctionnement des ateliers et expérimente quelques rétrospectives. Dans un second temps, inviter des personnes externes est une piste intéressante car la richesse des ateliers provient des interactions et des échanges que vont avoir les personnes qui y participent. L’objectif n’est pas de dire “Faites comme ça !”, mais plutôt “Que pensez-vous d’utiliser plutôt cette façon de faire ?”.

Si ces « invités » travaillent sur les mêmes langages et technologies, avoir un regard extérieur est selon moi toujours bénéfique, car non engageant. En effet, l’équipe d’un projet aura toujours le dernier mot, donc il ne s’agit pas d’imposer, mais de suggérer. Le contexte du projet est vraiment primordial, il est donc important que parmi les participants il y ait des membres du projet.

En revanche, nous ne conseillerons pas que l’équipe X organise seule un atelier sur le code du projet C, car elle ne connaît probablement pas le contexte. Par contre, avoir un atelier commun sur le code du projet B avec les équipes X et Y peut être intéressant !

Même si chaque contexte a ses propres règles et bonnes pratiques, c’est important selon nous qu’une organisation définisse un socle commun de bonnes pratiques, que chaque projet viendra enrichir. De plus en plus d’entreprises structurent des “communautés de pratiques” qui vont dans ce sens. Même dans une structure à taille humaine comme chez Promyze, nous nous efforçons d’uniformiser les pratiques sur nos différents projets. Quand une personne change d’équipe, elle a déjà ainsi des repères pour facilement rentrer dans le code !

De la revue à la correction

H : Corriger une mauvaise pratique immédiatement pendant la revue de code est le meilleur moyen de ne pas la laisser tomber aux oubliettes. C’est facile quand la revue se déroule en présentiel, au poste du développeur, mais là ce n’est pas le cas. Comment conseillez-vous de procéder à la correction des mauvaises pratiques identifiées pendant les Ateliers Craft ?

P : Très bonne question qui revient souvent ! Sur ce point, nous sommes d’ailleurs en train de finaliser une fonctionnalité dans Themis qui permettra, lorsqu’on identifie qu’une bonne pratique n’a pas été suivie, de proposer une correction (ex : un refactoring). Cela permettra d’enrichir la documentation de la bonne pratique, et d’échanger avec l’équipe pour savoir si on valide ou non la suggestion de correction. Pour en revenir à la question, nous prônons une démarche d’amélioration continue du code, donc si nous avons identifié des mauvaises pratiques dans l’atelier, le premier objectif sera d’essayer de ne plus l’appliquer sur les prochains développements. Par la suite, si l’on travaille sur du code existant, et qu’on identifie une mauvaise pratique, alors à ce moment-là il peut s’avérer judicieux de le retravailler pour qu’il respecte la bonne pratique définie dans l’atelier. Il faudra évidemment veiller aux risques de régressions, donc coupler les tests et les développements est fondamental. Enfin, la correction à apporter va dépendre du niveau de criticité : s’il y a potentiellement un bug derrière une mauvaise pratique, on sera forcément plus réactif dans le passage à l’action !

Comment organiser les ateliers ?

H : Il est possible de créer des ateliers à volonté. Comment les organiser ? Est-il conseillé par exemple de tenir des ateliers thématiques ? Comment savoir quand un atelier est terminé ?

P : Nous préconisons d’organiser des ateliers thématiques (ex : HTML/CSS, NodeJS, Spring, …), au sein desquels plusieurs sessions pourront être organisées. Il n’y a qu’une seule session en cours par atelier, donc cela facilite l’organisation. Plusieurs ateliers peuvent être créés en parallèle, mais généralement un seul sera actif chaque semaine par équipe. Pour chaque session, une personne dans l’équipe est désignée comme animateur, et aura pour mission de définir le code source sur lequel travailler, d’envoyer des rappels aux participants et enfin d’organiser la rétrospective. Nous préconisons qu’à chaque démarrage de session, la rétrospective soit notée dans l’agenda de l’équipe, cela permet à chacun et chacune de s’organiser ! Enfin, avoir une rotation dans les thématiques permet de rythmer les échanges et d’apporter de la diversité, mais aussi de revenir quelques semaines plus tard sur une thématique avec un regard qui aura peut être évolué.

Enfin, nous préconisons aussi de préparer le prochain atelier dès la fin de la rétrospective, en désignant qui sera la personne en charge de l’organisation et à quelle date on peut planifier la future rétrospective.

Les guégerres de bonnes pratiques

H : Il y a parfois des querelles autour des bonnes pratiques. Typiquement, il n’est pas rarissime de voir deux devs seniors, tous deux excellents, se crêper le chignon sur telle pratique, que X qualifiera de bonne et Y d’antipattern. Comment les Ateliers Craft permettent-ils de sortir de ces impasses ?

P : Effectivement cela peut arriver que, sur le moment, des personnes ne soient pas d’accord sur une bonne pratique. C’est déjà quelque chose de positif, ça montre qu’il y a de la matière pour échanger des arguments et arriver à un consensus ! Mais pour rebondir sur la question précédente, il est important d’avoir une personne qui soit “facilitateur” lors d’une rétrospective, anime les échanges, invite les participants à s’exprimer, … Cette personne doit être en mesure de sentir si un consensus va rapidement être trouvé lors de la rétrospective ou non, et si ce n’est pas le cas, la pratique qui fait débat est temporairement mise de côté, pour laisser le temps à l’équipe d’y réfléchir et d’exposer des arguments. Ce n’est pas évident de trancher à chaud sur des sujets pointus ! Themis proposera d’ailleurs très bientôt une fonctionnalité dans ce sens, un mode “battle” avec un système de vote qui offrira la possibilité d’apporter des arguments “pour” ou “contre”.

Themis vu de l’intérieur

H : Ca va être énorme ! Et chez Promyze, comment utilisez-vous les Ateliers Craft ?

P : Nous utilisons les ateliers une fois par semaine en organisant la rétrospective le vendredi après-midi. C’est une bonne opportunité pour tous et toutes de se retrouver pour parler de qualité de code et terminer la semaine ensemble. Notre objectif est de ne pas dépasser 1 heure, c’est important de borner les échanges. En pratique, nous conseillons à nos utilisateurs de viser 30 à 45 minutes.

Au début, nous avons forcément été les premiers testeurs de cette fonctionnalité, donc plusieurs formats ont été expérimentés (notamment sur le nombre de fichiers, de tags que l’on pouvait poser, …). Cela nous a aidés à optimiser l’utilisation des ateliers et d’en faire profiter nos clients.

Nous définissons la thématique de chaque session d’atelier, et désignons une personne pour animer la future rétrospective de cette session. Nous mettons en place une rotation dans la thématique des ateliers (HTML/CSS, NodeJS, Tests unitaires, …). C’est très positif jusqu’à présent, en plus nous avons dans notre équipe des profils avec des parcours différents, cela amène de la richesse dans nos échanges !

Merci à Promyze d’avoir répondu à nos questions sur Themis. Longue vie à cet outil qui apporte énormément au processus d’amélioration continue !