[TUTO] Google Analytics pour les tests de portabilité mobiles

Vous avez un site web et vous voulez vous assurer qu’il peut être utilisé correctement depuis n’importe quelle combinaison machine + système d’exploitation + navigateur ? Laissez tomber tout de suite, c’est impossible ! Les configurations sont trop nombreuses pour être toutes testées, il faut donc abandonner l’idée de faire des tests de portabilité.

Mais non, c’était une blague… Aujourd’hui, on va voir ensemble comment se servir des données collectées par Google Analytics pour construire une base pour des tests de portabilité utiles et suffisamment couvrants.

Extraction de la liste des appareils les plus courants

Les étapes pour obtenir la liste des appareils mobiles utilisés par les visiteurs du site sont les suivantes :

  1. Se connecter sur Google Analytics
  2. Déplier l’onglet « Audience »
  3. Déplier l’onglet « Mobile »
  4. Cliquer sur « Appareils »
  5. Un tableau de bord s’affiche ; modifier la plage de dates à volonté. Par exemple, observer les 3 derniers mois pour avoir davantage de matière, tout en conservant des données suffisamment récentes.
  6. Afficher le nombre maximum de lignes pour ce tableau (il est possible d’afficher jusqu’à 5000 lignes)
  7. Cliquer sur le bouton « Exporter » pour obtenir un fichier Excel listant l’ensemble des devices utilisés. Remarque : il est fort possible que le premier élément de la liste regroupe tous les iPhones sans distinction de version…

C’est tout ! Vous avez désormais un peu de matière pour commencer vos tests de portabilité mobile.

Utilisation de la liste

Sur la liste extraite, vous pouvez par exemple calculer combien de lignes de devices vous permettent de couvrir 80% des utilisateurs. Pour le site Hightest, nous avons fait l’exercice. Sur 595 devices, 167 nous permettent de couvrir 80 % des utilisateurs. Plus saisissant encore, 26 nous permettent d’en couvrir 50 % ! Ce type de données permet vraiment de cibler l’effort de test.

Et vous, utilisez-vous ce type de données issues de l’utilisation réelle pour orienter vos tests ?

Mettez-vous en œuvre des tests de portabilité sur vos projets, ou d’autres tests non fonctionnels ?

Si vous voulez profiter d’autres tutos pour accompagner votre quotidien de QA, abonnez-vous à notre page LinkedIn !

Révisions ISTQB : un nouveau site pour s’entraîner !

Précédemment, nous avons publié des articles permettant de guider de nouveaux aspirants testeurs :

Aujourd’hui, dans cette lignée d’articles, nous avons le plaisir de mettre en avant une initiative très utile menée par deux testeurs. Il s’agit du site istqb.online, créé par Med Aziz Zouaoui et Sarah Sliti, et qui contient des quiz blancs pour réviser les certifications ISTQB. Nous apprécions et partageons cet esprit de partage et de challenge, ayant nous-mêmes quelques quiz blancs à notre actif. C’est donc avec joie que nous échangeons aujourd’hui avec Med Aziz et Sarah !

Hightest : Bonjour à vous deux ! Et tout d’abord, merci pour cette belle initiative. Comment vous est venue l’idée ?

Med Aziz Zouaoui : Tout d’abord je voudrais vous remercier pour votre interview et pour l’aide que vous allez apporter à plein de gens en faisons connaître notre site web.

Je suis un développeur qui a décidé de se lancer dans le métier de test et qui avec l’aide de Sarah, y est arrivé. C’est durant ma reconversion que Sarah et moi-même avons eu l’idée de créer un site web qui serai 100 % éducatif, à but non lucratif, dans lequel tout le monde pourrait s’autoévaluer et s’entraîner avant de passer la certification ISTQB.

Hightest : Comment avez-vous découvert le métier de testeur ?

Med Aziz : Après avoir été un marketer et un développeur CMS, j’ai découvert le métier de test à travers Sarah, et après des séances de partage de connaissance et de coaching je me suis senti dans mon élément et j’ai tout de suite décidé d’intégrer le monde de testing.

Sarah Sliti :  J’ai effectué mon projet de fin d’étude au sein d’un département de software testing. Pendant que je travaillais sur mon projet, on m’a demandé de venir en renfort à une équipe de test pour respecter un délai de livraison pour un client important et depuis j’ai développé une passion pour ce domaine et j’ai décidé d’en faire ma carrière.

Hightest : Que vous ont apporté les certifications ISTQB lors de votre itinéraire de QA ?

Med Aziz : Puisque je n’étais pas un testeur de formation, le monde du testing était inconnu pour moi, mais grâce aux certifications ISTQB j’ai pu affiner mes connaissances et avoir les compétences requises pour exceller dans mon travail.

Sarah :  Les certifications ISTQB m’ont apportée beaucoup de connaissances à propos du software testing. Elles ont mis une structure aux notions que j’ai pu acquérir durant ma carrière. Ces certifications m’ont permis de comprendre les grandes lignes du métier de test ainsi que les détails du processus du test et comment l’intégrer dans le cycle de vie logiciel.

Hightest : Qu’est-ce qui vous plaît le plus dans le métier du test ?

Med Aziz : La fierté de savoir que la place d’un testeur est devenue primordiale au sein d’une entreprise

Sarah : Satisfaire le besoin du client et contribuer à la bonne qualité du produit et au succès du projet.

Hightest : Tous les testeurs sont différents et chacun a son propre « style » de test. De votre côté, comment vous décririez-vous en tant que testeurs ?

Med Aziz : Je suis un testeur méticuleux qui éprouve un plaisir en chassant les bugs.

Sarah : Je suis une testeuse curieuse qui a l’œil pour le détail, organisée dans ses idées avec une bonne capacité d’analyse.

Hightest : Quelles sont les nouveautés que vous prévoyez pour votre site ?

Med Aziz & Sarah :  Intégrer un forum pour plus d’interactivité avec les passionnés de test, partager des idées et bénéficier des expériences des autres.

Hightest : Recherchez-vous des contributeurs pour créer de nouveaux quiz ISTQB et étoffer votre site ?

Med Aziz & Sarah : Nous sommes ouverts à toutes contributions. Vous pouvez nous envoyer vos idées à travers notre site, nous avons ajouté une rubrique pour cela : Nous Contacter – istqb.online. Nous pourrons discuter et voir ce que nous pourrons faire pour encore mieux aider la communauté du test.

N’hésitez donc pas à visiter istqb.online ! A ce jour, il propose déjà 6 quiz blancs pour s’entraîner à la certification de niveau Fondation.

Merci à Med Aziz et Sarah pour leurs réponses !

Crédit image de couverture : cottonbro

Petites histoires de reconversion dans le test logiciel

Dans notre précédent article, nous partagions quelques astuces pour réussir son premier entretien d’embauche en tant que testeur, et nous invitions à mettre en avant les expériences passées dans d’autres domaines. Aujourd’hui, nous avons le plaisir d’approfondir ce sujet, en partageant avec vous un beau bouquet de témoignages recueillis auprès d’une multitude de QA issus de reconversions. Et vous verrez que beaucoup de ces profils ont exercé dans des domaines très éloignés de l’informatique, et ont su tirer parti au maximum de ces expériences !

Les soft skills sont au cœur de cet article, et nous espérons qu’à votre tour vous prendrez conscience des trésors que vous apportent vos expériences passées.

Bonne lecture, et bon courage aux aspirants testeurs qui nous lisent et se préparent à leur nouvelle carrière !

Sommaire

  1. De l’équipe de foot à l’équipe de test, avec Romain C
  2. Reconversions jumelles, avec A.B
  3. Des tests chimiques aux tests logiciels, avec Sabri Taleb
  4. Luxe, test et qualité, avec Coralie Cebron de Lisle
  5. De la QSE à la QL, avec F.D
  6. Exigence et qualité : de commerçant à testeur, avec David Venjon
  7. En mode test, avec Marion Lemaire
  8. De maître de conf’ à maître Scrum, avec Munaf Abbas
  9. Les savoureuses recettes de Julien Antonio
  10. Du parc d’attractions à l’attraction pour la qualité, avec Naa’ilah Aly
  11. Téléopérateur : l’envers du décor, avec Alvine Kamga
  12. Record & Playback, les enseignements de la production musicale, avec Dino Dona
  13. Le test est le remède, avec Sonia Boutaraamt
  14. Fuel for test, avec Nabil Boulehrouz
  15. Orchestrer la lumière et les tests, avec Sylvain Viole

De l’équipe de foot à l’équipe de test

Ce témoignage de Romain C file la métaphore du football, son premier domaine d’expertise, et qui vient aujourd’hui nourrir sa pratique du test. L’état d’esprit qui en ressort est extrêmement motivant… voire épique !

J’ai pu travailler 2-3 ans dans le secteur du sport avant de prendre un virage à 90° pour travailler dans le monde du test.

Mes premières expériences dans le sport me servent beaucoup aujourd’hui dans le monde du test.

Dans le sport j’utilise :

  • la persévérance
  • la rigueur
  • l’abnégation
  • l’esprit d’équipe
  • la remise en question
  • le dépassement de ses limites
  • l’esprit de compétition

Ces éléments me servent à surmonter les difficultés de projets ou des équipes et je n’aime pas abandonner ou perdre. 😉

Je fais beaucoup de métaphores et d’allusions au sport.

Je considère vraiment ma squad comme mon équipe de foot avec :

  • ses points forts
  • ses points faibles
  • ses individualités fortes
  • les travailleurs de fond
  • les leaders
  • les suiveurs
  • les relayeurs

Aussi, je considère :

  • L’Engineering Manager comme le coach
  • Le QA Engineer comme le milieu soupape, sentinelle
  • Le produit PM/PO comme le créateur de jeu (milieu offensif, attaquant)
  • Les devs comme des attaquants ou des défenseurs selon leur profil
  • Le sponsor métier comme le gardien de but.

Reconversions jumelles

Dans ce témoignage, A.B illustre ce qui pourrait être un proverbe : “tous les chemins mènent au test” ! Elle montre aussi l’intérêt d’avoir pu développer une expertise métier poussée dans un domaine particulier.

A la base, je suis ingénieur en biologie cellulaire et moléculaire, mais il n’y avait pas du tout de débouchés.

Ma jumelle, qui avait fait une école de commerce et est devenue QA, m’a cooptée. 

On a toutes les deux fait des études qui n’ont rien à voir et on se retrouve à faire le même métier !

J’ai fait pas mal de QA dans le domaine médical. Je me mettais à la place du personnel de santé et surtout, je comprenais à quoi servaient les features implémentées.

Il y a aussi beaucoup de logique. Des symptômes qui indiquent un diagnostic et entraînent un traitement. Le traitement a potentiellement des effets secondaires, est-ce que c’est acceptable ou non… ça s’applique aussi à l’informatique.

Maintenant que je ne travaille plus dans le médical, je garde le même esprit de bien comprendre la feature et la même logique. Et je trouve ça hyper cool d’avoir des résultats si rapides (contrairement à un traitement qui nécessite des jours et des jours avant d’avoir un résultat). En une ligne de code, ça peut être résolu 😊

👩👩

Des tests chimiques aux tests logiciels

