Le kit de secours métaphorique pour les tests agiles

La métaphore en action

« Tu travailles dans le test ! Quels langages tu connais ? »

Dans les prochains articles, nous n’allons pas parler de Python, Java ou Ruby, mais d’un langage que l’on utilise tous les jours en tant que QA : le « langage naturel« . Par commodité, c’est comme ça que l’on nomme le langage que l’on parle aussi bien à la maison qu’au bureau. Mais il n’a rien de « naturel » ; nous allons au contraire nous pencher sur des manières de le modeler, de le ciseler, afin de le rendre plus efficace, plus à même de servir la qualité des projets. Nous allons pour cela nous appuyer sur le procédé de la métaphore.

Pourquoi cette figure de style en particulier ?

La rencontre de deux univers sémantiques

Le mois dernier, sur le blog de la Taverne du Testeur, Marc Hage Chahine filait une longue métaphore sur le métier du test en le mettant en parallèle avec une chasse aux champignons. L’article allie l’utile à l’agréable en poursuivant un but bien précis : donner une explication d’un processus complexe, de façon à ce qu’un enfant de 6 ans puisse la comprendre.

Le résultat est assez réussi. Pourquoi ? Parce qu’en sollicitant un univers sémantique familier, on peut faciliter la compréhension d’un autre univers plus difficile à imaginer. Autre avantage : l’interlocuteur peut poursuivre la métaphore et ainsi alimenter la discussion, beaucoup mieux que s’il n’avait pas ce point de repère. Il peut par exemple se replonger dans un embarras qu’il a déjà vécu (ramasser un caillou qu’il prenait de loin pour un champignon) pour imaginer certaines situations du métier (la frustration des QA qui tombent sur des faux positif).

Et les métaphores sont partout. D’ailleurs, elles constituent souvent le ressort comique des memes et des GIF. Un exemple ?

Trois chats regardent avec beaucoup d'attention un oiseau par la fenêtre. Soudain, un petit chien arrive derrière les chats et les fait sursauter. Sur l'image, une étiquette indique que les chats représentent l'équipe projet, l'oiseau représente le week-end et le chien représente un bug inattendu.

On dit souvent qu’une image vaut mille mots. Mais ce qui est vrai à l’écrit, avec les graphiques et les illustrations (et, donc, les GIF), l’est donc aussi à l’oral, avec les métaphores. La formulation d’une idée peut avoir un impact notable sur la façon dont le cerveau de l’interlocuteur est stimulé. Ces dernières années, des chercheurs se sont même employés à le confirmer expérimentalement.

Les effets d’une métaphore sur le cerveau

Le psychologue Rutvik Desai, dans un article paru en 2011, a par exemple observé que les verbes d’action, y compris ceux qui étaient présents dans des métaphores, faisaient réagir les zones moteur du cerveau (source [PDF]). Ce qui pourrait signifier que la phrase « Il va falloir qu’on se serre les coudes pour terminer cette campagne de test » est plus stimulante que « Il va falloir qu’on s’entraide […] ». A noter : plus une métaphore est commune, moins elle active les zones moteur du cerveau. Quand on dit qu’on saisit l’intérêt de quelque chose, l’image de la préhension est assez lointaine. C’est comme si le cerveau avait besoin d’un effet de surprise pour que la métaphore joue son rôle.

Des résultats similaires ont été obtenus par l’université d’Emory en 2012 avec des métaphores contenant des références au toucher (source). Là, par exemple, on pourrait remplacer « Votre implication m’a fait très plaisir » par « m’a fait chaud au coeur ».

On voit bien pourquoi les ouvrages de fiction nous donnent l’impression de nous évader ; l’imagination, entendue comme production d’images mentales, peut mettre en action les zones du cerveau impliquées dans les mêmes actions lorsqu’on les vit réellement. De la même manière, on peut aussi supposer que les métaphores, lorsqu’elles sont utilisées au travail (pour susciter l’attention, expliquer une idée, défendre un point de vue, motiver une équipe…) peuvent jouer un rôle intéressant.

C’est en tous cas ce que nous avons pensé en lisant l’excellent ouvrage More Agile Testing (2014) de Janet Gregory et Lisa Crispin. Le propos, truffé de métaphores intéressantes, en est d’autant plus limpide et stimulant. Nous avons donc décidé d’en sélectionner quelques-unes et de les développer dans une série d’articles.

Pour entrer dans le vif du sujet, voici la première métaphore de notre série, qui vous permettra peut-être de résoudre des situations de conflits d’intérêts.

Vélocité : le bus rapide VS le bus efficace

Problématique

Vous en avez assez de ressasser le sempiternel triangle Coût-Temps-Qualité. Dans certains contextes, vous avez besoin d’une autre image pour faire comprendre que la qualité prend du temps au début, mais qu’il serait contre-productif de la négliger.

Métaphore

Parole à David Evans, coach agile (traduit par nos soins) :

« Le management se montre parfois réticent lorsque je préconise d’écrire collaborativement les tests d’acceptation avant de se lancer dans l’implémentation de chaque story. On m’objecte généralement que cette tâche ralentirait la vélocité du développement. Je leur concède qu’en effet, en une certaine mesure, ça ralentit les choses. Cela dit, s’arrêter pour prendre des passagers ralentit aussi le trajet d’un bus. »

Il cite ensuite Kent Beck dans Test-Driven Development: By example (2002).

« Si écrire des tests d’acceptation avant de se lancer dans l’implémentation ralentit une chose, c’est bien la vitesse de création de code qui ne marchera pas. »

La métaphore du bus met en oeuvre un raisonnement absurde :

  • Les transports publics sont trop lents
  • S’arrêter pour prendre des passagers ralentit les transports publics
  • Donc les transports publics devraient cesser de prendre des passagers.

Si l’on suit cette logique, les transports publics gagneront en rapidité mais le résultat final ne correspondra en rien à ce qui était attendu. Les usagers résilieront leur abonnement, congestionneront le centre ville avec leurs voitures personnelles et critiqueront les transports publics sur les réseaux sociaux.

Nous vous proposons de filer la métaphore d’une manière qui vous permettra maintenant de rejoindre votre interlocuteur. Il s’agit d’abonder dans son sens dans la première partie de l’argumentation, mais de proposer d’autres solutions pour accélérer le trajet du bus. La métaphore devient ici force de créativité. En se projetant dans la problématique du bus, on quitte le quotidien du projet et on suscite de nouvelles idées.

Un exemple :

  • Les transports publics sont trop lents
  • Un ensemble de trajets mal optimisés ralentit les transports publics
  • Donc il faut s’atteler à revoir tout ou partie de ces trajets. Autrement dit : existe-t-il des étapes de notre workflow qui ralentissent le projet sans contrepartie ?

Ou encore :

  • Les transports publics sont trop lents
  • Le trafic des autres modes de transports ralentit les transports publics
  • Donc il faut s’atteler construire des voies dédiées aux transports publics. Autrement dit : existe-t-il des facteurs extérieurs qui ralentissent le projet et que nous pourrions limiter ?

La métaphore nous a servi ici à combattre une idée allant à l’encontre de la qualité du projet, de rejoindre son interlocuteur et d’entamer avec lui une discussions sur l’amélioration des processus.

Conclusion

Les métaphores peuvent donc être utilisées pour mieux nous faire comprendre, en particulier lorsque le sujet est complexe. Mieux encore, en nous faisant voir les choses sous un autre angle, elles peuvent initier une réflexion et susciter de nouvelles idées.

Merci au Guichet du Savoir pour les recherches bibliographiques sur la confirmation expérimentale de la puissance de la métaphore ainsi qu’à Audrey Loiseau qui nous a transmis le GIF. Et merci à vous, qui posterez vos propres métaphores dans les commentaires !

Nous publierons prochainement une autre métaphore issue de More Agile Testing.

SonarQube met son grain de sel dans Gitlab !

Attention, cet article est ancien ! Certaines parties sont peut-être inadaptées à votre stack actuelle. Pour découvrir nos nouveaux article sur le test et la qualité logicielle, nous vous conseillons de consulter la page d’accueil de notre blog. Amusez-vous bien !

La galaxie SonarQube

Dans de précédents articles, nous avons présenté SonarQube, son interface ainsi que son intégration avec Jenkins, et SonarLint, son acolyte qui permet aux développeurs de vérifier la qualité de leur code avant de le commiter. Aujourd’hui, nous voulons affiner encore les choses, et différencier l’analyse des branches features et master.

Cet article présente un applicatif open-source, disponible en l’état et sans garantie. Il est de la responsabilité du SI de vérifier qu’il est conforme à sa politique de sécurité d’une part, et de respecter sa licence d’autre part. Merci à Gabriel Allaigre, de Talanlabs, pour le plugin Sonar-Gitlab !

La procédure suivante met en oeuvre SonarQube, Gitlab et Jenkins en environnement Linux.

Problème initial : trop ou trop peu de données qualimétriques ?

Entre surcharge informationnelle…

Dans un projet donné, il arrive que chaque branche (de feature ou même de bug) fasse l’objet d’une analyse SonarQube à chaque fois que du nouveau code est poussé dessus. Les résultats de cette analyse sont alors stockés dans la base de données et affichés dans l’interface.

Le problème, c’est qu’il en résulte rapidement une liste interminable de « projets » SonarQube qui n’en sont pas ; ce ne sont que des branches ! Ces résultats sont conservés indéfiniment alors qu’ils perdent leur intérêt dès que les branches sont fusionnées.

Comment éviter ce bruit tout en conservant le feedback de SonarQube ?

… et isolement des informations

Par ailleurs, il est assez courant d’entendre des témoignages de ce type : « Nous avons installé SonarQube et des analyses sont régulièrement lancées sur nos projets, mais en pratique on ne les regarde pas souvent. » Effectivement : SonarQube est simple à installer, simple à configurer et simple à utiliser. Le plus difficile est de l’intégrer pleinement aux modes de travail des équipes.

Le plugin présenté ici vise à résoudre le premier problème, tout en apportant un élément de solution au second.

Comprendre les lancements d’analyse SonarQube

Il faut d’abord savoir que SonarQube dispose de 3 modes de lancement :

  • Analysis : il s’agit du mode de lancement par défaut de SonarQube. Tous les fichiers sont analysés et SonarQube crée ou met à jour un projet dans sa base de données.
  • Preview : tous les fichiers sont également analysés mais les résultats ne sont pas stockée dans la base de données.
  • Incremental : seul le fichier courant ou les derniers fichiers modifiés sont analysés. Il s’agit du mode de lancement par défaut de SonarLint.
    Source : https://blog.sonarsource.com/analysis-vs-preview-vs-incremental-preview-in-sonarqube/

Ce sont sur ces modes de lancement que nous allons nous appuyer pour différencier les analyses des branches features et master :

  • Pour la branche master, nous allons continuer d’utiliser le mode analysis, et stocker les résultats dans la base de données.
  • Pour les branches temporaires, nous allons basculer sur le mode preview, ce qui va nous permettre de générer le rapport et de le visionner… sur Gitlab !

L’idée est de permettre à un utilisateur Gitlab dédié (que l’on nommera tout simplement SonarQube) de commenter les commits en indiquant les mauvaises pratiques détectées dans les portions de nouveau code.

Mise en pratique

Récupération du plugin

La dernière version stable du plugin Sonar-Gitlab est disponible depuis le centre de mise à jour de SonarQube, vous pouvez l’y installer directement.

Si vous souhaitez utiliser la toute dernière version du plugin, vous devrez récupérer le projet Sonar Gitlab Plugin sur la page Github du projet, placer le jar dans le répertoire « plugins » de Sonarqube (SONARQUBE_HOME/extensions/plugins) puis redémarrer SonarQube.

Configuration de Gitlab

  1. Créer un compte Gitlab avec comme nom SonarQube
  2. Se connecter sur Gitlab en tant qu’administrateur et attribuer à l’utilisateur SonarQube le profil « Développeur » dans les groupes contenant les projets à analyser
  3. Se connecter sur Gitlab avec l’utilisateur SonarQube et générer un token sur la page http://urldegitlab/profile/personal_access_tokens

Configuration de SonarQube

  1. Se connecter sur SonarQube en tant qu’administrateur
  2. Dans « Configuration », se rendre dans le tout nouvel onglet « Gitlab »
  3. Dans le formulaire qui s’ouvre, renseigner le token
  4. Remplir les champs « Global template » et « Inline template » en adaptant les templates proposés ici : https://gitlab.talanlabs.com/gabriel-allaigre/sonar-gitlab-plugin#examples

Configuration du projet à analyser

  1. Sur Gitlab, récupérer l’id du projet souhaité, qui se trouve dans les Settings du projet.
  2. Sur SonarQube, revenir à l’écran des projets, cliquer sur le projet concerné, puis sur « Configuration » > « Paramètres projet » > « Gitlab »
  3. Dans le formulaire qui s’affiche, renseigner l’id du projet récupéré dans Gitlab et, éventuellement, adapter les barrières qualité du projet
  4. Pour être analysé par SonarQube, un projet doit contenir un fichier sonar-project.properties. Ajouter les deux lignes suivantes à ce fichier :
     sonar.analysis.mode=${MODE_ANALYSE}
     ${GITLAB_CONFIG}

    A noter : les variables ${MODE_ANALYSE} et ${GITLAB_CONFIG} seront remplacées au moment du build Jenkins.

Configuration du job Jenkins

  1. Sur Jenkins, créer un build et ajuster les actions déclenchant le build ; ici, à chaque fois qu’un changement a lieu sur Gitlab
  2. Lors de l’étape de récupération des sources, prendre soin de ne cibler aucune branche en particulier.
  3. Ajouter une étape « Exécuter un script shell » avec le script suivant :
     ID_PROJET="124" # id du projet, à récupérer dans Gitlab
     URL_SONARQUBE="http://urldesonarqube"
     SHA_DERNIER_COMMIT=$GIT_COMMIT
     if ["$GIT_BRANCH" = "origin/master" ];
    then
     echo "Nous sommes sur la branche master. Les résultats de cette analyse seront enregistrés dans la base de données de SonarQube."
     sed -i "s/${MODE_ANALYSE}/publish/g" sonar-project.properties # on suppose que ce fichier est à la racine du projet. Adapter le chemin si besoin.
     sed -i "s/${GITLAB_CONFIG}//g" sonar-project.properties
     else
     echo "Nous sommes sur une autre branche que master. Les résultats de cette analyse seront enregistrés dans les commentaires de l'utilisateur SonarQube dans Gitlab."
     sed -i "s/${MODE_ANALYSE}/preview/g" sonar-project.properties
     # Configuration Gitlab
     sed -i "s/${GITLAB_CONFIG}/sonar.gitlab.commit_sha=${CI_BUILD_REF}nsonar.gitlab.ref_name=${CI_BUILD_REF_NAME}nsonar.gitlab.project_id=${ID_PROJET}nsonar.host.url=${URL_SONARQUBE}nsonar.issuesReport.console.enable=true/g" sonar-project.properties
     sed -i "s/${CI_BUILD_REF}/$SHA_DERNIER_COMMIT/g" sonar-project.properties
     sed -i "s/${CI_BUILD_REF_NAME}/$SHA_DERNIER_COMMIT/g" sonar-project.properties
     fi
  4. Ajouter l’étape de lancement de l’analyse SonarQube.

Intégrer l’analyse de code à tous les niveaux

Récapitulons. Désormais, à chaque changement dans le dépôt Gitlab, un build Jenkins sera lancé. Si c’est la branche master qui est concernée, un rapport sera enregistré dans la base de données de SonarQube ; sinon, des commentaires seront postés sur le commit pour indiquer d’éventuelles mauvaises pratiques dans le nouveau code introduit.

Bonnes analyses !

Vous aimerez peut-être…

Sondez votre code avec SonarQube

La qualité de code en direct avec SonarLint !

Testeur en contexte Agile