Sabri Taleb est chimiste de formation et a même réalisé un doctorat dans cette discipline. Dans sa carrière de testeur, il a pu constater des parallèles entre les deux univers. 

La chimie est un domaine passionnant mais parfois surprenant. Il faut être extrêmement rigoureux, curieux et avoir un esprit critique (comme dans le test), contrôler chaque étape de transformation en faisant des analyses qualité (très souvent plusieurs analyses qui viennent compléter ou confirmer que le produit attendu est bien formé) et si nous voyons que ce n’est pas le cas, analyser et comprendre ce qu’il s’est passé et essayer de reproduire l’anomalie (si c’en est une) et modifier les protocoles.

Et même si le protocole est maîtrisé et routinier, un contrôle n’est pas exclu (encore une fois, comme dans le test 🙂 ), même si nous n’allons pas pousser les analyses qualité (une analyse rapide suffit).

De tout ça, il y a beaucoup de similitudes, ce qui fait que j’ai pu me sentir à l’aise dans cette nouvelle aventure. 

En effet, Sabri Taleb s’est retrouvé propulsé dans le monde du test (comme tant d’entre nous !) par une heureuse opportunité… qu’il a saisie in extremis !

J’ai toujours été attiré par ce que je ne connaissais pas. Lors de ma thèse, on m’avait proposé de refondre un site web, j’ai accepté sans avoir aucune connaissance, du coup j’ai aimé rechercher des solutions et tâtonner jusqu’à avoir un site fonctionnel en y ajoutant une fonction qui permettait aux étudiants de s’inscrire en master directement en ligne. Fini les dossiers papier !

C’est un concours de circonstances ; mes expériences professionnelles dans la chimie étaient courtes (CDD) et il n’y avait pas de postes dans ce domaine dans ma région. Privilégiant le côté familial, j’ai donc regardé ce qu’il y avait de disponible dans les environs, et j’ai constaté qu’il y avait des postes principalement de l’informatique.

J’ai trouvé une annonce qui offrait une possibilité de reconversion de bac +5 scientifique en dev Java, j’ai postulé et j’ai été accepté de suite en POEI (une entreprise s’engageait à embaucher après la formation).

A la fin des 3 mois intenses où on apprend la base du développement et des langages, l’entreprise m’a proposé de suivre une autre formation de 3 mois pour faire de la QA.

J’ai d’abord refusé, puis j’ai accepté de suivre la formation le jour de la date de clôture des dossiers.

Et c’est comme ça que je suis devenu QA avec des compétences en automatisation.

⚗️

Luxe, test et qualité

Avant de se reconvertir dans le domaine de la qualité logicielle, Coralie Cebron de Lisle a exercé dans différents domaines, dont la vente de produits de luxe. Ce qui a contribué à forger son exigence qualité.

En tant que vendeuse de produits de luxe, j’ai appris que les petits détails ont une grande importance et c’est dans son ensemble que le produit prend de la valeur, car aucun détail ne doit être négligé. Et c’est bien là qu’on peut reconnaître la qualité d’un produit.

Tout comme dans le test, il est important d’être curieux, à la fois des technologies utilisées et de la façon de travailler de ses propres collègues afin de comprendre comment le résultat final est obtenu.

Ses expériences précédentes ont également eu un impact positif sur son savoir-être : 

Dans mon expérience passée, que ce soit dans le tourisme, ou dans le commerce, être un bon communicant est essentiel au sein de l’équipe, non seulement par la bonne humeur, mais aussi par une facilité d’adaptation à travailler avec des collègues avec des personnalités très différentes.

⌚✨

De la QSE à la QL

Dans ce témoignage, F.D met en évidence les atouts qu’apporte un background QSE à une carrière dans la qualité logicielle.

En tant qu’ingénieur QSE, j’étais chargée d’accompagner les entreprises dans leurs démarches de certification ISO/TS 14001. Ça consistait à mettre en place la gestion des déchets, la gestion des produits chimiques ou encore la veille réglementaire pour la partie environnement. Pour la qualité, les activités étaient du type audit, reporting fournisseur.

Je dirais que les parallèles les plus évidents avec le test logiciel sont surtout du côté qualité. Pour l’écriture des rapports d’anomalies, je m’inspire beaucoup des méthodes de résolution de problèmes : la méthode QQOQCP, les 5 pourquoi, entre autres méthodes… Cela m’aide beaucoup à structurer ma pensée.

Le côté très procédural des certifications ISO m’a aussi permis d’acquérir des compétences en gestion documentaire. Cela n’est pas forcément mis en avant dans le contexte agile mais chez une entreprise cliente qui ne possède pas d’outils de tests, ça peut être un sacré avantage.

Le métier d’ingénieur QSE est aussi un métier de formateur (aux procédures qualité, aux situations d’urgence…) Il m’a permis aussi de savoir comment m’adresser à différents publics (développeurs, product leaders, etc…) pour aller chercher l’information, pour rendre compte d’une anomalie, pour décaler un planning…

📃✅

Exigence et qualité : de commerçant à testeur

Dans son “ancienne vie”, David Venjon était chef de secteur alimentaire. Ce métier consiste à gérer le secteur alimentaire d’un magasin en incarnant les valeurs et l’esprit de l’enseigne.

Dans ce métier, rechercher en permanence la satisfaction des clients est primordial. Il faut avoir le sens du commerce et de la bienveillance. On doit veiller au respect de la politique commerciale du groupe, de la mise en place de l’ensemble des opérations commerciales. Avoir des connaissances en gestion est un plus. Il faut connaître ses budgets, apporter des correctifs si nécessaire et bien entendu, développer son CA. On doit former ses collaborateurs, les faire monter en compétence, recruter le cas échéant. Des notions de droit du travail sont nécessaires, et la rigueur et l’anticipation font partie du quotidien.

Lors de ma reconversion professionnelle dans la qualité logicielle, j’ai analysé mes softs et hard skills acquises tout au long de ma carrière (17 ans) et j’ai synthétisé celles qui me seraient utiles dans l’informatique.

Je retiens les compétences transverses suivantes :

  • analyse ;
  • organisation ;
  • rigueur ;
  • adaptabilité ;
  • diplomatie ;
  • écoute ;
  • initiative.

Toutes mes compétences étaient axées vers un seul et même objectif : la satisfaction du client.

Depuis 2 ans, je me suis appuyé sur ces forces, qui représentaient mon socle de base, mon cercle de confort, afin de pouvoir me dépasser et acquérir de nouvelles compétences déterminantes dans mon nouveau métier :

  • l’investigation ;
  • l’autonomie (encore plus prononcée que dans mon ancien métier) ;
  • l’apprentissage (dans une démarche intellectuelle et non mécanique) ;
  • la réflexion ;
  • le dépassement de soi.

Les compétences transverses sont une valeur refuge sur lesquelles je m’appuie et je me réfugie en cas de difficulté pour mieux rebondir ensuite.

Cela me rend encore plus exigeant et consciencieux dans mon quotidien, ce qui m’a très vite rendu crédible au sein de mon équipe et m’a donc donné de la confiance en moi.

🤝

En mode test

Marion Lemaire a débuté sa carrière en tant qu’ingénieur textile spécialisée en mode éthique ; elle faisait également du stylisme photo et du conseil. Elle a constaté, elle aussi, des ponts entre ces différentes disciplines et le test logiciel.

Il y a évidemment la minutie de l’ingénierie et l’habitude des process, mais au-delà de ça, il y a plusieurs choses :

  • l’aptitude à comprendre un besoin client même quand le client ne sait pas exprimer ce qu’il veut (classique)
  • la facilité à appréhender différents secteurs et à s’intégrer dans une équipe existante
  • l’évident sens du détail
  • la capacité à se mettre dans les chaussures de l’utilisateur final, car dans tout métier on est confronté à l’outil IT (logiciel de modélisation, plate-forme de vente en ligne, etc)
  • l’aptitude à comprendre des règles de gestion complexes (j’accompagnais les démarches d’audit vers la labellisation écologique par exemple)
  • la facilité à être un couteau suisse et un interlocuteur privilégié de toutes les parties prenantes
  • les capacités de communication et de restitution de l’information (j’étais gestionnaire de la fédération des acteurs de la mode éthique)
  • les capacités d’organisation (gérer un shooting de A à Z, c’est pas de la tarte)
  • le rédactionnel (je faisais des piges pour des magazines de mode)

Suite à cela, Marion a suivi une formation à l’EQL (Ecole de la Qualité Logicielle, à Montrouge juste à côté du Beffroi où se tient tous les ans la JFTL). Elle y est ensuite restée en tant que formatrice puis encore recruteuse de profils.

J’ai vu des artistes tatoueurs devenir d’excellents testeurs techniques, des prothésistes ongulaires devenir de géniales fonctionnelles avec un super côté support, et pléthore de profils incroyables comme des scripts dans le cinéma, des thésards en histoire de l’art, des artistes en mosaïque, des astrophysiciens… C’est incroyable les ponts que l’on peut faire !

📸

De maître de conf’ à maître Scrum

Munaf Abbas, ancien enseignant-chercheur, met en lumière par son témoignage de nombreux mécanismes de l’exigence intellectuelle, nécessaire à de bons tests.

Je suis un ancien enseignant-chercheur ayant travaillé pendant quelques années dans l’enseignement supérieur en France et à l’étranger. J’avais un poste fixe à l’étranger, Maître de conférences, que j’ai quitté pour revenir en France, où les postes sont très rares et parfois inaccessibles. J’ai deux doctorats, l’un en linguistique appliquée à la traduction et l’autre en sciences de l’information et de la communication.

Quand je me suis reconverti à l’informatique, ce qui m’a le plus attiré étaient la méthode et la qualité (la deuxième étant en partie une conséquence de la première).

Il y a beaucoup d’éléments que j’ai pu facilement recontextualiser de mes expériences passées : la méthodologie, la rigueur, la planification et le travail en amont sur la conception et sur les échéances. L’évaluation également est toujours présente à l’esprit ; comment on pourrait évaluer les choses, individuellement et collectivement : un produit, un plan ou un process de réalisation. La vision micro du projet se marie ainsi à la vision macro, et jouer un rôle de connecteur par moment m’a bien plu. J’étais, jusqu’à ma précédente mission, Scrum master et testeur en même temps, et mon expérience précédente m’a bien aidé là-dedans.

👨‍🏫

Les savoureuses recettes de Julien Antonio

Ancien cuisinier, Julien Antonio a puisé dans son expérience en cuisine de nombreux réflexes utiles en tant que QA.

L’attention au détail et le souci de la qualité sont importants dans les deux cas.

Côté testeur, il y a le fait de vérifier que ça fonctionne bien mais aussi que ça répond au besoin du client, plus les petits à-côtés qui font partie de la qualité. Par exemple : “Pourquoi ce nouveau bouton n’a pas du tout le même comportement que tous les autres sur la même page quand on clique dessus ou quand on le survole ?”

Côté cuisine, je trouve que de bonnes questions à se poser quand on goûte un plat sont : “Est-ce que c’est bon ? Est-ce que j’ai envie d’en reprendre une deuxième cuillère juste par gourmandise ? Si ce n’est pas le cas, qu’est-ce qui manque, quel est le problème ?” Ce n’est souvent pas grand-chose (un peu de jus de citron pour ajouter une touche d’acidité par exemple) mais ça fait la différence entre un plat correct et un plat où on va se dire « Han mais c’est super bon ! »

Côté développement on insiste beaucoup sur :

  1. Tester tôt et tout au long du développement
  2. La qualité des spécifications.

Côté cuisine on pourrait insister sur :

  1. Goûter tôt et tout au long de la préparation
  2. La qualité de la rédaction des recettes.

Et ça a beaucoup d’importance :

  1. Quand je cuisine avec des proches je les fais souvent goûter régulièrement et se poser la question que j’évoquais plus haut (« Est-ce que c’est bon ? Qu’est-ce qui manque ? »), plutôt que de juste suivre la recette et de ne se poser la question de la réussite du plat qu’une fois que celui-ci est sur la table.
  2. Une recette qui dit par exemple « Laisser réduire quelques minutes, jusqu’à obtenir une consistance proche de celle du miel » est plus utile car plus précise qu’une qui dirait juste « Laisser réduire réduire 5 minutes ». Car, pourquoi 5 minutes ? Pourquoi est-ce qu’on laisse réduire en fait ? Qu’est-ce qu’on veut comme résultat ? C’est sans doute clair dans la tête de l’auteur, mais ce n’est pas du tout explicite dans celle de la personne qui lit la recette. On ne peut pas modifier la rédaction d’une recette, on peut juste être plus sélectif quand on feuillette un livre de recettes avant de l’acheter. Et on peut appliquer la même logique quand on retravaille des specs avant de les confier aux devs : qu’est-ce qui nous semble évident mais n’est pas dans le texte ? Est-ce qu’il reste des ambiguïtés ? Etc.

👨‍🍳

Du parc d’attractions à l’attraction pour la qualité

Avant de rejoindre le monde de la qualité logicielle, Naa’ilah Aly a travaillé plusieurs années à Disneyland Paris. Une expérience humaine très riche et stimulante, qui lui permet aujourd’hui de faire face à de nombreuses situations.

J’ai effectué plusieurs postes à Disneyland Paris, le plus significatif ayant été celui de guest flow. Un peu partout à travers le parc nous étions en charge de gérer les différents flux des visiteurs, cela pouvait se traduire aussi bien par informer les gens, répondre à leurs attentes, assurer leur sécurité durant les parades, contrôler l’accès à certaines zones du parc pendant les spectacles mais aussi se charger de l’ouverture de certaines attractions et de l’accueil du public au sein de ces attractions.

La sécurité était la priorité pour Disney et les vérifications essentielles. Je n’aurais pas pu souhaiter une meilleure préparation pour mon métier actuel. J’y ai appris à faire des vérifications méticuleuses, aidées par l’usage de checklists, à ne pas laisser de détails sans surveillance, à faire les choses de façon logique et ordonnée. J’y ai aussi appris à placer le client en priorité, à faire preuve d’empathie, à dépasser ses attentes. J’y ai gagné également une bonne dose de diplomatie et une expérience dans la résolution de conflits.

C’est un peu grâce à Disney que je peux aujourd’hui vérifier une feature avec précision, en me mettant à la place de l’utilisateur et en rapportant les bugs mais toujours avec le sourire !

🎠

Téléopérateur : l’envers du décor, avec Alvine Kamga 

Forte d’une expérience de téléopérateur, Alvine Kamga en tire une compréhension profonde des impacts d’une mauvaise expérience client, ainsi qu’une forte capacité d’écoute et d’empathie.

Mon expérience en tant que téléopérateur m’a permis de comprendre l’importance de la satisfaction du besoin de l’utilisateur final :

  • En tant que téléopérateur je me trouvais au premier plan, en contact direct avec l’abonné et je faisais face à l’insatisfaction permanente de ce dernier par rapport au service rendu.
  • En tant que testeur je me retrouve de l’autre côté de la barrière et à chaque fois que je travaille j’ai toujours à l’esprit qu’au bout de la chaîne il y a un utilisateur final qui doit être satisfait du service ou du produit qui fait l’objet de mes tests. Ce qui constitue une source de motivation permanente.

Comme je l’ai appris de mon expérience de téléopérateur : “Un utilisateur satisfait est un utilisateur dont le besoin a été compris et résolu.”

🎧

Record & Playback, les enseignements de la production musicale 

Dino Dona a démarré sa carrière dans le monde de la production musicale. Un domaine qui semble éloigné de celui du domaine logiciel, et pourtant, les parallèles sont nombreux entre le processus de création d’un applicatif et celui de la production d’un album.

Lorsque l’on produisait des albums, le rythme était assez semblable à la production d’une application. Chaque titre passait par plusieurs phases : composition, écriture, enregistrement, ajustement, mixage, mastering. Chaque phase était dépendante de la précédente et demandait une validation par toute l’équipe. 

Nous nous fixions un rythme théorique de 2 semaines pour terminer toutes les phases d’un titre. 

Cependant, et contrairement à un produit numérique, la musique ne répond pas directement à un besoin. Son rôle premier est de transmettre des émotions et parfois, un titre qui ne suit pas un chemin de production « standard » comme évoqué précédemment peut être un carton. 

J’ai découvert le test lors de la création d’un jeu pour smartphone dans l’univers de la musique.

Voici quelques softs skills qui m’ont permis de faire une bonne transition dans le monde du test et plus particulièrement sur le rôle de responsable QA :

  • Fiabilité : La nécessité de tenir ses engagements auprès des parties prenantes, être rassurant, tenir ses délais,
  • Aptitude à fédérer : Mettre en place un collectif durable et tirer le meilleur de chaque individu qui le compose,
  • Rigueur : On mise sur un artiste qui lui-même met sa vie en jeu pour atteindre son objectif. Il ne doit pas y avoir de place pour le doute,
  • Débrouillardise : Savoir apprendre et trouver des solutions rapidement,
  • Capacité à être à l’écoute : Comme tous les métiers créatifs, l’humeur de l’artiste prend une place importante, il faut savoir être à l’écoute.

🎼

Le test est le remède

Sonia Boutaraamt a débuté sa carrière en tant que visiteuse médicale, c’est-à-dire porte-parole de laboratoires pharmaceutiques auprès de professionnels de santé. Une pratique qui a développé sa rigueur et ses compétences en communication.

La visite médicale consiste à rendre visite aux médecins généralistes et ou spécialistes, que ce soit en ville ou en milieu hospitalier. Dans mon cas, c’était les deux. Lors de ces visites, il s’agit de leur faire des rappels sur les spécialités du laboratoire (indications, contre-indications, effets indésirables, posologie), leur présenter les nouveaux médicaments et leur parler des études cliniques récentes. 

Les situations similaires dans le monde de la qualité logicielle sont nombreuses. Elles se concentrent notamment dans la collecte des données et leur exploitation, le reporting, la mise en place de KPI pour atteindre les objectifs. Il y a aussi toute la partie bonnes pratiques et l’habitude de passer des certifications ; en effet, nous n’avions pas le droit d’aller sur le terrain si on était pas certifié tous les 3 mois. J’ai gardé ce côté, j’essaye toujours de me faire certifier au maximum.

En bref, les processus ont une même base : bonnes pratiques, certifications, stratégies (stratégie de test / stratégie commerciale) et politique (politique de test du SI / politique commerciale des laboratoires).

💊

Fuel for test

Quelques jours après la parution de l’article, nous avons eu le plaisir de recevoir un autre témoignage tout aussi inspirant. Il s’agit de celui de Nabil Boulehrouz, précédemment caissier dans une station service pendant 10 ans, avant de reprendre ses études et de se reconvertir dans le test logiciel.

Après quelques années dans le test je me suis rendu compte que le contact avec les clients m’avait facilité le travail avec les développeurs et les autres parties prenantes.

En station-service, quand le client se sert en carburant mais ne peut pas payer, c’est assez compliqué. En effet, là où on peut juste abandonner ses courses dans les autres commerces, en station ce n’est pas possible car le carburant est déjà dans le réservoir. Il faut donc toujours trouver un compromis avec le client. Et chaque client est différent. Avec le temps, j’ai appris à m’adresser de la bonne manière avec les clients pour trouver une solution. Cette « compétence » m’a beaucoup servi dans le test, surtout quand je travaille avec des équipes qui n’ont pas l’habitude de travailler avec un testeur. C’est assez délicat de remonter des bugs au début sans que les développeurs le prennent personnellement.

Orchestrer la lumière et les tests

Et encore un témoignage bonus avec Sylvain Viole, qui avant d’être QA engineer était régisseur lumière dans le spectacle.

Au moment de ma reconversion je me rappelle avoir beaucoup travaillé sur les ponts entre ces deux activités sans lien à priori.

Mon ancien métier consistait à préparer, installer, programmer et exploiter le matériel technique nécessaire à l’éclairage d’un événement, spectacle ou concert.

Il y a beaucoup de choses dans cette activité dont je me sers aujourd’hui dans mon métier de QA :

  • Le repérage et la préparation d’un événement correspond à la lecture et au challenge des spécifications d’un produit. Dans les 2 cas il faut être observateur, précis, le plus exhaustif possible et maîtriser le contexte.
  • La programmation séquentielle de lumière (encodage) est très proche de celles de tests automatisés. Dans les 2 cas il faut coder, et factoriser pour simplifier la maintenance.
  • Une répétition générale partage les mêmes objectifs qu’un test end to end.
  • L’alternance de séquences travaillées et non travaillées (dédiées à la veille et l’autoformation) que l’on peut avoir en ESN ou freelancing peut aussi s’approcher des rythmes d’un régisseur lumière intermittent.

Un point déstabilisant en revanche aura été d’intégrer le côté incrémental des choses dans la tech, là où dans la régie technique le livrable devait être complet dès la première itération. (Parfois, souvent, il n’y en avait qu’une…)

Côté soft skills, l’anticipation, autonomie, l’organisation et la précision sont des qualités auxquelles les 2 activités font appel.

Avant de travailler sur la formulation de ces ponts entre la technique du spectacle et la QA, je trouvais le parallèle un peu tiré par les cheveux. Maintenant que ma reconversion est consommée, je le trouve évident.

💡

Conclusion

Le monde du test s’enrichit de la diversité des profils qui rejoignent cette profession. Les expériences passées construisent les soft-skills et permettent également d’aborder ce nouveau contexte avec un regard plus acéré.

Il n’y a donc pas d’hésitation à avoir si ce métier vous attire ; lancez-vous, vous allez faire des merveilles !

Et pour découvrir d’autres aspects du métier du test, rendez-vous sur notre page LinkedIn 🙂

Photo de couverture : James Wheeler

4 clés pour réussir son premier entretien d’embauche de testeur

Dans un précédent article, nous vous donnions des pistes pour vous aider à devenir testeur logiciel. Vous avez désormais obtenu un premier entretien d’embauche et votre nouvelle carrière de QA vous tend les bras : félicitations ! Problème : le syndrome de l’imposteur vous guette, et vous redoutez que l’entreprise ne vous retienne pas. Pas de panique, dans cet article on partage avec vous quelques astuces pour que ce moment se passe bien. Mettez toutes les chances de votre côté !