L’Agile c’est quoi ?    

La méthode Agile n’est plus vraiment à présenter, cette méthodologie basée sur des cycles itératifs a su s’imposer dans de nombreux projets de développements.

Pour rappel, les 4 valeurs fondamentales de la méthode Agile sont :

  • L’ équipe : « Les individus et leurs interactions, plus que les processus et les outils »
  • L’ application : « Des logiciels opérationnels plus qu’une documentation exhaustive »
  • La collaboration : « La collaboration avec les clients, plus que la négociation contractuelle »
  • L’ acceptation du changement : « L’ adaptation au changement, plus que le suivi d’un plan »

Et le testeur dans ce contexte ?

Le métier du test est en constante évolution de par l’évolution des technologies, des outils de tests automatisés et des méthodes de gestion de projet.

Dans un contexte Agile, le testeur a une place prépondérante pour le succès du projet.

ISTQB en a d’ailleurs fait un syllabus que vous pouvez retrouver ici.

Comment se positionner ? Quels types de tests réaliser ? Avec qui interagir ?

Nous vous donnons quelques clés du succès qui feront de vous un bon testeur Agile dans cette vidéo :

Vous êtes certifié ISTQB fondation ? vous souhaitez être certifié ISTQB testeur Agile ? Contactez nous !!

Vous aimerez peut-être…

5 graphiques Jira pour mieux communiquer sur les anomalies

Réunion de clôture : un jeu pour finir en beauté !

Respectons le sens des valeurs agiles (blog d’Atlas Management)

 

5 graphiques Jira pour mieux communiquer sur les anomalies

Relecture 2023 : bien que cet article date un peu, nous confirmons qu’il est toujours d’actualité 😉 Bonne lecture et amusez-vous bien à créer tous les graphiques qui vous aideront dans votre quotidien de QA !

Avoir les bonnes métriques au bon moment

« Combien a-t-on d’anomalies ouvertes ? »

Voilà une question que les QA entendent parfois, mais qui n’amène qu’une réponse assez sommaire.

Le produit comptabilise 200 anomalies ouvertes ? Simplement en tenant compte de la criticité des bugs, on découvrira peut-être qu’il est de meilleure qualité qu’il y a quelques mois, où il n’en comptait que 150.

Une liste d’anomalies en dit long sur son projet. En prenant le temps de l’analyser, on peut être en mesure de répondre aux questions suivantes :

  • Où se regroupent les défauts ?
  • Comment la qualité du produit évolue-t-elle dans le temps ?
  • Le nombre de régressions augmente-t-il ou diminue-t-il ?

Autant d’informations qui permettent de détecter aussi bien des risques projet que des risques produit.

Dans votre organisation, si la gestion des anomalies se fait sur Jira, cet outil vous sera d’une grande aide pour analyser et communiquer autour des anomalies de vos projets. Il permet de créer un certain nombre de graphiques, appelés « gadgets ». En voici quelques mises en pratique !

Dans cet article nous parlons indifféremment de « demandes » ou « tickets » Jira.

Prérequis : savoir comment gérer les filtres Jira

Les filtres constituent une fonctionnalité phare de Jira. Ils permettent aussi bien de retrouver rapidement un lot de demandes que de créer des graphiques à partir de celles-ci.

Après avoir effectué une recherche à plusieurs critères, il suffit d’enregistrer celle-ci en lui donnant un nom. Votre filtre est prêt à être utilisé. Pour cela, rendez-vous dans l’onglet « Tableaux de bord » et cliquez sur « Ajouter un gadget ».

Comptabiliser une dimension des anomalies avec le graphique « Statistiques de filtre bidimensionnel »

Le graphique « Statistiques de filtre bidimensionnel », très simple, permet de visualiser une facette donnée d’un lot de demandes. Ici, nous avons choisi en première dimension le champ dédié à la sévérité des bugs. Ce qui nuance, comme dit précédemment, le simple nombre de bugs.

Pour rappel, le lot d’anomalies est défini par le filtre choisi. Il peut être intéressant de comparer un graphique portant sur toutes les anomalies d’un projet, à un graphique portant uniquement sur les anomalies ouvertes de ce projet.

Sur ce graphique, on voit également le statut des différents bugs (la 2ème dimension), ce qui permet par exemple d’évaluer si l’effort de correction est bien dirigé vers les sévérités les plus élevées.

Identifier les zones à risque de l’application avec le graphique « Carte thermique »

Créer un nuage de bugs

L’un des 7 principes généraux du test énoncés par l’ISTQB met en valeur la tendance des bugs à se regrouper. Par expérience, les QA affectés depuis quelques temps à un projet donné sauront où focaliser l’effort de test, en particulier lors de ses tests exploratoires. Mais cela ne suffit pas : il faut aussi pouvoir mettre en évidence auprès de toutes les parties prenantes les zones sensibles de l’application, afin qu’elles y accordent une attention particulière.

Sur Jira, le gadget « Carte thermique » génère un nuage de mots qui affiche chacun d’eux avec une police proportionnelle à son nombre d’occurrences. Ces mots peuvent être issus d’une multitudes de critères. Dans un projet donné, chaque anomalie peut se voir attribuer une ou plusieurs étiquettes correspondant aux blocs fonctionnels concernés. La carte thermique portant sur les étiquettes permettra alors d’identifier les fonctionnalités les plus sensibles, comme ci-dessous.

Avantages de ce graphique

Cette vision peut aider à organiser la correction d’anomalies en mettant entre parenthèses le seul critère de priorité. Cela présente plusieurs avantages. Quand une personne se charge d’un lot d’anomalies concentrées sur une même fonctionnalité :

  • Elle termine généralement le travail plus rapidement que si plusieurs personnes s’y étaient attelé les unes après les autres
  • Comme elle se plonge dans la fonctionnalité dans son ensemble, elle monte en compétence sur l’ensemble de ses aspects, ce qui pourra l’aider à la faire évoluer par la suite
  • A l’issue de cette correction, le client peut se sentir soulagé de constater que pour une fonctionnalité, tout fonctionne correctement
  • Des anomalies mineures ou triviales, qui auraient été ignorées sinon, peuvent être épongées.

Evaluer la dette technique avec le graphique « Demandes créées comparées aux demandes résolues »

Comme dit précédemment, le nombre d’anomalies ouvertes peut s’interpréter de différentes façons. Il est aussi intéressant d’analyser le graphique comparant le nombre de demandes créées au nombre de demandes résolues, pour adapter si besoin l’effort de correction d’anomalies. Un gadget dédié est disponible sur Jira.

Très parlant, il permet de voir en un coup d’oeil si la dette technique est en train de se résorber ou au contraire de s’accentuer.

Identifier les moments critiques avec le graphique « Plage de demandes »

« Cette appli est de plus en plus buggée ! »

Le graphique « Plage de demandes », ou « Plage de tickets », permet de communiquer sur le nombre d’ouvertures de bugs au fil du temps. Prenez le temps de bien expliciter les différentes hausses et baisses, qui peuvent être dues à des facteurs très différents (nouvel interfaçage avec un autre système complexe, congés d’une partie de l’équipe, livraison de nouvelles fonctionnalités, phase soutenue de correction d’anomalies, arrivée de nouvelles recrues dans l’équipe de test, refacto…)

Pensez à désactiver l’option « cumulative ». Sans cela, le graphique afficherait une courbe croissante, qui ne permettrait pas aussi bien d’identifier les pics de bugs.

Par exemple, sur le graphique ci-dessus, nous voyons qu’entre novembre et février l’équipe a ouvert énormément d’anomalies, puis que le nombre de rapports de bugs ouvert a baissé.

Evaluer le turn-over des bugs avec le graphique « Âge moyen »

Assez difficile à interpréter, ce graphique peut toutefois fournir des chiffres « choc » pour motiver la correction d’anomalies.

Un bémol cependant : ces chiffres sont de moins en moins parlants au fil du temps, car dans l’ensemble, il est normal que les bugs bloquants récents soient corrigés avant les bugs triviaux anciens.