#1 – Partagez votre enthousiasme

Beaucoup de personnes découvrent le test par hasard, par exemple suite à un entretien avec des conseillers Pôle Emploi. Il n’y a aucun mal à ça, le métier est encore relativement méconnu et tous les moyens sont bons pour le faire connaître ! Merci d’ailleurs, au passage, aux personnes qui, sans l’exercer, font connaître ce beau métier.

Toutefois, si vous êtes dans ce cas, il est important que votre discours dépasse cette dimension “hasard de la vie”. Sans cela, votre interlocuteur se demandera, à juste titre, si vous avez choisi le test logiciel par envie ou par dépit.

  • Qu’est-ce qui fait qu’aujourd’hui, vous avez envie de faire du test ?
  • Cette activité vous plaît-elle authentiquement ?
  • Si oui, quelles sont les activités ou les situations précises qui vous font le plus vibrer ?

Vous aurez beau être authentique dans votre motivation, ce qui va compter avant tout c’est de l’exprimer d’une façon que votre recruteur puisse vous croire.

Plus vous serez spécifique et plus vous paraîtrez authentique. 

Par exemple, “Je veux devenir QA car ça me plaît d’améliorer la qualité des logiciels” sonne un peu fade. “J’adore constater qu’un des bugs que j’ai découverts a été parfaitement corrigé”, ou encore “Ca me fait pétiller le cerveau de rechercher la petite configuration qui provoquera une défaillance” c’est tout de suite plus savoureux !

Si vous montrez votre motivation et que celle-ci est sincère, votre enthousiasme aura toutes les chances de gagner votre interlocuteur.

#2 – Assumez toutes les cordes à votre arc

Vous avez un passé de littéraire ? De comptable ? De biologiste ? De prof ? De standardiste ? De cuistot ? De parent au foyer ?

Félicitations, vous faites donc partie de l’écrasante majorité de personnes qui ont débuté leur carrière autrement que dans le test logiciel. Vous avez tout à gagner à assumer pleinement vos expériences passées. Elles ont façonné chez vous un certain regard sur le monde, des exigences qui vous sont propres, une manière d’apprendre, de vous organiser, de communiquer.

C’est une richesse et il est important que vous en preniez conscience !

Vous gagnerez à expliquer à votre interlocuteur les ponts qui existent entre les différentes expériences et disciplines qui jalonnent votre carrière, et le métier du test. Dans le prochain article, nous donnerons la parole à une myriade de QA aux parcours extrêmement variés, qui vous parleront des apports de leurs premières disciplines. Préparez-vous !

#3 – Démontrez vos qualités de testeur

Emna Ayadi, spécialiste en test logiciel, a mis en lumière 4 catégories de compétences indispensables aux testeurs du XXIème siècle (les 4C) :

  • Esprit critique
  • Collaboration
  • Communication
  • Créativité

Même si vous débutez dans le monde de la qualité logicielle, vous avez déjà certainement des “success stories” à partager en rapport avec ces soft kills, que ce soit dans votre passé étudiant, professionnel, associatif, ou de loisirs.

En lien avec les qualités citées ci-dessus, illustrez celles dans lesquelles vous vous reconnaissez le plus par des actions que vous avez pu mener précédemment.

#4 – Faites part de votre curiosité

La curiosité est une qualité extrêmement valorisée dans le monde de la qualité logicielle. C’est normal ; vous allez devoir vous intéresser à des domaines fonctionnels que vous ne maîtrisez pas encore, faire l’effort d’aller dans le détail, apprendre à utiliser des outils qui changeront d’année en année…

Et le hack, c’est que la curiosité s’appuie justement sur ce qui, en tant que débutant, peut aujourd’hui vous faire peur : le fait de ne pas tout savoir !

Au cours de l’entretien, faire part d’éléments précis qui éveillent votre curiosité permettra à votre interlocuteur d’en savoir davantage sur votre motivation et ce sur quoi votre profil tend. Encore une fois, plus vous serez spécifique, plus vous irez loin dans les questions, et plus vous aurez de l’impact. Un exercice possible est de préparer une question, et de trouver une question supplémentaire pour l’approfondir. Par exemple, après avoir posé la question “Quels outils utilisez-vous ?”, vous pouvez aller plus loin : “Selon quels critères les avez-vous choisis ?”

Ou encore, après la question “Combien de personnes constituent l’équipe de test ?”, demander “Quel ratio visez-vous entre les devs et les QA ?”.

Une curiosité sincère démontre également, sans qu’il y ait besoin de le formaliser ou de forcer le trait, une certaine humilité.

Développer une attitude de curiosité est donc “tout benef”, lors de l’entretien mais aussi tout au long de votre parcours… que nous espérons riche en succès !

D’autres ressources pour aller plus loin

Cet article s’adresse aux testeurs débutants, qui veulent décrocher leur tout premier poste de testeur. Il existe cependant d’autres articles que nous vous conseillons de lire également, même s’ils ne se focalisent pas sur le cas particulier de la première embauche. Nous souhaitons partager avec vous deux d’entre eux :

Il ne nous reste plus qu’à vous souhaiter un entretien agréable et enrichissant. Tirez-en le maximum, et n’oubliez pas qu’une réponse négative ne signifie pas que l’histoire est terminée ! Si le courant est passé, gardez contact ; cela pourra mener, quelques années plus tard, à de belles collaborations. You never know!

Pour découvrir d’autres contenus sur le métier du test, abonnez-vous à notre page LinkedIn 🙂

Journée du test logiciel 2022

5 bonnes raisons d’aller à la JFTL l’année prochaine !

Ce mois-ci, pour la première fois depuis des années, un membre de notre société a eu la possibilité de se rendre à la JFTL, la Journée Française du Test Logiciel. Une belle découverte pleine de surprises, de fun et de qualité !

Quelques éléments à partager si vous voulez vous convaincre (ou convaincre vos collègues !) d’y aller l’année prochaine !

 

1. Des conférences de qualité

C’est peut-être, et sans surprise, l’aspect le plus connu et le plus recherché de la JFTL : la ribambelle de conférences centrée sur le métier du test.

La programmation, qui fait l’objet d’une sélection exigeante, est à la hauteur de ce qu’on peut espérer de l’événement QA français le plus réputé. Nous ne rentrerons pas dans l’exercice vain de résumer les contenus de ces belles interventions, d’autant que leurs supports seront prochainement disponibles sur le site du CFTL (dans l’onglet « Archives » de l’espace JFTL). Toutefois, saluons la diversité de ces conférences, illustrée par la keynote inaugurale de Bernard Rulmont, psychologue clinicien, qui a parlé du stress et de comment l’apprivoiser dans un contexte agile.

Journée Française du Test Logiciel - 5 bonnes raisons d'y aller - keynote inaugurale de Bernard Rulmont 6 - Stress en agilité

 

Notons aussi l’émergence d’un sujet brûlant : la responsabilité environnementale du numérique, et les manières d’en tenir compte dans le métier du test.
Via un espace communautaire en ligne (Congreet) il était possible d’attribuer des notes aux conférences, et c’est celle de Nicolas Laigle et Antonio Ferreira « L’importance croissante des tests automatisés pour l’accessibilité numérique » qui a remporté le gros lot, félicitations à eux !

 

2. La Journée des Tutoriels

La JFTL est, selon la tradition, précédée d’une journée plus studieuse, la Journée des Tutoriels. Deux sessions de 3 heures, une le matin et l’autre l’après-midi, pour prendre le temps de se plonger dans un sujet.

Cette année, nous avons découvert avec plaisir deux solutions de la société Smartesting, Gravity et Yest, respectivement des outils de shift-right et shift-left testing. Le premier permet de générer des scénarios de tests automatisés à partir des usages réels constatés en environnement de production. Le deuxième est un outil de MBT (Model-Based Testing), qui s’intègre notamment avec Jira, et qui est pensé pour favoriser la clarté des spécifications et, ce faisant, la co-construction des tests avec les responsables produits.

La Journée des Tutoriels est un moment où l’on peut notablement monter en compétences sur des sujets proches de nos problématiques quotidiennes, tout en se préparant en douceur à l’effervescence du lendemain.

3. Un nombre invraisemblable de QA

1300 pros de la qualité dans un même lieu ! Ça fait rêver et c’est véritablement enthousiasmant. Il n’y a bien sûr pas le temps de parler à tout le monde, mais il y a de fortes chances que vous croisiez des personnes avec qui vous avez déjà échangé sur les réseaux (par exemple sur LinkedIn, dans le groupe Le métier du test).

C’est assez magique de découvrir en 3D les personnes que nous avons eu l’occasion de lire et d’entendre seulement à distance jusqu’alors ! La conversation se poursuit naturellement, avec la même spontanéité que si on s’était déjà rencontrés plusieurs fois auparavant.

Nous qui utilisons Squash TM au quotidien depuis des années (vous savez, ce super outil de gestion des tests !), c’était par exemple un plaisir de mettre des visages sur des noms de personnes que nous croisions régulièrement sur le forum de cet outil.

 

4. Des surprises à gogo dans les stands

Véritable « village du test », l’espace consacré aux stands invite à la discussion à bâtons rompus.
Quel plaisir à l’occasion de cette édition de voir autant de jeux au sein des stands ! Le jeu « 1001 tests » du stand Sogeti, le jeu « Agility maturity cards » d’Agilitest, le burger quiz du stand Ausy… La gamification et les serious games sont désormais des outils incontournables de notre métier, et ces indices le démontrent bien.

Journée Française du Test Logiciel - 5 bonnes raisons d'y aller - jeu « 1001 tests » du stand Sogeti

Cette JFTL était aussi l’occasion de découvrir le dernier livre du CFTL, consacré à l’automatisation des activités de test.
Malgré l’affluence, le lieu est si bien organisé qu’il est toujours possible de s’entendre, et de « vraies » conversations peuvent avoir lieu. Ce qui nous amène à la 5ème bonne raison d’aller à la JFTL !

5. Un lieu d’exception

Le Beffroi de Montrouge est un lieu d’accueil parfait ; malgré le nombre important de participants, il y a toujours suffisamment d’espace pour se sentir à l’aise, pas de sentiment de surnombre. Un vestiaire à l’entrée permet de déposer sa valise, ce qui est bien pratique lorsque l’on vient de l’autre bout de la France… ou du monde !

Légèrement à l’extérieur de Paris, ce lieu est parfaitement accessible grâce à un métro tout proche, et sa position un peu excentrée permet de trouver à proximité des hébergements à coût raisonnable, et d’avoir le plaisir de venir à pied.

Ces détails un peu anecdotiques ne viennent que renforcer le plaisir d’assister à un événement parfaitement rôdé, aussi utile qu’agréable.

Bref, pour toutes ces raisons, nous recommandons vivement d’assister à la JFTL. Et pour prolonger le plaisir, nous vous invitons à découvrir ses coulisses sur le blog de la Taverne du Testeur !

A bientôt !

 

Journée Française du Test Logiciel - 5 bonnes raisons d'y aller - Iman Benlekehal, Benjamin Butel, Dimitri Doye, Zoé Thivet

Un échantillon de la « planète test ». De gauche à droite, d’Ouest en Est : Iman Benlekehal, Directrice Expert en Assurance Qualité au Canada, Benjamin Butel, Coach Testing à Rennes, Dimitri Doye, Expert technique Tosca à Lille, et Zoé Thivet, Ingénieur test applicatif à Nouméa (Photo prise par Yannick Cum).

La Nouvelle-Calédonie est peut-être loin de chez vous, mais nous sommes toute l’année accessible sur notre page LinkedIn 🙂

Tests non fonctionnels : quelques ressources pour vous lancer

« Les compères dans leur Fiat font sécher leurs mains en utilisant les portes. »

Qu’est-ce que c’est ? Une formule magique ? Une chaîne aléatoire générée par une IA ? Un extrait de chanson absurde ?

Rien de tout ça : c’est notre moyen mnémotechnique pour se souvenir des 8 aspects de la qualité logicielle définis par ISO 25010 !

Les com(patibilité)per(formance)es dans leur Fia(bilité)t fon(ctionnalité)t sec(urité)her leurs main(tenabilité)s en utilisa(bilité)nt les port(abilité)es.

Compatibilité, Performance, Fiabilité, Fonctionnalité, Sécurité, Maintenabilité, Utilisabilité, Portabilité.

Ces 8 aspects sont tous importants, mais l’un d’entre eux est comme un arbre qui cache la forêt : l’aspect fonctionnel. Eh oui : quand un produit numérique est créé, on veut avant tout savoir “s’il fonctionne” !

Toutefois, il est important d’avoir en tête les 7 autres aspects, qui se focalisent sur comment le produit fonctionne : rapidement, joliment, sécuritairement, compréhensiblement, simplement…

Cet article donne quelques clés pour comprendre ces types de test avant de vous lancer. Les ressources partagées sont issues de nos propres travaux ainsi que d’autres ressources francophones, pertinentes et faisant autorité dans le domaine de la qualité logicielle. Nous étofferons avec plaisir cette liste avec vos suggestions, alors n’hésitez pas à nous en partager.

Bonne lecture !

Compatibilité

Portrait robot du problème de compatibilité

L’applicatif fonctionne bien sur la machine du développeur (héhé !) mais rencontre des problèmes dès qu’il se trouve sur le même environnement qu’un autre logiciel du système d’information ? Il a du mal à communiquer avec d’autres systèmes dont il dépend ? Il présente certainement un problème de compatibilité !

A quoi ressemblent des tests de compatibilité ?

Bien souvent, les problèmes de compatibilité sont découverts “par hasard”, ou plutôt “par nécessité”, quand l’applicatif est installé dans son environnement cible. Mais en fonction du produit (notamment ceux nécessitant une installation locale chez chaque client), il peut être nécessaire de procéder à des tests systématiques. Cela consiste à imaginer différentes configurations que pourrait rencontrer l’applicatif, et vérifier si chacune d’elle permet un comportement nominal de celui-ci. Des tests de portabilité sont alors souvent également nécessaires (voir la section dédiée).

Pour aller plus loin :

Fiabilité

Problèmes de fiabilité : kézako ?

Les utilisateurs ne font pas confiance à l’applicatif ? Il plante à chaque fois qu’on saisit une valeur qu’il n’attend pas ? Il est régulièrement indisponible ? Il est incapable de se rétablir après avoir “crashé” suite à une forte affluence ? Il y a certainement un problème de fiabilité !

Comment tester la fiabilité ?

La fiabilité donne lieu à des tests de diverses natures.

Certains tests visent à mettre l’applicatif et son environnement en difficulté (coupure réseau, indisponibilité d’une ressource tierce…) afin de vérifier l’adéquation de son comportement et sa capacité de récupération.

Des dispositifs de monitoring peuvent également être mis en œuvre afin de vérifier la disponibilité de l’applicatif au fil du temps.

Pour aller plus loin :

Performance

La performance, qu’est-ce que c’est ?

L’applicatif est trop lent ? Il ne tient pas plus de 15 utilisateurs simultanés ? Il y a certainement un problème de performance !

La performance regroupe un certain nombre de termes utilisés au quotidien au sein des DSI : charge, robustesse, stress, rendement… 

Pourtant, chaque terme a une signification différente et peut mener à des types de test différents.

Vous vous perdez dans la sémantique ? Pas de panique, faites un petit tour par cet article de désambiguïsation qui vous permettra d’y voir plus clair grâce aux définitions de l’ISTQB !

Quels types de tests pouvez-vous réaliser ?

Les tests les plus courants pour cet aspect de la qualité sont les “tirs de charge”, qui consistent à simuler l’utilisation de l’applicatif par un certain nombre de personnes. Le type d’utilisation peut être spécifié, et des rapports sont générés de façon à comprendre quelles ressources sont les plus susceptibles de créer des lenteurs voire des indisponibilités en production.

Quelques outils connus : JMeter, Neoload, Gatling.

Pour aller plus loin :

Sécurité

Bugs de sécurité : des bugs pas comme les autres ?

Les bugs de sécurité, aussi appelés “failles”, ont une place un peu à part dans l’inconscient collectif, car ils mettent en jeu non seulement l’applicatif, son environnement et ses utilisateurs, mais aussi des acteurs bien spécifiques, communément désignés sous le noms de hackers, pirates ou utilisateurs malveillants !

Ces anomalies peuvent être de natures très différentes. On distingue communément les défauts présents dans l’applicatif (on parle tout simplement de “sécurité applicative”), et ceux qui concernent son environnement ou son réseau.

Techniques de tests de sécurité

Parmi les techniques spécifiques les plus courantes pour effectuer des tests de sécurité, on compte le pentest ou penetration testing (des tests souvent outillés qui consistent à s’introduire dans un système) et les scans de vulnérabilité, qui comparent un existant avec une bibliothèque de failles connues et plus ou moins communes. Tandis que les pentests nécessitent souvent des connaissances assez poussées, il est possible de mettre en œuvre rapidement et à peu de frais des scans de vulnérabilité. Toutefois, l’un ne remplace pas l’autre.

Des tests de sécurité peuvent être facilement mis en œuvre lors de la conception de tests d’API ; il suffit alors d’imaginer des scénarios “interdits” (exemple : essayer de changer le prix d’un article en utilisant l’API en étant connecté en tant que simple client !)

Pour aller plus loin :

Maintenabilité

Repérer les problèmes de maintenabilité

L’applicatif connaît de nombreuses régressions ? L’intégration de nouveaux développeurs se fait lentement et dans la douleur ? Les devs historiques rechignent à retourner sur le projet ? Ca sent la problématique de maintenabilité !

Comment gérer les défauts de maintenabilité ?

La qualité de code est étroitement liée à cet aspect de la qualité logicielle ; toutefois, ce n’est pas parce que la qualité de code est essentiellement une responsabilité des développeurs, que les testeurs n’ont pas de rôle à jouer pour faciliter la consolidation de la maintenabilité.

Les outils de qualimétrie peuvent être des alliés dans la détections de problèmes de maintenabilité. SonarQube par exemple détecte 3 types de problèmes de code : les bugs, les vulnérabilités et les “code smells”. Cette troisième catégorie permet de détecter des aspects qui trahissent un manque de maintenabilité au sein du code.

Un travail collaboratif de définition de bonnes pratiques de développement est également un investissement très intéressant pour la qualité à long terme du produit. Cela peut prendre la forme de revues de code classiques (simple et efficace !), mais cela peut aussi être outillé avec des solutions telles que Promyze.

Pour aller plus loin :

Utilisabilité

Le spectre des problèmes d’utilisabilité

L’utilisabilité est un aspect passionnant de la qualité logicielle, qui s’intéresse avant tout à l’expérience subjective de l’utilisateur. Et “subjective” n’est pas un gros mot ! Cela signifie simplement qu’il est nécessaire ici de se positionner dans une situation spécifique. Celle, par exemple, d’une personne qui n’a pas forcément les mêmes informations que nous, le même vécu ou encore les mêmes caractéristiques physiques (dans le cas des tests d’accessibilité).

Comment obtenir des retours d’utilisabilités crédibles ?

Une des grandes difficultés qu’un testeur peut rencontrer au moment de rapporter un bug d’utilisabilité est le risque de se voir rétorquer “C’est subjectif” (sous-entendu “Cela n’est pas un bug, cela ne sera pas corrigé”). Il est donc important de s’appuyer sur des arguments solides et si possible soutenus par des ressources tierces (états de l’art, témoignages utilisateurs…)

Comme pour la portabilité (voir section suivante), le crowdtesting (ou test participatif) est en mesure d’apporter rapidement des informations qualifiées sur l’utilisabilité des applicatifs.

Pour aller plus loin :

Portabilité

Les signes de problèmes de portabilité

L’applicatif fonctionne bien sur Windows 10 mais pas sur MacOS ? Sur Chrome mais pas sur Firefox ? Le design est magnifique sur écran d’ordinateur mais horrible sur smartphone ? Quand on parle de portabilité, il s’agit exactement de ce type de problèmes !

Démarrer une démarche de tests de portabilité

L’ennemi n°1 de la portabilité, c’est… de ne pas faire de tests de portabilité. Certes !

L’ennemi n°2, c’est de se disperser.

En effet, la combinatoire des environnements (système d’exploitation, version d’OS, navigateur, taille d’écran…) empêche la plupart du temps de tout tester. La portabilité donne une belle illustration du principe général du test “Les tests exhaustifs sont impossibles” !

Pour asseoir une stratégie de tests de portabilité efficace, il est nécessaire de s’appuyer sur des chiffres. Quelles sont les configurations les plus plausibles dans notre cas ? Quels sont les 20 % de configurations (à la louche !) qui nous permettront d’être confiants sur 80 % des cas ?

Des outils de tracking des utilisateurs sont alors très utiles (par exemple, Google Analytics pour un site web permet de connaître quelques éléments sur les habitudes de navigation des utilisateurs).

Une fois cet état des lieux réalisé, c’est le moment de se lancer. Plusieurs possibilités peuvent alors être envisagées :

  • Avoir recours à des fermes de devices ou de navigateurs (des services en ligne qui mettent à disposition des environnements dédiés à ce type de tests)
  • Investir dans de nombreux devices de test (c’est beaucoup plus onéreux ; la plupart du temps nous déconseillons cette pratique)
  • Faire appel à des crowdtesteurs. L’avantage ici étant que les retours ne concerneront pas seulement la portabilité, mais aussi d’autres aspects de la qualité logicielle.

Pour aller plus loin :

  • Comprendre les enjeux liés à la compatibilité : Article sur la Taverne du testeur
  • Nous avons testé pour vous deux services cloud permettant de mettre en œuvre des tests de portabilité : pCloudy et BrowserStack.
  • L’extension Lighthouse de Chrome permet de passer en revue des aspects tels que la performance, la portabilité et l’accessibilité.
  • La portabilité et la compatibilité sont souvent étroitement liées, car elles s’intéressent toutes deux à la variété des configurations logicielles et matérielles dans lesquelles l’applicatif va être utilisé. Toutefois, ce sont deux notions à distinguer. Voici donc un paragraphe (en anglais) sur la différence entre compatibilité et portabilité.

Par où commencer ?

Eh oui, cela fait beaucoup d’infos ! 