Il peut être intéressant d’ajouter la notion de criticité à ce filtre.

Quand on considère le graphique ci-dessus, on peut supposer que le rythme de correction des anomalies a baissé et que de la dette technique s’est accumulée.

Partager les graphiques

Il est important que les parties prenantes puissent accéder aux graphiques à volonté. Cela permettra à tout un chacun de prendre quand il le souhaite la température du projet. Pour cela, plusieurs solutions :

  • Insérer ces graphiques dans un ou plusieurs tableaux de bord partagés (sur Jira)
  • Profiter de l’intégration Jira-Confluence pour intégrer les gadgets sur une page de wiki, ce qui permettra de commenter au fur et à mesure l’évolution des données affichées.
  • Périodiquement, envoyer des rapports (par mail ou autre) intégrant des copies d’écran de ces graphiques, avec un lien pour accéder à leur version dynamique.

Nous espérons vous avoir donné des idées, n’hésitez pas à partager vos propres graphiques avec nous !

Vous aimerez peut-être…

Testeur en contexte Agile, pour (re)découvrir le rôle des QA en contexte Scrum

L’épineuse question des KPI, parce que tous ces beaux graphiques Jira peuvent générer de précieuses métriques utiles à toute l’équipe et sa performance !

World Quality Report 2017-2018 : focus sur l’agilité, les tests mobiles et l’automatisation

Une étude annuelle sur le monde du test logiciel

Le premier World Quality Report (en bon français, rapport mondial sur l’assurance qualité) a été publié en 2009 par Capgemini. D’année en année, l’étude s’est étoffée, a gagné en moyens et en notoriété. En 2017, le World Quality Report, c’est :

  • 1660 seniors de l’IT interrogés
  • 32 pays représentés (dont la France, avec 150 personnes interrogées)
  • Une photographie à l’instant T de l’assurance qualité dans les organisations publiques et privées de plus de 1000 employés
  • Des focus par thème, mais aussi par type d’entreprise
  • Des recommandations pour faire face aux problématiques actuelles du métier

Bref, un panorama intéressant à décoder, en gardant tout de même à l’esprit que cette année l’étude a été commanditée par la Sogeti et Capgemini, en partenariat avec l’éditeur Microfocus. Ce pure-player a notamment développé Silk Test et, plus dernièrement, racheté un large portefeuille de logiciels d’Hewlett-Packard Enterprise, dont Loadrunner. Ce qui n’est pas neutre

Notre article fait le point sur trois sujets brûlants dans le domaine du test logiciel : les transformations du métier induites par l’émergence de l’agilité, le défi encore peu exploré des tests mobiles et les challenges liés à l’automatisation des tests.

Le boom du test agile

Les chiffres du test agile

En développement comme en test, le World Quality Report révèle que l’agilité a le vent en poupe. 95% des répondants affirment mettre en oeuvre des pratiques de test agile, au moins sur une partie de leurs projets. 37% des entreprises pratiquent le test exploratoire.

Les pratiques devOps aussi sont également en expansion, et sont désormais représentées dans 88% des entreprises interrogées. Cependant, elles ne touchent jamais la totalité des projets, et concernent moins de 20% des projets dans 47% de l’ensemble des entreprises.

De nouvelles contraintes

Face à cette transformation, les forces vives du test tendent à se décentraliser, et affrontent notamment trois problématiques :

  • La création d’environnements de test idoines et de jeux de données réalistes, qui notamment respectent les lois en vigueur (« QA teams need to help their organizations comply with new data laws such as the EU’s General Data Protection Regulation », ce qui nous rappelle une fois de plus l’aspect juridique du métier de testeur). Cette problématique rend également difficile l’automatisation des tests et les tests mobiles.
  • La réutilisation et la répétition des tests au fil des itérations
  • Le manque de méthodologie de test agile

Même si la décentralisation du test présente de nombreux avantages, le WQR conseille aux grandes organisations de conserver un organe central (un « TEC » ou « Test Excellence Center ») afin d’harmoniser les pratiques, de capitaliser sur les réussites et de réaliser des POCs.

Automatisation des tests : un horizon impossible ?

Les chiffres de l’automatisation des tests

Le World Quality Report de 2017 révèle que presque la moitié des entreprises (48%, et jusqu’à 57% des entreprises spécialisées dans les télécoms, les médias et les divertissements), se trouvent trop dépendantes des tests manuels. Et effectivement, le chiffre peut étonner : seuls 16% des cas de test fonctionnels sont automatisés !

Parmi les difficultés le plus fréquemment rencontrées, on retrouve :

Autant de challenges qui freinent l’avancement des projets d’automatisation, et augmentent année après année le manque à gagner.

Des pistes pour mieux automatiser les tests

Face à ce constat, le World Quality Report conseille de s’armer de patience. Le rapport indique que parmi les entreprises ayant mis en oeuvre une stratégie d’automatisation des tests, celles dont la démarche a été la plus fructueuse ont commencé par des projets-pilotes autonomes (à l’inverse d’une approche « big bang »).

Il est aussi conseillé de prendre au sérieux la formation en automatisation des tests des équipes qualité, où d’importantes lacunes sont constatées.

Enfin, la présence d’une réelle stratégie et la transparence des reportings des tests automatisés sont cités comme des critères de réussite majeurs.

Tests mobiles : ça pourrait bouger plus

C’est ce qui ressemble à la cinquième roue du carrosse : 52% des répondants n’ont pas assez de temps pour mener des tests mobiles. 47% pointent un manque de méthodologie dans le domaine, 46% ne disposent pas d’équipements adéquats. 5% des organisations interrogées ne font même aucun test mobile.

Ces chiffres sont étonnants, à l’heure où des solutions open-source telles qu’Appium, ou des IDE performants et gratuits comme Katalon, permettent de mettre en oeuvre à moindre coût des stratégies de test mobile, y compris en externalisant la gestion des hardwares (avec par exemple AWS Device Farm, Xamarin Test Cloud ou Kobiton).

Un point intéressant à relever est que les tests non-fonctionnels sont bien représentés dans le domaine du test mobile :

  • 53% des stratégies incluent des tests de performance
  • 43%, des tests de sécurité
  • 39%, des tests de compatibilité
  • 38%, des tests de portabilité,

Contre 48% pour les tests d’interface utilisateur.

Plongée dans le passé : quoi de neuf depuis 2009 ?

L’automatisation des tests était déjà source d’embarras

Certaines choses ne changent pas : en 2009, les entreprises étaient déjà frustrées par leur taux d’automatisation des tests. Le World Quality Report indiquait en effet que 50% des entreprises n’avaient pas atteint leurs objectifs d’automatisation 3 ans après avoir acquis les outils ad hoc. En cause : le manque de plannification, de stratégie sur le long terme et de formation des testeurs. A l’époque, des solutions d’automatisation existaient déjà depuis une quinzaine d’année.

… mais la vision de l’automatisation a mûri

Il existait à l’époque un aspect qui peut maintenant nous étonner : dans l’édition de 2009, la majorité des personnes interrogées pensaient que l’automatisation des tests pourrait aider à réduire la taille de l’équipe de test. Une corrélation qui de nos jours paraît naïve, et qui a d’ailleurs totalement disparu dans l’édition de cette année.

On est sortis de la crise…

Dans le WQR de 2009 transparaît un sentiment d’inquiétude lié à la crise. L’agilité est directement assimilée à un gain pécuniaire, les robots de test semblent voués à remplacer les humains… Il est réjouissant de constater qu’en 2017, ce biais a disparu (au profit d’autres que nous n’identifierons sans doute, hélas, qu’en 2025).

… et on a découvert tant d’autres choses

Pour faire bref, voici quelques mots que l’on ne trouvait pas encore dans la première édition du World Quality Report :

  • Mobile
  • API
  • Load testing
  • DevOps (et pour cause, le mot a été inventé deux mois après la parution du WQR de 2009 !)

La sécurité applicative, la performance et le cloud sont brièvement évoqués, mais on ne les retrouve pas plus loin que dans l’introduction. Bref, depuis la première édition du WQR, le métier du test n’a eu de cesse de s’étoffer. Multidisciplinaire en pratique, il l’est devenu de plein droit au fil des années.

Conclusion

Certes, il n’est pas toujours facile de comprendre comment sont générés les chiffres du World Quality Report. « Nous ne pratiquons pas le test agile » : ils étaient 2% à l’affirmer en 2015, contre 31% en 2016 (!) et maintenant 5% en 2017… Mais malgré ce genre de bizarreries que l’on retrouve tout du long, ainsi que quelques partis pris qui s’expliquent par les commanditaires de l’étude (par exemple l’évocation de TMap, mais pas d’ISTQB) le WQR reste un document utile pour prendre la température du monde du test et comprendre les problématiques auxquelles font face aujourd’hui les grandes organisations. Une analyse qui s’avère encore plus intéressante lorsqu’on la met en parallèle avec les éditions précédentes. Alors bonne lecture !

Ressources

World Quality Report de 2009 (pdf)

World Quality Report de 2017 (formulaire de téléchargement)

Vous aimerez peut-être…

Chiffres sur l’accessibilité du web calédonien

9 points juridiques que chaque QA devrait maîtriser

Le test logiciel est une protection contre les bugs, mais aussi contre les litiges. Vous avez un doute ? Cet article est fait pour vous.

La loi relative à l’informatique, aux fichiers et aux libertés, indique :

Constitue une donnée à caractère personnel toute information relative à une personne physique identifiée ou qui peut être identifiée, directement ou indirectement, par référence à un numéro d’identification ou à un ou plusieurs éléments qui lui sont propres.

Sous peine de sanctions, ce type de données doit faire l’objet d’un traitement particulier. Toute personne travaillant dans la qualité logicielle devrait valider que les données personnelles sont manipulées de manière légale.

1) Il est obligatoire d’assurer la sécurité des données personnelles

Comme le dit l’article 34 de la loi,

Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu’elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès.

La loi est sans équivoque : la sécurité des données personnelles relève de la responsabilité de celui qui les traite. En cas d’attaque informatique, l’entreprise victime de l’attaque peut être poursuivie en justice par ses internautes. Double effet kiss cool.

Les QA, connaissant cette problématique, doivent veiller à ce qu’elle soit soulevée au plus tôt, et si possible renforcer la sécurité des informations en pratiquant des tests de sécurité.

2) Le traitement des données doit être transparent

Les utilisateurs doivent être informés de leurs droits. Pouvoir consulter les mentions légales (dont le contenu est également réglementé) est obligatoire.

3) La localisation des données est réglementée

Transférer des données personnelles en-dehors de l’UE a des implications juridiques. Il est important de savoir vers quels pays les données personnelles peuvent être transférées. A titre d’exemple, en mars 2017, il est possible de transférer des données personnelles en Argentine, mais pas en Australie.

4) Envoyer un mail peut être un délit

Envoyer un mail ne coûte rien… mais ce n’est pas toujours autorisé. Il est interdit d’envoyer des mails commerciaux à des adresses trouvées dans des espaces considérés comme publics : pages web sans authentification, forums de discussion, annuaires.

Le cas échéant, si un internaute donne volontairement son adresse e-mail, il faut impérativement lui dire qu’il est susceptible de recevoir des offres commerciales.

Tout courrier commercial doit proposer un lien de désinscription.

Dans les formulaires, les cases à cocher proposant l’envoi de mails publicitaires doivent être décochées par défaut.

Plus d’informations ici.

5) Ne pas crypter les mots de passe peut coûter cher

Il est interdit de conserver en base de données des mots de passe non cryptés, comme Optical Center qui, en 2014, en a fait les frais. 50 000 euros d’amende ont dû être déboursés. Un coût financier mais aussi réputationnel… A cet effet, la CNIL donne des éléments pour mettre les mots de passe en sécurité.

6) Stocker certaines données est interdit

Une donnée sensible, au sens CNIL, concerne un ou plusieurs des aspects suivants de l’internaute :

  • ses origines raciales ou ethniques,
  • ses opinions politiques, philosophiques ou religieuses,
  • ses appartenances syndicales,
  • sa santé ou son orientation sexuelle,
  • ses données génétiques ou biométriques,
  • son passé judiciaire,
  • son numéro de sécurité sociale.

Attention, certaines données sont sensibles sans en avoir l’air. Vous demandez à vos utilisateurs s’ils sont végétariens, végans, au régime sans gluten, sans oeufs, sans porc, sans lactose ? Sans le savoir, vous êtes sur le point de stocker une donnée sensible dans votre base de données. Demandez-vous si le risque en vaut la peine.

Le traitement des données sensibles est en principe interdit. Si ces informations sont vraiment nécessaires, leur recueil doit être justifié et nécessite le consentement exprès de la personne. Par prudence, il est conseillé de demander un avis sur les données sensibles à la CNIL, voire une demande d’autorisation (obligatoire par exemple pour le numéro de sécurité sociale). Attention, la réponse peut prendre quelques mois avant d’arriver.

Toutes les données sensibles sont concernées : celles déclarées par les utilisateurs sur le site, celles recueillies « IRL » et informatisées ensuite, et même si ces informations sont prévues pour être utilisées strictement en interne. La CNIL donne une définition précise de la donnée sensible.

7) Il est interdit de placer un cookie sans autorisation

Il est obligatoire de :

  • communiquer aux internautes la finalité des cookies
  • demander leur consentement (dont la durée maximale de validité est de 13 mois)
  • leur fournir un moyen de refuser les cookies.

Et tout cela, avant de générer le cookie.

En savoir plus sur les cookies

Respecter la propriété intellectuelle

8) Les contenus textuels et multimédias doivent être contrôlés

Des questions de bon sens sont de rigueur :

  • Les contenus affichés par le système à tester appartiennent-ils à sa société éditrice ? Si non, les autorisations idoines ont-elle été produites ?
  • Les crédits sont-ils correctement mentionnés ?
  • Le droit de courte citation est-il correctement appliqué ? Le contenu est-il exempt de plagiat ?
  • Les personnes dont les photos apparaissent ont-elle donné une autorisation explicite ?

Quelques vérifications bien utiles, qui prendront peu de temps à l’équipe de test et pourront éviter litiges et bad buzz.

9) Les briques open-source peuvent imposer des contraintes qu’il faut respecter

Si le produit comprend des briques issues de programmes open-source, il est essentiel de respecter la licence qui leur est associée. Attention, certains logiciels open-source obligent à partager leurs versions modifiées (par exemple avec la licence GNU GPL).

Conclusion

Certes, les QA ne sont pas des juristes. Dans une vision 360° de la qualité, nous devons pourtant être capables de porter un regard critique sur les aspects juridiques du système à tester. Les champs d’étude sont extrêmement vastes : il faudrait encore parler du droit à l’oubli, des lois propres aux sites de e-commerce… Nous ne saurions assez vous conseiller d’investiguer afin de comprendre jusqu’où les tests peuvent aller.

Bonus

La qualité de code en direct avec SonarLint !

Attention, cet article est ancien et certains de ces éléments ne sont peut-être plus d’actualité. Pour découvrir nos articles les plus récents, nous vous invitons à découvrir la page d’accueil de notre blog !

À quoi sert SonarLint ?

Après notre présentation de SonarQube, nous vous proposons maintenant de prendre le problème de la qualité de code à la racine avec le linter SonarLint.

Qu’est-ce qu’un linter ?

Un linter est un utilitaire d’analyse de code. Ce type d’outil permet de déceler les éventuelles erreurs et problèmes syntaxiques. On parle de « linter son code » (en bon franglais !), ce qui consiste à lancer une analyse de code afin de le rendre plus maintenable, plus lisible et globalement plus qualitatif. Le linter ne procède pas aux corrections et modifications du code ; cela reste au développeur d’arbitrer sur la solution à mettre en œuvre.

Que fait SonarLint ?