Connaître les 8 aspects de la qualité logicielle est un bon début. Pour la suite, nous vous conseillons ces étapes pour faire de vous un cador des tests non-fonctionnels :

  • Faire connaître ces 8 aspects à votre équipe (en partageant cet article par exemple !)
  • Discuter collégialement des différentes facettes de la qualité vis-à-vis des applicatifs que vous testez au quotidien
  • Identifier les tests non fonctionnels prioritaires pour chaque applicatif
  • Vous former et mettre en œuvre ces tests au sein de votre stratégie globale !

Tout cela étant dit, nous vous souhaitons bon courage dans votre périple ! Si vous avez des questions ou besoin d’aide, nous vous conseillons de poster un message sur le groupe LinkedIn francophone très réactif Le métier du test. Au plaisir de vous y retrouver !

Bon courage dans votre exploration et souvenez-vous que le test regorge toujours d’occasions d’apprendre !

Découvrir ODASE, partie II : intégrer les ontologies dans le SI

ODASE est un logiciel permettant de formaliser la réalité du métier, de façon à constituer un référentiel exploitable par une multitude d’applicatifs.

La semaine dernière, nous accueillions Rémi Le Brouster pour nous parler de cette solution, de ses objectifs et du changement de paradigme que cela entraîne pour la définition des règles métier.

Nous nous retrouvons cette semaine pour échanger sur l’intégration de cette solution dans le quotidien des acteurs techniques.

H : Comment les équipes techniques utilisent la représentation du métier définie par ODASE ?

RLB : Avec l’équipe informatique côté client, on définit en parallèle comment ils souhaitent interroger l’outil. On peut par exemple déterminer un ensemble de services pour interroger ODASE, auquel cas on établit alors un contrat d’API. Nous nous occupons alors de réaliser la partie technique qui va proposer les services, transmettre les informations à l’outil, demander le résultat, et le retourner. Ainsi, ni le client, ni le serveur n’ont à connaître le fonctionnement métier.

Afin de décorréler encore plus le technique du métier, et exploiter encore plus l’explicabilité fournie par l’outil ODASE, l’API n’a pas nécessairement besoin de se baser sur la modélisation métier. Nous réalisons alors une ontologie d’intégration, qui fait la conversion entre les concepts métiers et les concepts techniques. Cette correspondance est donc parfaitement compréhensible et documentée, et il n’y a donc pas besoin d’aller investiguer du code pour comprendre le mapping. La passerelle entre le métier et le technique est donc une simple affaire de traduction, très localisée et lisible, et cette indépendance entre le métier et le technique permet de pouvoir avancer sur les deux aspects de façon indépendante.

H : Comment les développeurs accueillent la solution ODASE ? Le fait qu’il y ait besoin de s’interfacer avec un outil tiers complique-t-il leur travail ?

RLB : Les développeurs n’étant pas une entité unique, je suppose que leur accueil de la solution doit varier. Par exemple, je sais qu’en tant que développeur, j’adore me creuser la tête sur des problématiques métiers, définir le périmètre précis et les cas limites, et trouver des algorithmes efficaces, ce que rend obsolète ODASE sur la partie métier, le périmètre et les cas limites étant modélisés en amont, et les résultats étant calculés par l’outil.

A ma connaissance, la plupart des développeurs préfèrent s’occuper de la partie technique, ce qu’ils ont encore plus le loisir de faire grâce à notre outil. Cela leur évite également les frustrations de devoir gérer des spécifications métiers qui ne sont pas toujours limpides, ou de se rendre compte trop tard de la divergence entre la réalité métier et ce qu’ils en avaient compris, ce qui invalide parfois toute leur implémentation.

Concernant le fait de s’interfacer avec ODASE, c’est aussi simple que de s’interfacer avec n’importe quelle autre API ou JAR (selon le choix technique qui a été fait), ce à quoi les développeurs sont généralement habitués. ODASE a donc plus tendance à leur simplifier le travail et à leur éviter des frustrations que l’inverse.

H : Certains développeurs aiment particulièrement apprendre des choses sur le métier, pour comprendre pourquoi ils font ce qu’ils font et donner du sens à leurs efforts. En séparant les règles métier de l’implémentation technique, y a-t-il un risque de frustrer les développeurs qui ont ce type d’appétence ?

RLB : Bien que cela soit possible, s’ils aiment autant s’occuper de problématiques métiers que moi, je pense qu’il reste important pour les développeurs de se familiariser avec le métier, même dans une approche ODASE, ne serait-ce que pour comprendre comment seront utilisées leurs applications. Ainsi, même si on les libère d’une partie de la gestion de ce métier, on ne saurait que trop les encourager à s’y intéresser tout de même (et encourager leurs employeurs à leur y octroyer du temps !). Idéalement, ils pourront alors s’appuyer sur la modélisation ontologique pour approfondir leurs connaissances métiers, afin de proposer et délivrer des applications et fonctionnalités plus pertinentes.

H : La solution ODASE, quand elle est mise en place, semble devenir le point névralgique d’un système d’information… Le SI devient-il « captif » de cette solution ? Les équipes de vos clients deviennent-elles autonomes, ou bien faut-il faire appel aux ontologues d’ODASE pour chaque ajout de règle métier ?

RLB : Dans une approche idéale où le client embrasse intégralement l’approche ODASE, notre solution devient en effet le point névralgique du système d’information, et je pense qu’il est essentiel de comprendre pourquoi, afin de saisir aussi en quoi cela peut aussi être émancipateur, notamment si le client veut changer totalement d’approche plus tard, et refondre son système d’information tout en revenant à une approche classique.

Tout d’abord, je tiens à rappeler que le système d’information ne se limite pas simplement à de l’applicatif, mais inclut aussi l’ensemble des échanges entre les acteurs et leur accès aux informations et documentations.

Dans une approche classique, la définition du métier est morcelée. Elle se trouve dans les connaissances et souvenirs des différents acteurs, dans des brouillons papiers, dans des mails, dans des outils de ticketing, dans des documents à destination du métier, des développeurs, du support ou des utilisateurs, dans le code aussi bien en langage informatique qu’en commentaires, etc. Il devient alors difficile d’interroger ces connaissances, et de savoir quelle source est fiable pour quel aspect. Car une spécification peut être obsolète ou décrire un changement qui n’a pas encore été implémenté, et même un expert avec une excellente connaissance métier peut se tromper, surtout face à des spécifications changeantes; l’interprétation du code par un humain peut passer à côté de certains cas particuliers, et le code lui-même est rarement une source unique, avec de multiples applications intégrant différentes règles, et comme nous venons de le voir, ces règles varient selon la source qui a été choisie en amont.

Dans l’approche ODASE, l’essentiel de notre travail est d’agréger toutes les connaissances de l’ensemble du domaine à modéliser, et de clarifier ce qu’est la vérité métier. A partir de là, nous construisons l’ontologie métier qui servira de référence. L’entreprise obtient ainsi un point unique qui définit toutes les règles de façon parfaitement indépendantes, et qui est interrogeable directement, que ce soit pour valider cette définition métier (plus besoin de tester extensivement le métier dans chaque application, et de devoir comparer les résultats !) ou pour vérifier ce qu’on obtient, d’un point de vue métier, dans telle ou telle situation. Cela signifie aussi que quelqu’un ayant une question métier peut la confronter à une source fiable. Cette source est réellement un point unique en ce que l’ensemble des applications peuvent se baser dessus, car elle ne décrit pas des règles métiers pour une application ou un ensemble d’applications, mais bien les règles métiers de l’ensemble du domaine. Ainsi, même pour une nouvelle application ayant besoin de nouveaux services afin d’interroger certains éléments intermédiaires, il suffit de rajouter techniquement de nouveaux services dans l’interface programmatique d’ODASE, autrement dit de nouveaux points d’entrée ou de nouvelles façons de l’interroger, mais sans toucher aucunement à la partie métier. De même, si c’est la partie métier qui change, sans que cela n’impacte les éléments nécessaires et donc la partie technique, il suffit de modifier les règles métiers, puis de déployer la nouvelle version sur les différentes plateformes intégrant ODASE.

Cette solution a donc ceci d’émancipateur que :

  • si le client veut remplacer une application faite il y a 15 ans en développant une version plus au goût du jour, il n’a pas besoin de recoder la partie métier, ni de développer de nouveaux algorithmes car le métier est approché d’une nouvelle façon (par exemple, avec l’ordre des questions qui change) ; il peut se concentrer purement sur la partie technique
  • si le client veut refondre totalement son système d’information et se séparer d’ODASE, pour déléguer l’ensemble de sa gestion à un gros ERP par exemple, le fait d’avoir défini clairement le métier en un point unique et fiable fera que son travail sera grandement facilité, et qu’il y gagnera en coûts, en qualité et en délais.

Pour ce qui est de la modification lorsque l’approche ODASE est en place, passer par nous est tout à fait possible et encouragé, notamment pour garantir la qualité de la représentation ontologique. Toutefois, il est également possible pour le client d’avoir son ou sa propre ontologue qui réaliserait tout ou partie des modifications (on pourrait par exemple former quelqu’un chez le client à cette fin).

Pour ce qui est des modifications classiques (par exemple les prix qui évoluent d’une année sur l’autre), on peut avoir ces éléments stockés dans des sources externes (fichiers Excel, base de données, autre), que le client pourra aisément mettre à jour, afin qu’il n’y ait qu’à relancer les instances du serveur ODASE pour que tout soit pris en compte (dans le cas d’une utilisation en mode serveur).

Enfin, nous sommes actuellement en train de développer un outil pour rendre les ontologies plus accessibles, aussi bien pour les visualiser que pour les modifier.

Il me semble que l’important, comme dans tout domaine, est de faire réaliser les modifications par des personnes dont l’expertise est adaptée à la complexité de la modification à apporter. Et nous visons à permettre que ces personnes puissent être côté client, afin justement d’offrir de l’autonomie et de la maîtrise, aussi bien en faisant progresser l’expertise côté client qu’en simplifiant la réalisation de modifications.

H : Est-il possible d’intégrer ODASE au sein d’un SI ayant une forte proportion de legacy, ou est-ce plutôt une solution à privilégier sur des SI naissants ou du moins récents ?

RLB : Il est évidemment toujours plus confortable de travailler sur des bases neuves ou saines, plutôt que de devoir investiguer l’ancien. Toutefois, ODASE a principalement été utilisé dans des contextes de refonte du legacy de grosses structures, pour lesquelles les approchent classiques avaient déjà échouées plusieurs fois. En effet, l’approche ontologique permet de s’abstraire au fur et à mesure de la nébuleuse qu’est souvent la structure legacy, tout en testant ensuite le fait d’obtenir les mêmes résultats. De plus, là où dans les approches classiques, un petit détail peut invalider toute la structure de l’implémentation, ou forcer des contournements qui s’accumulent rapidement et rendent l’ensemble instable ou non-maintenable, dans l’approche ontologique, il est juste question de rajouter un concept, quelques attributs ou modifier / créer quelques règles supplémentaires. Autrement dit, c’est aussi simple que de mettre à jour de la documentation métier, mais sans avoir à s’encombrer de formulations complexes ni de phrases à rallonge.

H : Quelle est la plus grande réussite d’ODASE à ce jour ?

RLB : ODASE est actuellement utilisé dans le milieu de l’assurance, ce qui est gage de la fiabilité de l’outil et de l’intérêt de l’approche. C’est une très belle référence pour nous, et notamment de notre capacité à modéliser avec précision des ensembles métiers particulièrement complexes. 

H : Comment ODASE vise à se développer dans les années à venir ?

RLB : Nous sommes en train de créer notre propre outil qui permettra de visualiser et d’éditer les ontologies. L’objectif est que l’ensemble devienne plus simple, intuitif, pratique et confortable d’utilisation. Les étapes clefs sont :

  • la visualisation de l’ontologie (concepts et règles), en permettant de construire et enregistrer des vues qui affichent seulement les concepts qui leurs sont pertinents,
  • l’édition simple d’attributs ou de règles, pour permettre au métier de gagner de l’autonomie sur ces aspects,
  • l’ajout de règles,
  • puis de rajouter progressivement différents outils qui sont pratiques ou nécessaires pour les ontologues.
Etat actuel de l’outil de visualisation des ontologies.
Tout cela se fera évidemment en prenant en compte les retours des utilisateurs et utilisatrices, et avec pour objectif d’avoir avant tout un outil simple pour le métier, et ensuite seulement un outil pratique pour les ontologues, ce qui passera vraisemblablement par le fait de conditionner l’affichage de certains éléments à des options.

Merci à Rémi Le Brouster pour cette présentation détaillée du fonctionnement d’ODASE !

Découvrir ODASE, partie I : définir les ontologies

Il était une fois une entreprise qui avait un système d’information. Dans ce système prospéraient différents applicatifs, plus ou moins récents et plus ou moins bien maintenus. Même s’ils formaient un ensemble hétéroclite et souvent assez bancal, tous ces applicatifs avaient bon nombre de points communs. Premièrement, ils parlaient souvent des mêmes choses (de « clients », de « contrats », de « factures », de « produits »…) Deuxièmement, ils étaient mal documentés, vraiment très mal documentés. Troisièmement, ils faisaient l’objet d’une lutte sans relâche : les équipes techniques refusaient de porter la connaissance fonctionnelle de ces outils, et les équipes fonctionnelles refusaient d’admettre que les équipes techniques ne connaissaient pas leurs règles de gestion.

Les problèmes de cette entreprise étaient aussi épineux que désespérément ordinaires.

Aujourd’hui, notre invité Rémi Le Brouster est avec nous pour parler d’une solution, nommée ODASE, visant à résoudre les problèmes de cette entreprise.

Hightest : Bonjour Rémi ! Tu es directeur technique adjoint de la solution ODASE, et tu étais précédemment développeur. Au cours de ta carrière, as-tu déjà été impliqué au sein d’une entreprise comme celle dont on parlait à l’instant ?

Rémi Le Brouster : Bonjour Hightest ! Ca m’est en effet arrivé, et c’est aussi pour cela que je me suis beaucoup investi pour rejoindre ODASE. J’ai été dans une entreprise très orientée métier, avec une problématique de migration d’un ancien logiciel vers un nouveau, où il fallait donc recouvrer et réimplémenter les règles de gestion. L’ancienne application datant, les spécialistes des différentes parties du métier n’étaient plus tous là, et ceux qui les avaient remplacés étaient parfois contraints de nous répondre de refaire pareil, faute de documentation métier suffisante, ce qui impliquait de fouiller dans le code

Cela était d’autant plus déroutant que la fiabilité de l’ancien logiciel était contestée, donc il fallait avancer en marchant sur des œufs.

Et évidemment, en voulant réimplémenter les comportements métiers, qu’ils soient historiquement bien réalisés ou fautifs, les développeurs introduisaient aussi de nouveau bugs, ce qui est le lot de presque tout développement.

Je pense également que ce genre de problématiques arrive dans beaucoup d’entreprises, mais avec le chef de service informatique / responsable R&D qui fait le tampon entre le métier et les développeurs, ce qui invisibilise le problème pour ces derniers.

H : Quel est l’objectif d’ODASE ?

RLB : L’objectif d’ODASE est de séparer intégralement le métier de la technique. Le métier doit être garant de la partie métier, tout comme les développeurs doivent se concentrer sur le code et ses problématiques techniques. Pour cela, il faut un outil capable de faire la passerelle entre les deux, se basant donc sur la documentation métier, et qui soit interrogeable via des applications, en leur retournant les résultats calculés souhaités. Cela permet aussi que cette documentation métier soit nécessairement à jour et en phase avec les applications.

Habituellement, dans les systèmes d’information :

• Les spécifications métier peuvent être éparpillées, redondantes, incomplètes, incorrectes, ambiguës.
• Le nombre de lignes de code peut être très important.
• Les changements dus au métier affectent toute l’implémentation.
• Ces changements métiers sont rarement bien documentés, bien qu’ils devraient l’être.
• Le debugging porte tant sur la technique que sur le métier puisque les experts métier n’ont pu intervenir en amont de l’implémentation.

Mettons qu’un SI ait un client lourd et une appli web, voici à quoi cela ressemble classiquement :

Il est courant de trouver des spécifications métier redondantes voire contradictoires les unes envers les autres. Chacune vit sa vie.

Avec ODASE, un certain nombre de choses changent.

• Le métier et la technique sont clairement séparés.
• Le métier est défini en un point unique (l’ontologie et les règles associées).
• L’ontologie est validée en amont avec les experts métier grâce aux explications.
• Il ne peut pas y avoir de contradictions entre le métier et l’implémentation technique.
• Le nombre de lignes de code est très réduit (il ne couvre que la technique).
• Les changements métier ne portent que sur l’ontologie.
• L’ontologie est une documentation de la vérité métier, toujours à jour.
• Les tests de type informatique ne portent que sur la technique.

On se retrouve donc avec une configuration comme suit :

ODASE permet de centraliser les modèles métiers et devient une source de vérité fiable.

H : Comment fonctionne ODASE ?

RLB : Notre fonctionnement est qu’un·e ontologue se charge de la modélisation du métier sous forme d’ontologies, et idéalement cela se fait en interaction forte avec un·e ou plusieurs spécialiste·s métiers, qui formulent le fonctionnement métier, et valident au fur et à mesure l’expression ontologique du métier. L’ontologue s’appuie aussi généralement sur de la documentation, et parfois même du code.

L’ontologie se découpe principalement en une représentation des concepts, de leurs attributs et de leurs liens entre eux, et en une spécifications des règles métiers qui définissent l’interaction entre ces différents éléments. Ces règles métiers sont des propositions logiques, ce qui signifient qu’elles sont tout le temps vraies, et qu’il n’y a aucune notion d’ordre entre elles.

Description de concepts d’une ontologie simple de démonstration. Dans cet exemple, il s’agit d’une application de location d’œuvre d’art. On voit que pour un contrat de location, on a plusieurs propriétés : une durée de location, un un prix total, un locataire…
 
Fichier contenant les règles métiers de l’ontologie. On voit ici que chaque règle de ce ficher est exprimée sous forme de conditions : si ceci, alors cela. Par exemple, on voit que si l’artiste est décédé, alors le contrat de location d’œuvre d’art comprend un supplément (afin de promouvoir les artistes vivants).
Afin de valider ces règles métiers, on peut implémenter des cas de tests, et vérifier les résultats. On peut également enregistrer les résultats des différents cas de test, afin que l’outil indique les changements lors d’exécutions futures.
Détection du changement d’un résultat de test
Détail du changement d’un résultat de test.

H : Pour parler en langage de testeur, ODASE permet de réaliser une analyse statique automatisée du référentiel métier… C’est top ! 

RLB : Notre outil permet également l’explicabilité de ces résultats, pour savoir par exemple pourquoi on obtient ce prix, ou pourquoi telle promotion ne s’est pas appliquée.
Explication du montant de 6€ de la réduction pour jeune locataire.

On obtient ainsi une représentation du métier spécifique, compréhensible et validée par le métier, que l’on peut faire évoluer facilement.

H : Mettons qu’ODASE soit installé dans une entreprise où travaillent des testeurs. Quels sont les changements à prévoir dans le quotidien de ces testeurs ? Quelle interaction avec ODASE prévoyez-vous ?

RLB : Tout dépend du contexte. Par exemple, si les testeurs ont une bonne connaissance métier, il peut être pertinent pour l’ontologue d’échanger avec eux, pour essayer d’en extraire de la connaissance métier, en complément des autres sources disponibles.

Dans ce contexte de bonne connaissance métier des testeurs, ou s’il y a une application legacy, ils peuvent aussi spécifier des cas de tests, et les résultats attendus. Cela permettra de valider que le métier est bien couvert, et de garder un œil sur des cas particulièrement complexes, stratégiques, ou historiquement problématiques, en vérifiant l’impact des évolutions sur le résultat des tests.

Les testeurs peuvent également valider, dans les applications techniques, que les résultats obtenus sont les bons. En effet, même si le métier est juste, si les applications qui interrogent ODASE ne fournissent pas les bonnes informations, c’est-à-dire s’ils envoient une mauvaise valeur ou omettent une variable nécessaire dans la construction du JSON de la requête envoyée (dans le cas d’une architecture client/serveur), le résultat sera erroné. Dans cette continuité, les testeurs peuvent également porter leur attention sur l’évolution de l’API, par exemple suite à l’évolution des informations nécessaires d’un point de vue métier, pour tester que ces évolutions ont bien été prises en compte techniquement dans les applications.

H : Quels types de profils deviennent ontologue ?

RLB : Il s’agit en général de docteur·e·s en informatique spécialisé·e·s dans la représentation des connaissances.

H : L’approche d’ODASE rappelle celle du BDD (behavior driven development). Comment se situe ODASE vis-à-vis des outils de BDD ?

RLB : Notre approche étant basée sur des propositions logiques toujours vraies, elle est fondamentalement orientée état. Ainsi, il n’y a pas du tout la notion de « When » des scénarios « Given … When … Then … ». Un état partiel est transmis à ODASE, et ODASE complète le reste. Le comportement, lui, est implémenté au niveau de l’applicatif, de façon technique.

De même, nous cherchons à représenter la réalité métier, de façon indépendante des fonctionnements attendus. Ainsi, ce ne sont pas des tests à passer, ni une volonté stratégique, commerciale ou produit quelconque qui vont régir l’ontologie. La réalisation de l’ontologie est avant tout une quête de la plus pure réalité métier. Les choix ontologiques sont uniquement faits en ce sens. Par contre, on peut s’adapter pour modéliser une partie de cette réalité métier avant une autre.

H : Merci Rémi pour ton temps et tes explications !

Retrouvez l’intégration d’ODASE dans le quotidien des équipes techniques dans la deuxième partie de cet article !

Découvrir ODASE, partie II : intégrer les ontologies dans le SI

 

PS : Si vous souhaitez en savoir plus, voici l’adresse d’ODASE : info@odase.io

7 signes que vous faites de la sur-qualité, et comment vous en sortir

La sur-qualité est l’ennemie sournoise de la qualité ; elle se déguise pour lui ressembler, mais ne manque pas de nuire aux projets dans lesquels elle s’invite. Voici quelques signes qui vous permettront de l’identifier dans vos pratiques et dans celles de vos équipes !