SonarLint est un plugin permettant de réaliser les analyse de code SonarQube au fil des développements, directement dans l’IDE. Un bon coup de pouce pour identifier au plus tôt, c’est-à-dire avant même le commit, les points à corriger. De ce fait, le coût de la qualité du code est extrêmement réduit, voire invisible, à l’inverse des lourdes campagnes correctives qui interviennent sur du code déjà mergé depuis longtemps.

Ici, un exemple avec Intellij. Il est à noter que ce plugin est également disponible pour les IDE Eclipse et Visual Studio.

Installation du plugin SonarLint sur Intellij

  • Ouvrir Intellij
  • Aller dans « File » > « Settings » > « Plugins »
  • Cliquer sur « Browse repositories »
  • Rechercher « SonarLint », l’installer et redémarrer Intellij

Lancer une analyse SonarLint

Pour lancer une analyse, cliquez sur l’onglet « Analyze » d’Intellij. Vous verrez les options SonarLint dans une liste déroulante.

Si par exemple nous lançons une analyse sur tous les fichiers (attention, cette opération peut s’avérer assez longue sur les gros projets), nous obtenons une vue telle que celle-ci :

Un double-clic sur une anomalie permet d’accéder à la ligne de code en question, ainsi qu’à l’explication du problème afin de pouvoir le corriger en connaissance de cause.

Intégration de SonarLint avec un serveur SonarQube

Partagez vos règles SonarQube sur tous les postes

Très bien, nous pouvons maintenant voir très rapidement les défauts de notre code dans la console SonarLint. Mais ce qui serait encore mieux, ce serait de partager les mêmes règles que le reste de l’équipe, à savoir les règles définies dans le serveur SonarQube central. Ces règles correspondent au(x) profil(s) qualité utilisé(s) pour le projet.

Pour ce faire :

  • Aller dans « File » > « Settings » > « Other settings » > « SonarLint General Settings ».
  • Ajouter un serveur SonarQube. Pour ce faire, il y a besoin d’un token (souvenez-vous, nous en avions besoin aussi pour interfacer SonarQube avec Jenkins !), ou d’un couple login/password.
  • Dans l’onglet « SonarLint Project Settings », associer le projet courant au projet correspondant dans SonarQube. Il est important que le nom du projet soit le même dans les deux outils.
  • De retour dans l’onglet « SonarLint General Settings », cliquer sur le bouton « Update binding ».

Désormais, vous partagez dans votre IDE le même profil qualité que votre projet SonarQube. Faites un test : introduisez un bug dans votre code, changez la priorité de ce bug dans SonarQube, cliquez de nouveau sur le bouton « Update binding » dans les Settings d’Intellij, et vous verrez que la priorité du bug changera également dans votre IDE lors de la prochaine analyse. Si ce n’est pas le cas, c’est que vous avez manqué une étape !

Résolution de version

Au moment de la mise à jour du lien SonarQube – SonarLint, une popup d’erreur peut survenir, avec un message comme celui-ci :

The following plugins do not meet the required minimum versions, please upgrade them: *** (installed: x.x, minimum: x.x).

Il s’agit la plupart du temps d’un package de règles d’un langage qui doit être mis à jour dans SonarQube. Pour régler ce problème de version :

  • Se rendre sur l’interface SonarQube
  • Se connecter avec un compte administrateur
  • Aller dans « Configuration » > « Système » > « Mises à jour »
  • Mettre à jour le module mentionné dans le message d’erreur

Conclusion

Le plugin SonarLint représente une opportunité pour les développeurs, car il aide à renforcer la qualité de code au fur et à mesure de l’écriture. Moins de risque d’oublis donc, et un allègement significatif des retours produits lors de la revue de code.

Un point d’alerte toutefois : il faut veiller à ce que les règles définies dans le profil qualité soient pertinentes, c’est-à-dire adaptées à la fois au projet et à l’équipe concernée. Sans cela, une part plus ou moins importante des analyses produites par SonarLint sera tout simplement ignorée par les équipes de développement. Le syndrome de Cassandre dans le domaine de la qualité de code, cela vous parle ? Si oui, vous découvrirez avec plaisir un outil permettant d’en sortir

Vous aimerez peut-être…

Sondez votre code avec SonarQube

SonarQube met son grain de sel dans Gitlab !

Performance, charge, stress… quelle différence ?

Vocabulaire ISTQB : on fait le point !

Dans le domaine du test comme ailleurs, il est important de bien nommer les choses afin de partager un langage commun avec ses interlocuteurs.

Quelle est donc la différence entre un test de charge et un test de performance ? S’agit-il de la même chose que d’un test de stress ? De robustesse ?… Sans avoir connaissance des définitions précises de ces termes, il est facile de s’emmêler les pinceaux.

Or, il arrive que des sons de cloche ne s’accordent pas, et par exemple que des sites se contredisent entre eux. Pourquoi ? D’une part, parce que les tests se ressemblent et mettent parfois en jeu les mêmes outils. D’autre part, parce que les termes évoquent des choses similaires ; dans la vie de tous les jours, on peut dire qu’une équipe performante est capable de tenir une grosse charge de travail en gérant bien son stress.

Il est donc important de se baser sur une source qui fasse autorité et permette de trancher ! Ici, nous nous réfèrerons au glossaire officiel de l’ISTQB, un « must-have » et un « must-read » pour les testeurs.  Plongeons-nous donc dans les définitions de ces termes !

Qu’est-ce qu’un test de performance ?

Test de performance : le processus de test pour déterminer les performances d‘un produit logiciel.

Performance : degré en fonction duquel le système ou composant accomplit les fonctions qui lui sont affectées dans le respect de contraintes données en ce qui concerne son temps d‘exécution et taux de débit. [d‘après IEEE 610]

Le but du test de performance est de fournir des métriques sur la rapidité de l’application. On veut déterminer si elle est capable d’exécuter ses fonctionnalités en un temps acceptable. La priorité n’est pas de connaître les performances de l’application dans un contexte particulier. Pour cela, un autre type de test peut être distingué : le test de rendement.

Le test de performance répond à la question : l’application est-elle suffisamment rapide ?

Des APIs permettent de diagnostiquer rapidement les problèmes de performances d’une page web. La plus utilisée est certainement PageSpeed, développée par Google. Elle founit un score sur 100, ainsi que des pistes pour améliorer la vitesse de chargement de la page.

Amusez-vous à utiliser cette ressource pour évaluer la performance de votre site web !

Voici par exemple les résultats du calcul des performances du site Testeum :

Qu’est-ce qu’un test de rendement ?

Test de rendement : le processus de test pour déterminer le rendement d‘un produit logiciel.

Rendement : la capacité du produit logiciel à fournir des performances appropriées, relatives au niveau de ressources utilisées dans des conditions spécifiées. [ISO 9126]

Le test de rendement introduit la notion de « conditions ». Le test de rendement permet d’établir un rapport entre performances et ressources utilisées dans un contexte réaliste (ex : plusieurs utilisateurs connectés en même temps, réalisant des requêtes consommant plus ou moins de ressources).

Le test de rendement répond à la question : l’application est-elle suffisamment rapide dans un contexte donné ?

Qu’est-ce qu’un test de charge ?

Test de charge : un type de test concerné par la mesure du comportement d‘un composant ou système avec une charge croissante, p.ex. nombre d‘utilisateurs et/ou nombre de transactions en parallèle pour déterminer quelle charge peut être gérée par le composant ou système

Le test de charge recherche la limite des capacités de l’application. En augmentant graduellement la charge à laquelle est soumise l’application, il est possible d’identifier des paliers. On peut considérer le test de charge comme un pré-requis au test de stress.

Le test de charge répond à la question : quelle est la charge maximale supportée par l’application ?

Qu’est-ce qu’un test de stress ?

Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l‘accès mémoire ou serveurs [d‘après IEEE 610].

Le test de stress permet d’anticiper les performances d’une application en contexte exceptionnel (afflux non anticipé d’utilisateurs, panne). Un cas d’école : l’explosion des visites sur un site de e-commerce le premier jour des soldes. On peut considérer le test de stress comme une catégorie de test de robustesse.

Le test de stress répond à la question : comment réagit l’application lorsqu’elle est soumise à sa charge maximale ?

Qu’est-ce qu’un test de robustesse ?

Test de robustesse : test concernant le degré pour lequel un composant ou système peut fonctionner correctement en présence de données d‘entrée invalides ou de conditions environnementales stressantes.

Le test de robustesse permet de vérifier qu’une application reste opérationnelle en contexte exceptionnel. Les menaces testées viennent aussi bien d’une charge importante (comme le test de stress) que de comportements non souhaités (flux d’informations incorrectes, de fichiers corrompus…)

Le test de robustesse répond à la question : comment réagit l’application lorsqu’elle est soumise à des inputs ou un contexte exceptionnels ?

Autant de tests non-fonctionnels…

Malgré leur synonymie apparente, les différents termes que nous venons de présenter donnent donc lieu à des tests spécifiques, que nous ne devrions pas confondre afin de maintenir une communication claire.

Envie de passer une certification ISTQB ?

Si vous souhaitez approfondir vos connaissances en test, nous organisons à la demande des accompagnements à la maîtrise d’ISTQB à Nouméa. Hightest est organisme de certification accrédité par le GASQ depuis 2015 et est habilité à organiser des examens ISTQB. Pour plus d’informations, veuillez prendre contact avec nous !

Et pour vos révisions, jetez un oeil à notre article Les 7 principes généraux du test en illustrations et à nos différents quiz en ligne !

3 maladies de l’automatisation des tests

Le testeur chargé de l’automatisation des tests est vulnérable à des troubles qui lui sont propres. Il est important de les connaître pour mieux s’en protéger.

La logopathie – Trouble cognitif

Symptôme

Le patient est le seul de son équipe à pouvoir lire les logs produits par ses tests automatisés. Souffrant d’une apparente dissonnance cognitive, il énonce des propos déroutants tels que « Tous ceux-ci ne passent pas mais c’est normal ».

Cause

Trop absorbé par le développement de ses automates, le patient a négligé la qualité du reporting, un élément pourtant nécessaire à la compréhension des résultats des tests.

Complications possibles

  • L’équipe devient dépendante de son testeur automaticien. Par conséquent, s’il est absent, il est impossible d’analyser les résultats des tests automatisés.
  • Analyser les logs devient si compliqué que, par manque de temps, on ne lance plus les tests automatisés. Tout le temps consacré à ce travail est désormais perdu.
  • Dans le pire des cas, on finit par abandonner l’automatisation des tests.

Mesures préventives

  • Utiliser un framework de test BDD : Gebish, Cucumber… qui prendra en charge nativement un reporting d’une clarté satisfaisante.
  • A défaut, anticiper cette problématique dès le début du projet d’automatisation. Pour chaque étape du test automatisé, générer un log en bon français. Il est également important de faire savoir où se trouvent les reportings, afin que les personnes concernées puissent les trouver en toute autonomie.

Remèdes possibles

Allouer du temps à cette problématique en communiquant sur son importance. Chiffrer les gains de temps possibles en analyse.

Si vous utilisez Selenium, une petite virée sur notre article dédié à la qualité des logs Selenium vous redonnera des couleurs.

Troubles associés

Le documutisme (trouble de la communication). Le patient n’a pas conscience de la complexité de son projet et/ou ressent une aversion envers les tâches documentaires. Il en résulte une aura de mystère autour des travaux d’automatisation des tests. Seuls quelques proches du patient ont été instruits de bouche à oreille et sont en mesure de comprendre, de loin en loin, ce dont il est question.

L’automatite – Trouble de l’identité

Symptôme

Le patient agit davantage en « automaticien » qu’en testeur. Il enchaîne les scénarios et automatise au kilomètre.

Cause

Le testeur chargé de l’automatisation des tests est soumis à une forte exposition à des problématiques purement techniques. Comment cliquer sur le premier bouton visible en ignorant les boutons cachés qui le précèdent ? Comment naviguer entre 2 popups ou plus ? Comment autoriser ou interdire la géolocalisation sur tel ou tel navigateur ? Cette charge cognitive peut le mener à oublier le pourquoi au profit du comment. Le patient devrait, en temps normal, être en mesure de conserver un œil critique sur les scénarios qu’il doit automatiser.

Complications possibles

  • Faute de recul, le patient perd un temps précieux à automatiser des scénarios à faible valeur ajoutée.
  • Le patient passe à côté de bugs qu’il aurait pu trouver.
  • Les reportings perdent en pertinence.

Mesures préventives

Dès le début du projet, prévoir des rôles hybrides. La dichotomie entre le testeur manuel et le testeur automaticien, décriée par certains, pourrait être néfaste au métabolisme de l’équipe de test.

Vu sur https://mrslavchev.com

Remèdes possibles

Redonner une vision d’ensemble de la qualité du produit en introduisant des phases de test manuel et de rédaction de cas de test dans l’emploi du temps du patient.

Troubles associés

Chez le testeur dit manuel, la checklistopathie paralyse les mêmes neurones que l’automatite. Les deux types de malades ont besoin, pour recouvrer la santé, de raviver leur curiosité et leur passion pour le fouinage logiciel.

La scalophobie – Trouble de la motricité

Symptôme

Le patient se trouve face à un projet d’automatisation des tests dont il n’a pas suffisamment étudié la scalabilité. L’architecture est brouillonne et difficile à maintenir. Le patient évolue avec difficulté au sein d’un écosystème qu’il a lui-même créé.

Cause

Avide d’avancer rapidement dans l’automatisation des scénarios, le patient a consacré un temps insuffisant à la conception de l’architecture de son projet d’automatisation.

Complications possibles

  • Importantes pertes de temps en maintenance.
  • Difficulté à intégrer de nouveaux collaborateurs dans le projet.
  • Risques accrus de contracter la logopathie

Mesures préventives

En début de projet, dédier une plage de temps suffisante à la conception de l’architecture du projet. Communiquer sur l’importance de cette phase. S’appuyer sur des design patterns éprouvés, tels que le Page Object (dont nous donnions dernièrement un exemple avec Protractor).

Remèdes possibles

Une bonne refactothérapie !

Troubles associés

La scalophobie de type documentaire, qui affecte les testeurs en charge de la rédaction des cas de test.

Conclusion

Il est essentiel de maintenir une bonne hygiène de vie afin d’éviter les maladies que nous venons de lister. Garder le cap sur les objectifs de l’automatisation, communiquer avec son entourage et conserver un recul sur ses activités permettra au testeur de rallonger l’espérance de vie de ses automates et de booster leur tonus au quotidien.

Bon courage !

Vous aimerez peut-être aussi…

Ce n’est pas un bug, c’est un poème

Les 7 principes généraux du test en illustrations

Le kit de secours métaphorique du testeur agile

Vous avez à coeur de respecter les bonnes pratiques de tests automatisés ? Cette page mémo pourrait vous être utile !

Protractor + AngularJS : Structure d’un projet industrialisé

Note préalable : cet article date de 2017. Depuis, Protractor a atteint la fin de sa vie. Merci à lui et surtout aux personnes qui ont contribué à cet outil !

Diviser pour mieux tester

Bienvenue dans la 3ème et dernière partie de notre série d’articles sur la découverte des tests Protractor ! Dans l’article précédent, nous avons vu pourquoi et comment séparer les jeux de données et les scripts de test. Aujourd’hui, nous poursuivons sur notre lancée en isolant la description des pages et en structurant les dossier du projet.

  1. Installation et exemple de script
  2. Gestion des jeux de données et des dépendances du projet
  3. Structure d’un projet industrialisé

Gestion du référentiel d’objets avec le Page Object Model

Qu’est-ce que le Page Object Model ?

Le Page Object Model est un design pattern (ou patron de conception) qui consiste à regrouper en une même classe les identificateurs des composants web avec lesquels on souhaite intéragir, ainsi que les méthodes associées à ces composants. Le Page Object Model joue le même rôle dans les projets Selenium que l’Object Repository dans les projets UFT ou Katalon par exemple.