Dans son acception la plus simple, la sur-qualité consiste à allouer à la qualité des moyens supérieurs aux besoins réels.

Dans cet article, nous montrerons que la sur-qualité peut également provenir d’une mauvaise gestion de moyens alloués à la qualité, même si ces moyens sont originellement bien dimensionnés.

Afin d’illustrer des comportements extrêmes à éviter, les traits sont volontairement un peu forcés ! 🙂

Signe 1 : Vous rejouez toujours tous les tests de régression

Contexte : vous avez passé du temps à écrire un test d’importance moyenne à faible en 2020 à l’occasion de l’implémentation d’une nouvelle fonctionnalité. Aucune anomalie n’a été détectée en exécutant ce test. La fonctionnalité s’est avérée très stable au fil du temps.

Ce test s’est pourtant retrouvé rejoué VINGT-HUIT FOIS, à l’occasion de chacune des campagnes de test qui ont eu lieu depuis.

Vingt-huit fois.

Pourquoi ?

Par habitude ? Parce que vous avez décidé, ou bien votre entreprise a décidé, que la qualité était une priorité, et que dans cette mesure il fallait rejouer à chaque campagne l’ensemble des tests de régression ?

Des leviers plus forts que vous sont certainement en jeu (biais cognitifs, management, etc), mais c’est contre-productif. Au mieux, cela dépense silencieusement un budget énorme qui avait été prévu à cet endroit. Au pire, cela contribue à construire une mauvaise réputation des activités de test. Ainsi pourrez-vous entendre les discours suivants :

  • « Les tests, ça coûte cher »
  • « Les recettes sont de plus en plus longues et créent un goulet d’étranglement »
  • « On fait de plus en plus de tests mais on ne trouve pas de plus en plus de bugs »
  • « Les testeurs doivent s’ennuyer, ils font toujours la même chose ».

Comment éviter ça ?

Le meilleur moyen d’éviter cet écueil est de prendre le temps de revoir sa stratégie de test, et de trouver un équilibre entre rapidité et couverture de test.

Signe 2 : Vous conservez tous les cas de tests écrits depuis le début du projet

« Ce cas de test a bien été écrit pour une raison… »

C’est le seul motif que vous avez pour conserver ce cas de test, et le rejouer respectueusement campagne après campagne.

La personne qui l’a écrit est partie depuis des mois, d’autres tests ont été écrits depuis qui couvrent peut-être encore mieux cette partie, mais dans votre esprit, il est hors de question de supprimer ce cas de test.

Or, un référentiel de tests en bonne santé est comme un serpent ; il grandit certes, mais lentement, et se débarrasse régulièrement de sa peau morte. Comme l’indique avec humour le wiki Fan de Test, conserver, par principe, la totalité des tests écrits depuis le début du projet, relève de la syllogomanie.

Comment éviter ça ?

Effectuer régulièrement une revue des tests, pour éventuellement en supprimer ou en fusionner, est une bonne pratique. Il y a de quoi hésiter avant de supprimer un cas de test, mais si vous utilisez un outil de gestion des tests qui intègre une gestion des versions, cela devient beaucoup moins intimidant.

Signe 3 : La combinatoire vous contrôle plus que vous ne la contrôlez

Vous voulez tester toutes les configurations, TOUTES.

Un produit peut être de 10 couleurs différentes et de 5 tailles différentes ? Boum, vous prévoyez 50 tests pour vérifier que ce produit s’affiche correctement dans le panier quelle que soit sa couleur et sa taille.

Vous souhaitez que le site web fonctionne correctement sur les 3 navigateurs les plus utilisés du marché ? Allez : 50 tests multipliés par 3, 150 tests.

Et ainsi de suite.

C’est une caricature évidemment, mais pourrait-elle être votre caricature ?

Comment éviter ça ?

Découvrez des techniques, par exemple Pairwise, qui vous permettront de réduire le nombre de jeux de données tout en conservant une couverture satisfaisante.

Et pour éviter le paradoxe du pesticide, changez de temps à autre les jeux de données !

Il est important également de voir les cas d’utilisation au-delà de la combinatoire. S’il est possible, dans un formulaire d’inscription, de saisir un pays de résidence et une devise préférée, il est important de proposer l’euro aux utilisateurs ayant choisi la France comme pays de résidence. Le dollar des Tuvalu (archipel de 11 000 habitants)… un peu moins. Inutile donc de fournir le même effort de test sur les deux cas !

Signe 4 : Vous avez des lubies

Un jour, vous avez trouvé un bug de sécurité sur un applicatif A, qui pouvait être reproduit en modifiant malicieusement le contenu de listes déroulantes. Vous avez donc mis en place des tests très poussés sur cette partie, ce qui s’est révélé parfaitement pertinent dans le contexte. Quel bonheur de faire une si belle moisson de bugs ! Quel génie !

Depuis, à chaque fois que vous vous retrouvez sur un nouveau projet, vous mettez en œuvre ce type de test. La sécurité des listes déroulantes est systématiquement testée de fond en comble. C’est votre dada. Et peu vous importe que cela prenne du temps, peu vous importe que les risques ne soient pas les mêmes ; ça a marché une fois, ça devrait marcher de nouveau !

Bref, il est facile d’oublier les 7 principes généraux du test logiciel, et un en particulier : « Les tests dépendent du contexte ».

Comment éviter ça ?

Votre expérience de testeur doit vous bonifier avec le temps, ouvrir vos perspectives et vous permettre de vous adapter à toujours plus de situations. Si vous pensez constamment à ce qui a fonctionné sur vos précédents projets, vous risquez de tomber dans la sur-qualité sur certaines parties anodines et d’utiliser le temps dédié aux tests à mauvais escient.

Le mieux est alors, à chaque fois que l’on intervient sur un nouveau projet de test, de s’efforcer à adopter un regard neuf. Presque comme si on voyait un logiciel pour la première fois… tout en capitalisant sur l’expérience passée. Un exercice d’équilibriste, mais qui en vaut la peine !

Signe 5 : La loi de Murphy est votre seule crédo

« Tout ce qui est susceptible d’aller mal ira mal. »

L’applicatif à tester est mis en production toutes les deux semaines ? Pas de problème : toutes les deux semaines, vous faites non seulement des tests sur des cas passants, sur des cas non-passants, mais aussi sur des scénarios abracadabrantesques. Toujours les mêmes, par sécurité, parce qu’on ne sait jamais.

Hé oui, car que se passerait-il en production si un utilisateur essayait de changer sa date de naissance de manière à indiquer qu’il est né après-demain, en passant par l’inspecteur parce que l’interface web ne permet pas cette manipulation ?

Quelle question brûlante, cela vaut vraiment la peine de faire ce test tous les 15 jours ! (Ironie)

Comment éviter ça ?

La loi de Murphy n’est pas dénuée de bon sens, mais la plupart du temps, il est important d’obtenir d’abord des informations sur ce qui est le plus probable d’arriver.

Pensez avant tout au besoin métier, recentrez-vous sur le cœur des exigences.

Dans la mesure du possible, collectez également des informations sur les utilisateurs finaux : quels sont leurs besoins les plus fréquents ? Quelles sont les fonctionnalités qu’ils utilisent le plus ? Quelles sont leurs habitudes de navigation ? Cela aide à redonner à la loi de Murphy sa juste place.

Signe 6 : Vous testez comme des fous mais il y a tout de même des bugs découverts en prod

Le temps passé à couper les cheveux en quatre, consciemment ou inconsciemment, sur des fonctionnalités triviales, représente un manque à gagner. C’est du temps confisqué aux questions essentielles, celles qui s’intéressent à ce qui pourrait vraiment mal tourner.

La sur-qualité sur certaines parties n’empêche donc en rien… la sous-qualité sur d’autres !

Comment éviter ça ?

Prendre conscience du décalage entre l’important effort de test fourni, et les résultats infructueux, est la première étape. Cela permet ensuite de marquer une pause pour revoir la stratégie. L’étape suivante : recentrer les activités de test autour des fonctionnalités les plus fragiles, celles qui regroupent le plus de défauts (pensez Pareto !)

Signe 7 : Ajouter davantage de tests ne réussit pas au projet

« Les tests, c’est comme le fromage : plus il y en a et meilleur c’est ! »

Oui… mais dans les mêmes limites !

Ne niez pas : vous ne voudriez pas d’une pizza recouverte d’une couche de 4 centimètres de fromage. (Si ? Bon ok, mais à ce moment-là on a de très bons cardiologues à vous conseiller.)

Il existe de même un seuil à partir duquel ajouter des tests ne réussit plus au projet, au contraire.

Jusqu’à un certain point, augmenter les moyens alloués aux tests est bénéfique au projet : les anomalies sont trouvées plus tôt, et leur coût de correction est donc moindre.

Au-delà d’un certain point, les tests continuent de déceler des anomalies, mais plus suffisamment pour assurer le ROI de cette activité.

Comment éviter ça ?

Observez comment se déroulent vos campagnes de test.

Mettons qu’une campagne se déroule sur 4 jours ; si très peu d’anomalies majeures sont découvertes pendant les trois premiers jours, qu’aucune n’est découverte lors du quatrième, et que la nouvelle version ne révèle aucune nouvelle anomalie une fois en production, interrogez-vous collectivement : serait-il possible la prochaine fois de réduire le temps alloué à la campagne de tests ?

Ce temps gagné pourrait être utilisé autrement : en effectuant des revues de spécifications, en automatisant davantage de tests, en optimisant l’outil de gestion des tests…

Résultat : au fil de l’eau, les tests permettent de livrer de plus en plus vite en production, et deviennent un facteur visible de succès.

En conclusion

La surqualité est l’ennemie de la qualité, mais aussi de l’image que vos interlocuteurs se font des activités de test. Pire encore, elle cohabite volontiers avec la sous-qualité.

Elle met en péril l’efficience (faire bien les choses), et parfois aussi l’efficacité (faire les bonnes choses), des tests. Heureusement, des solutions existent !

Et vous, quels signaux utilisez-vous pour déceler la sur-qualité au sein de vos projets ?

test logiciel-video-bug d'expérience

[VIDEO] Un bug d’UX est-il un bug ?

Un bug, c’est « toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. » (Glossaire CFTL, ISTQB).
Si on se contente de lire la première partie de cette définition (jusqu’à « etc »), le positionnement général vis-à-vis du bug est tout à fait confortable puisque cela permet pour les testeurs de définir deux parties de leur activité assez clairement :
  • Vérifier que les exigences forment un ensemble cohérent
  • Tester si l’application est conforme à ces exigences
Par contre, pour la seconde partie, « les perceptions ou expériences de quelqu’un », c’est une autre histoire :
  • Qui est quelqu’un ?
  • Qu’est-ce qu’un bug d’UX ?
  • Quelles perceptions ? Quelles expériences ?
  • Quels biais entrent en jeu ?
  • Comment gérer ces bugs ?
Zoé vous apporte des réponses cette vidéo sur les Bugs d’expérience (UX).
Et vous alors, quels bug d’UX avez-vous pu trouver dernièrement ? Dans vos organisations, comment procédez-vous pour les trouver / corriger ?