Dans les articles précédent, nous interagissons avec la page d’accueil du site d’Angular. Si nous nous servons d’un objet page pour la décrire, cela donne :

var SiteAngularPageAccueil = function() {
    this.champ_nom = element(by.model('yourName'));
    this.message_salutations = element(by.xpath("//div[contains(@class, 'well')]//h1"));

    this.entrerPrenom = function(prenom) {
        this.champ_nom.sendKeys(prenom);
    };
};

module.exports = SiteAngularPageAccueil;

La méthode entrerPrenom est vraiment simpliste ; en pratique, on pourrait s’en passer. Nous avons choisi de la créer simplement pour fournir un exemple d’utilisation de méthode d’objet.

Enregistrons ce code dans un fichier site-angular-page-accueil.js, que nous plaçons dans un dossier « pages ».

Utilisation de l’objet page dans le script

Mettons à présent à jour le cas de test en appelant l’objet page et en interagissant avec elle :

var donnees = require('./jeu-de-donnees-demo.js');
var using = require('jasmine-data-provider');
var SiteAngularPageAccueil = require('../pages/site-angular-page-accueil.js');

describe("Suite de test de la feature qui dit bonjour", function() {

    var pageAccueil = new SiteAngularPageAccueil();

    beforeEach(function () {
        browser.get(browser.baseUrl);
    });

    using(donnees.prenoms, function (data, description) {
        it("Chaîne de type " + description, function () {
            testMessageSalutations(data.prenom);
        });
    });

    using(donnees.faux_positif, function (data, description) {
        it("Si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function () {
            testMessageSalutations(data.prenomSaisi, data.prenomVoulu);
        });
    });

    function testMessageSalutations(prenomSaisi, prenomVoulu){
        pageAccueil.entrerPrenom(prenomSaisi);
        var prenomAVerifier = (prenomVoulu ? prenomVoulu : prenomSaisi);
        expect(pageAccueil.message_salutations.getText()).toEqual('Hello ' + prenomAVerifier + '!');
    }

});

Nous avons également créé une fonction testMessageSalutations pour éviter au maximum la duplication entre les deux cas de test.

Le script est maintenant concis et exempt de toute redite ! A ce stade, notre script de test a atteint un niveau de maintenabilité satisfaisant. Il peut jouer une multitude de cas de test différents, et n’est plus soumis aux changements de l’interface du site web.

Exemple de structure de projet Protractor

Pour augmenter la lisibilité de votre projet, nous vous suggérons de ranger dans des répertoires séparés vos fichiers de configuration, vos pages, vos suites de tests et vos jeux de données.

Le nombre de suites de test augmentant, n’hésitez pas à créer des sous-dossiers. Dans vos fichiers de configuration, il sera d’autant plus simple de sélectionner tel ou tel ensemble de suites de tests. Par exemple :

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['../specs/front-office/*.js'],
    baseUrl: 'https://www.monsupersiteweb.nc',
    framework: 'jasmine2'
};

Ici, toutes les suites de test se trouvant dans /spec/front-office seront jouées.

Vous avez maintenant tout ce qu’il vous faut pour démarrer votre projet de tests Protractor sur de bonnes bases. A vous de jouer maintenant ! Et vous souhaitez rester encore un peu avec nous, voici un petit bonus…

Bonus : le reporting Jasmine

Vous aurez beau écrire le plus beau code du monde, il y a peu de chances que celui-ci suffise à émouvoir aux larmes votre chef de projet, client ou patron. Un reporting clair et documenté est indispensable pour communiquer sur l’exécution des tests. C’est pourquoi nous ne voulions pas vous quitter avant d’évoquer la librairie Jasmine2 Screenshot Reporter.

Ajout de la librairie

Dans votre package.json, déclarez la dépendance voulue :

"dependencies": {
  // [...]
  "protractor-jasmine2-screenshot-reporter": "0.3.5"
}

Mise à jour du fichier de configuration

Il est maintenant nécessaire d’appeler la librairie dans le fichier de configuration :

var HtmlScreenshotReporter = require('protractor-jasmine2-screenshot-reporter');

var reporter = new HtmlScreenshotReporter({
    dest: '../reports',
    filename: 'reporting-' + getDate(true) + '.html',
    reportOnlyFailedSpecs: false,
    captureOnlyFailedSpecs: true,
    showQuickLinks: true,
    reportTitle: "Rapport de tests automatisés du " + getDate() + "",
    reportFailedUrl: true,
    pathBuilder: function(currentSpec, suites, browserCapabilities) {
        return currentSpec.fullName + "--" + browserCapabilities.get('browserName');
    }
});

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['../specs/dis-bonjour.js'],
    baseUrl: 'https://angularjs.org',
    framework: 'jasmine2',

    beforeLaunch: function() {
        return new Promise(function(resolve){
            reporter.beforeLaunch(resolve);
        });
    },

    onPrepare: function() {
        jasmine.getEnv().addReporter(reporter);
    },

    afterLaunch: function(exitCode) {
        return new Promise(function(resolve){
            reporter.afterLaunch(resolve.bind(this, exitCode));
        });
    }
};

function getDate(dansNomFichier) {
    var today = new Date();
    var dd = today.getDate();
    var mm = today.getMonth() + 1;
    var yy = today.getFullYear();
    var hh = today.getHours();
    var min = today.getMinutes();

    if(dd<10) dd='0' + dd;
    if(mm<10) mm='0' + mm;
    if(hh<10) hh='0' + hh;
    if(min<10) min='0' + min;

    if(dansNomFichier){
        today = yy + '-' + mm + '-' + dd + '--' + hh + 'h' + min;
    } else {
        today = yy + '/' + mm + '/' + dd + ', ' + hh + ':' + min;
    }
    return today;
}

Explication du fichier de configuration

dest: '../reports'

Avec cette configuration de la variable dest, si votre fichier de configuration se trouve bien dans un sous-dossier dédié (/src/confs par exemple), un sous-dossier « reports » sera créé dans le dossier « src ». A l’intérieur de ce dossier seront créés les reportings au format html, ainsi que les screenshots.

A chaque lancement, son contenu sera supprimé. Si vous souhaitez conserver les résultats des tests d’un lancement à l’autre, mettez à true la variable preserveDirectory lors de l’instanciation de votre HtmlScreenshotReporter :

preserveDirectory: true,

Dans ce cas, un sous-dossier avec un nom aléatoire sera créé à l’intérieur du dossier « reports ».

filename: 'reporting-' + getDate(true) + '.html',

La variable filename, sans surprise, définit le titre du fichier de reporting ; ici, nous avons choisi de lui ajouter la date et l’heure (voir la fonction « getDate » en bas du fichier).

reportOnlyFailedSpecs: false,
captureOnlyFailedSpecs: true,

Les variables reportOnlyFailedSpecs et captureOnlyFailedSpecs permettent de consigner tous les cas de tests dans le reporting, mais de ne prendre un screenshot qu’en cas d’échec.

showQuickLinks: true,

La variable showQuickLinks est à false par défaut. Ici, elle permet de générer au début du fichier des liens vers chacun des cas de test en échec. Pratique quand on se retrouve avec une très grande campagne de test.

reportTitle: "Rapport de tests automatisés du " + getDate() + "",

La variable reportTitle configure le titre qui s’affiche en haut du rapport html.

reportFailedUrl: true,

La variable reportFailedUrl permet d’afficher dans le reporting l’URL sur laquelle l’échec a eu lieu.

pathBuilder: function(currentSpec, suites, browserCapabilities) {
    return currentSpec.fullName + "--" + browserCapabilities.get('browserName');
}

La fonction pathBuilder permet de définir le nom des fichiers de screenshot. Ici, le nom est composé du titre du cas de test et du nom du navigateur.

Notre série sur Protractor est maintenant terminée. En espérant qu’elle vous aura apporté des éléments, nous sommes curieux d’avoir vos retours sur ce framework.

Pour en savoir plus sur les différents outils de tests automatisés ainsi que leurs usages et leurs bonnes pratiques, rendez-vous ici !