Deez is la tech — Épisode 6— La qualité logicielle

paulinem 72 min de lecture

À première vue, on pourrait penser qu’un logiciel de (bonne) qualité est tout simplement un logiciel qui fonctionne. Mais la qualité ne se résume pas à l’absence de bugs, loin de là.

Ce sixième épisode de Deez is la tech s’attelle à expliquer ce qu’est la qualité logicielle, le rôle de l’équipe QA dans les processus de qualité et le changement de paradigme des métiers de la tech.

Des validations de tests en bout de chaîne au contrôle des process qualité en amont, à gauche toute !

Note: This post accompanies the release of the sixth episode of “Deez is la tech”, a podcast created by Deezer’s Product & Tech teams — in French only for now. You can still find English content on deezer.io though. Go check it out!

Résumé de l’épisode

Dans l’industrie, la notion de qualité fait depuis longtemps l’objet de normes et certifications pour décrire des processus permettant de s’assurer du fait qu’un produit a des caractéristiques reproductibles. Le monde du logiciel n’échappe pas à la règle car ses acteurs aussi se doivent de proposer des produits répondant aux attentes de leurs utilisateurs.

Mais en quoi consiste la qualité logicielle exactement ? Comment s’assure-t-on de la qualité d’une application ? Qui en est le garant ?

Dans ce nouvel épisode, Virgile Carron (Product Manager | LinkedIn), Anthony Dussaut (Team Manager QA XP Engineer | LinkedIn) et Benmar Franco Iglesias (Senior QA Manager | LinkedIn) partagent leur vision des processus de qualité, en évoquant notamment l’évolution du rôle des équipes QA, le principe de “shift-left” (ou décalage des tests “vers la gauche”) et l’importance de l’automatisation des tests dans ce contexte de transition.

Comme à l’accoutumée, cet épisode est animé par Loïc Doubinine (Twitter) et Vincent Lepot (Twitter | Mastodon).

Transcript

[00:00:07.080] — Vincent : Bonjour et bienvenue dans Deez is la tech, le podcast qui n’pète ni les plombs, ni les crons ! Je m’appelle Vincent. Et pour co-animer avec moi, comme à l’accoutumée, il y a Loïc. Salut Loïc !

[00:00:20.730] — Loïc : Salut ! Heureux d’animer ce nouvel épisode avec toi, qui sera de qualité puisque c’est le sujet de notre discussion du mois.

[00:00:30.860] — Vincent : Lorsque j’achète une paire de chaussures dans un magasin, j’essaie en général de trouver une paire qui me plait esthétiquement évidemment, mais aussi plutôt en cuir, pour sa solidité. Cela fait partie des critères qui, selon moi, définissent une paire de chaussures “de qualité”. J’entends par là, un produit que je considère être de bonne facture et dont je peux présupposer les caractéristiques — comme la bonne tenue dans le temps dans le cas de mes chaussures en cuir. Si l’on en croit mon meilleur ami Larousse, on peut définir la qualité comme, je cite, “l’ensemble des caractères et des propriétés qui font que quelque chose correspond bien ou mal à sa nature et à ce qu’on en attend”. Ou, je cite encore, comme “chacun des aspects positifs de quelque chose qui font qu’il correspond au mieux à ce qu’on en attend”. Dans l’industrie, la qualité est une notion qui fait l’objet, depuis plusieurs années, de normes comme les ISO 9000, de certifications pour décrire des processus qui permettent de s’assurer du fait qu’un produit a des caractéristiques reproductibles. Le monde du logiciel n’échappe pas à la règle car, lui aussi, se doit de proposer à ses utilisateurs des produits répondant à leurs besoins. Comment assure-t-on la qualité d’une application ? Quels sont les critères d’un logiciel de qualité ? À quoi s’expose-t-on en cas de non-qualité ? Bref, la qualité dans le logiciel, c’est qui, c’est quoi et pourquoi ? C’est de cela que nous allons parler avec nos trois invités du jour qui, eux aussi, sont de qualité. On va commencer par celui qui est avec nous en studio : Anthony Dussaut, bonjour !

[00:01:55.620] — Anthony : Bonjour ! Moi c’est Anthony, je suis développeur chez Deezer depuis maintenant huit ans et demi et je travaille dans une équipe qui s’occupe de créer du tooling pour les équipes qui vont s’occuper de la qualité — notamment pour l’équipe QA — mais aussi d’autres types de tools qui vont permettre aux développeurs de potentiellement monitorer des métriques de qualité ou autre chose.

[00:02:17.700] — Vincent : Merci. On va pouvoir y revenir plus longuement. Également avec nous “en distanciel”, comme on dit : Benmar Franco Iglesias. Bonjour Benmar !

[00:02:26.110] — Benmar : Bonjour ! Benmar, QA manager dans l’équipe Listeners qui se trouve dans une startup qui s’appelle Core Product, donc vraiment au cœur du produit (note : les “startups” sont des sous-divisions du département Product & Tech chez Deezer). Je suis chez Deezer depuis quatre ans.

[00:02:38.010] — Vincent : Merci. Et également avec nous en distanciel : Virgile Carron. Salut Virgile !

[00:02:44.800] — Virgile : Salut tout le monde ! Virgile Carron, ça fait un peu plus de six ans que je suis chez Deezer, je suis Product Manager et j’ai fait un passage par l’équipe QA notamment en tant que Lead QA d’une équipe.

[00:02:55.120] — Vincent : Nous allons donc parler de qualité pendant le temps qu’il faudra et à la fin de l’émission, on reviendra avec vos coups de cœur musicaux. Aller, c’est parti !

[00:03:11.880] — Loïc : Première question : selon vous, c’est quoi la qualité logicielle ?

[00:03:16.400] — Anthony : Pour moi, la qualité logicielle, c’est un peu un mot fourre-tout qui va comprendre beaucoup, beaucoup de choses. Je pense que le principe de qualité, déjà, c’est ce que le client, ce que nos utilisateurs par exemple chez Deezer, vont pouvoir ressentir de ce qu’on propose. La qualité, ensuite, est déclinée en plein de petites parties. La qualité logicielle, donc ce qui va être la qualité qu’ils peuvent avoir sur les différentes features, sur leur utilisation, sur l’accessibilité et sur plein de choses dont on aura peut être le temps de reparler plus tard. Et il y a aussi la partie un peu plus cachée mais qui a un impact énorme aussi sur l’utilisateur, qui est la qualité directement du code, de ce qu’on propose d’un point de vue technique. Car du mauvais code peut avoir un impact directement via des bugs sur l’utilisateur, mais aussi sur notre capacité à délivrer, et donc sur des améliorations continues sur notre appli.

[00:04:12.020] — Benmar : De mon côté, je trouve effectivement qu’Anthony a donné une excellente description. C’est décliné en plusieurs facettes. Je pense que, pendant longtemps, on se concentrait sur des aspects plutôt liés aux critères d’acceptation sur les spécifications ou bien le nombre de défauts. Je pense que, de plus en plus, ce qui est important, c’est de retenir la valeur perçue par les utilisateurs. C’est vraiment, je pense, aussi une évolution de la perception de la qualité. La qualité, ce n’est pas simple, c’est sur plusieurs aspects que ça se joue. Mais au final, effectivement, on fait un produit et ce qu’on veut, c’est que ce soit conforme aux attentes des utilisateurs. Donc je pense que c’est ça qu’il faut retenir aujourd’hui de ce qui doit être perçu comme la vraie qualité d’un produit.

[00:04:52.400] — Virgile : Pour faire un petit résumé des deux, je pense que c’est un bon équilibre entre qualité pour les utilisateurs mais aussi robustesse de ce qu’on produit et de ce qu’on crée. C’est-à-dire créer un produit flexible qui est capable d’amener plus de valeur dans le futur aussi.

[00:05:07.960] — Vincent : Dans ce cadre-là, le rôle d’une équipe QA, ce serait quoi ?

[00:05:13.280] — Benmar : Pareil, j’ai la certitude qu’il évolue. Je pense que ce doit être l’un des métiers dans la tech, en tout cas, qui est le plus changeant et chez qui l’on challenge constamment les process et la façon de travailler, limite même les nomenclatures des rôles. Juste le fait d’appeler ça “QA”, c’est challengé aujourd’hui dans l’industrie. Typiquement, je pense qu’il y a des choses à défaire au niveau de “qu’est-ce que la qualité assurance” et “qu’est-ce que les contrôles de qualité”. Aujourd’hui, c’est beaucoup trop souvent confondu — et je ne parle pas nécessairement de chez Deezer, mais en général. Je pense qu’on est davantage passé sur le concept de contrôle de qualité quand on parle de “qualité assurance”. Et en fait, la QA — qualité assurance dans son origine si on veut, c’est vraiment essayer de faire en sorte que certains principes, certains process, certaines bonnes pratiques soient appliqués tout au long de la chaîne — chose qui, aujourd’hui, s’est un peu perdue, s’est convertie en validation en bout de chaîne de conformité à des exigences et un peu en garant de vérifier que tout est ok pour aller en prod, ce qui n’est pas vraiment le but original.

[00:06:20.900] — Anthony : C’est vrai qu’on avait tendance à penser — et toujours d’ailleurs dans pas mal de boîtes au final, à parler d’”équipes QA” où c’est la QA qui est responsable de la qualité. De plus en plus, moi, avec l’expérience, je pense que c’est un mauvais parti pris, que la qualité se partage dans toute une équipe et que c’est quelque chose qui devrait être directement dans les cordes de toutes les équipes et de tous les métiers qu’il y a autour du logiciel. C’est-à-dire qu’on pourrait avoir une équipe QA exceptionnelle qui arrive à traquer tous les bugs de la terre et laisse passer zéro bug en production, et se dire “on a une bonne qualité”. Mais si d’un point de vue produit, on ne répond pas du tout à ce que les clients attendent, qu’on a un truc moche, un petit peu bancal, notre produit final ne sera pas du tout de qualité. Donc en effet, on a vu pas mal de choses récemment en France. Ça fait beaucoup plus longtemps aux Etats-Unis qu’on parle de “quality assistance” par exemple ou de “shift-left” dans les différents processus de qualité, ce qui en fait amène la discussion en amont, donc en même temps qu’on écrit des specs — qu’elles soient techniques ou produits, pour que ces discussions sur “qu’est-ce qu’on veut atteindre comme qualité ?”, “qu’est-ce qu’on veut atteindre aussi en termes de tests ?” — pour vérifier justement, faire le contrôle de qualité au fur et à mesure du process — soient mises dès le début à plat. Et ce n’est pas une équipe QA qui va dire “nous, on va faire ces tests-là en bout de chaîne”. Non, c’est vraiment une discussion globale de toute l’équipe tech pour savoir exactement comment on va contrôler la qualité de ce qu’on produit.

[00:07:47.960] — Loïc : Donc ça veut dire que tu vas avoir cette assistance aussi bien au niveau des développeurs, quand il va y avoir la construction même des features…

[00:07:54.530] — Anthony : Exactement.

[00:07:55.220] — Loïc : …que la définition du produit, c’est-à-dire ce qu’on veut faire comme fonctionnalité sur le produit qu’on a.

[00:07:59.570] — Anthony : Exactement. Il y a des revues de specs qui sont faites directement avec les développeurs, avec potentiellement les équipes QA — s’il y a toujours des équipes QA — pour voir si les specs répondent à ce qu’on veut d’un point de vue logique. Je prends des exemples tous bêtes mais, sur pas mal de features, il y a déjà des standards dans l’industrie. Aujourd’hui, on ne sort pas un dark mode, par exemple, avec un noir absolu. On sait que ça fait mal aux yeux, il y a plein de recommandations Google à suivre pour dire “non, il faut un espèce de gris anthracite” qu’on connait un petit peu sur tous les sites. Ça fait partie de la qualité. Et si tu proposes un dark mode sur un site et que c’est du noir absolu ou du blanc absolu, c’est quelque chose qui va faire mal aux yeux. C’est comme ça, l’œil humain n’est pas habitué à ça. Ça fait partie de la qualité et pourtant, c’est une spec qu’on pourrait dire seulement produit. Mais pas seulement au final.

[00:08:46.550] — Loïc : Oui et du coup, ça s’éloigne vraiment de la “compliance” — ce que disait Benmar à un moment donné, c’est-à-dire juste respecter les règles établies à l’avance. C’est carrément être proactif en disant : la règle qu’on est en train de s’édicter — tu parlais de la couleur de fond par exemple — cette règle elle-même doit évoluer pour qu’elle ne soit pas tout à fait celle qu’on avait initialement prévue.

[00:09:03.650] — Anthony : Exactement. La qualité, de toute façon, commence au début du process. Vous, vous êtes développeurs par exemple, vous faites du test unitaire ou ce genre de choses ; au final, si vous n’avez pas les specs, vous ne savez pas exactement comment vous allez pouvoir créer vos modules, comment vous allez pouvoir les tester les uns avec les autres facilement, vous n’allez pas savoir quelle API il faut appeler… Voilà, si tout ça n’est pas directement dirigé, vous n’allez pas être capables de mettre en place quelque chose de bien. Vous allez pouvoir mettre en place vos stacks techniques mais derrière, s’il y a une petite modification côté produit — parce qu’au final, on essaie de partir ailleurs parce qu’on a pensé à quelque chose qui n’était pas de qualité à la base donc on fait une petite retouche, l’impact est énorme sur le développeur.

[00:09:41.020] — Vincent : Virgile, tu voulais rebondir ?

[00:09:42.680] — Virgile : Oui. Chaque individu, dans son expertise, a des bonnes pratiques. Il y a l’exemple du dark mode d’Anthony — ça c’est produit, voire même design. Il y a plein de bonnes pratiques côté dév aussi. Et en fait, quand on accumule toutes ces bonnes pratiques, il y a même plusieurs boîtes — et des boîtes parfaitement fonctionnelles — qui n’ont pas d’équipe QA. Ce sont des choix stratégiques de la part d’une entreprise, mais ça montre à quel point la qualité est censée être dans les têtes de tout le monde.

[00:10:07.150] — Vincent : Et est-ce qu’elle doit être dans les têtes de tout le monde ou aussi avoir des gens de la qualité, à chaque stade, qui peuvent intervenir ? Ou est-ce que ça peut être les mêmes personnes ?

[00:10:14.740] — Virgile : C’est un peu la grande question.

[00:10:16.900] — Benmar : Dans cette réinvention du rôle de l’équipe qualité, je pense que le rôle consiste plus à coacher, à s’assurer que ces rituels-là sont mis en place, que les gens sont effectivement bien impliqués en amont dans les kick-offs ou dans la rédaction des specs, qu’on ne saute pas des étapes. Fédérer en gros, évangéliser. Donc, encore une fois, pas garant de la qualité en soi, mais garant que ces étapes-là soient respectées.

[00:10:44.510] — Loïc : Oui, c’est garant du processus qui permet d’avoir, au final, une façon de travailler qui permet d’avoir une qualité acceptable — enfin acceptée on va dire — plutôt que de dire en bout de chaîne “ce que vous avez fait, ça ne remplit pas ou ça remplit les contraintes de qualité qu’on s’était fixées”. Sachant qu’en bout de chaîne, c’est souvent trop tard.

[00:11:04.940] — Anthony : Oui, c’est ça. Je vois bien ce rôle-là comme une espèce de chef de projet qualité qui suit une feature de bout en bout et qui va permettre de transmettre ses connaissances, de transmettre son expertise, mais qui va clairement changer de ce qu’on peut voir aujourd’hui — alors, je ne dis pas qu’il ne faut pas le faire — du carcan du testeur qui vient et qui va écrire ses cas de tests et qui va faire des tests manuels ou potentiellement — également un gros changement de l’industrie ces dernières années — automatiser lui-même avec des QA Engineers. Moi, je vois plutôt ça vraiment comme un rôle de garant de qualité globale, mais de process qualité. Après, tout process, toute organisation a des raisons d’être. Et chaque entreprise va avoir ses propres spécificités, ses propres problématiques en termes de taille d’équipe, en termes d’organisation, qui vont faire que le fait d’avoir un chef de projet qualité ne sera peut-être pas du tout la bonne réponse. Ça ne veut pas dire que le métier de QA, créateur de cas de tests et testeur manuel, est mort. Pas du tout. Ça dépend vraiment du contexte des boîtes. Je pense qu’il n’y a pas vraiment “une” bonne solution. Il faut juste trouver, dans les entreprises, “la” bonne solution par rapport à son propre paradigme.

[00:12:18.750] — Virgile : Oui, je crois pas mal aussi à cette notion d’évangélisation. Peut-être que c’est ça aussi que tu entends par “chef de projet”, Anthony ? Benmar, en tout cas, je pense que c’est ce que tu voulais dire. L’éternel danger, c’est de se dire que c’est la QA qui va s’occuper de la qualité. C’est vraiment l’affaire de tout le monde.

[00:12:35.020] — Vincent : Et ne pas tomber dans le cas qu’on a pu entendre — je l’ai entendu ici il y a très longtemps et je l’ai entendu dans plein de boîtes — qui est de dire “de toute façon, s’il y a un bug en prod, c’est de la faute de la QA”.

[00:12:45.380] — Virgile : Exactement. On peut faire cette analogie avec le football et le gardien de but : c’est pas tout le temps de la faute du gardien de but quand il y a un but.

[00:12:53.850] — Loïc : Et comment va-t-on matérialiser cette intégration des processus qualité dans le développement d’une fonctionnalité ? À quel moment ? Comment ?

[00:13:02.480] — Benmar : Les specs vont déjà être de plus grande qualité. L’idée de prévenir certains défauts ou certains cas à la marge est déjà prévue dans l’élaboration des specs. Donc ça donne déjà plus de billes aux développeurs pour faire du code de qualité, tout simplement. Et je pense aussi qu’avoir un meilleur partage et une meilleure communication, de meilleurs échanges sur ce qui est couvert en termes de tests unitaires entre autres, peut être intéressant au niveau de cet échange-là et de ces processus.

[00:13:29.630] — Loïc : Qu’est-ce qu’on partagerait ? Et qu’est-ce que les développeurs partageraient avec les personnes qui s’occupent des specs ? Ou comment discuteraient-ils ensemble ?

[00:13:36.830] — Benmar : En fait, c’est pas tellement avec les gens que… C’est pour ça qu’on parle d’être impliqué sur toute la chaîne, c’est-à-dire que c’est au moment où il faut les définir — ça peut être en amont, ça peut être pendant ou même après le push du code, c’est-à-dire qu’une fois que les lignes de codes sont écrites, voilà comment on va les tester — donc donner de la visibilité là-dessus. Je sais qu’il y a parfois des politiques de pourcentages de couverture. Typiquement, ces règles-là peuvent aussi être définies en accord avec l’équipe qualité. Ça permet surtout d’éviter la redondance des tests tout simplement, entre les tests unitaires de composants et les tests système qui seront fait un peu plus tard, de s’assurer la complémentarité de tout ça. Ça peut être hyper intéressant niveau efficacité, même sur le time-to-market. Si on refait des choses qui sont déjà testées ailleurs d’une autre manière, ce n’est pas très efficace.

[00:14:24.040] — Vincent : Tu parlais de tests système et de tests composant, peut-être qu’on peut se mettre d’accord sur le vocabulaire ? Je sais que des dénominations de tests, il y en a plein, et on est toujours un peu à mi-chemin entre “on voit très bien ce dont on parle” et “finalement, c’est relativement flou”. Pour vous, c’est quoi un test composant ? C’est quoi un test système ? Est-ce que vous avez d’autres types de tests en tête ?

[00:14:44.470] — Anthony : En réalité, ces différents types de tests sont assez bien décrits par quelque chose de très connu : la pyramide de tests. Elle a été mise en place il y a très longtemps, elle est aussi dans les principes SRE Google pour information. Et donc, en gros, pour les tests automatisés, il y a trois différentes strates : il y a les tests unitaires, les tests d’intégration et les tests systèmes. Et ensuite, il y a la dernière strate qui concerne les tests d’acceptance, qui sont en général plus “humains” parce qu’on teste par rapport à des specs, on est plus sur le visuel et autre. Tests unitaires, on teste directement le code. Donc, normalement, on est censé tester uniquement la méthode de test qu’on veut tester en mockant tout ce qu’il y a autour. Pour les tests d’intégration, c’est simplement l’intégration de deux composants l’un avec l’autre — que ce soit deux composants internes à une application ou un composant avec une API par exemple. Là aussi, on a pas mal de mocks et de stubs. Pour le test système par contre, on teste le système en entier donc aucun mock, aucun stub ne doit être mis en place. Là, en gros, on teste un peu comme notre utilisateur final.

[00:15:45.700] — Vincent : C’est-à-dire que là, typiquement, on va partir de — mettons — une appli mobile, on va cliquer sur les boutons et voir si ça répond ce que c’est censé répondre.

[00:15:52.900] — Anthony : Exactement. Je voudrais revenir sur ce que disait Benmar parce qu’il a parlé beaucoup de tests. Mais même au delà du test, comment pouvoir discuter et pouvoir améliorer un petit peu la qualité de notre logiciel ? Tout simplement, au niveau du code — on parlait de “chef de projet qualité” ou de “quality assistance” ou autre terme, le fait d’avoir, par exemple, un expert dans la techno qui est utilisée pour créer un site — un expert Java par exemple — qui va aller expliquer comment ça fonctionne, comment bien modulariser en composants, comment bien écrire son code pour éviter d’avoir des dépendances à gauche et à droite et de rendre quelque chose propre — on parle de “code propre” en général — c’est déjà de la qualité. C’est pour ça que ça rejoint exactement ce qu’on dit depuis tout à l’heure — et ce que Virgile a très bien dit aussi, c’est que la qualité est vraiment partout. Ce n’est pas juste le test. C’est vraiment au global. Ce sont toutes les communautés de pratiques qui peuvent être mises en place dans les différentes boîtes, qui vont discuter ensemble pour essayer de trouver le meilleur moyen, le moyen le plus efficace et le plus propre, de sortir des choses pour un utilisateur.

[00:16:53.940] — Vincent : Ça me rappelle une intervention qu’avait faite Céline dans l’épisode 2 de Deez is la tech, quand on avait fait un épisode sur l’accessibilité, qui nous disait : “pour nous, l’accessibilité est un critère de qualité comme les autres et il fait partie de la “definition of done”, c’est-à-dire que si le ticket ne respecte pas les problématiques d’accessibilité, il est retoqué aussi sec”. Donc finalement, ça fait aussi partie des spécifications.

[00:17:15.780] — Anthony : Tout à fait, oui. Et là, ce ne serait pas forcément un expert QA qui parlerait de ce genre de choses mais plutôt un expert sur ce sujet-là, qui peut très bien être un développeur, un expert en interne ou avec une équipe qui se monte — si c’est vraiment la philosophie de la société — ou tout simplement des consultants externes qui viennent exprès faire du contrôle qualité à ce niveau-là. On pourrait parler de beaucoup de choses aussi, de règles d’utilisabilité… On peut regarder un peu ce que font les concurrents aussi. Je parlais aussi de conformité, ça ne signifie pas forcément copier et ce n’est pas forcément une mauvaise chose. En général, c’est dit avec des termes assez peu élogieux mais ce n’est pas forcément copier bêtement pour faire comme le concurrent, mais pour donner une sorte de stabilité aux utilisateurs sur différentes applications, sur différentes façons de fonctionner et ne pas les perdre, tout simplement.

[00:18:04.830] — Loïc : On peut prendre l’exemple de l’iconographie autour de la musique qui est arrivée très tôt, quand les équipements de production et de reproduction audio sont arrivés. On a eu le petit triangle vers la droite ou vers la gauche qui indiquait la lecture, l’avance rapide qui était le triangle qui était doublé, le carré qui veut dire stop. La notion de copie devient presque une conformité parce que le sens de ces boutons est devenu un standard acquis par tout le monde. Et on s’attend, quand on appuie sur un triangle qui va vers la droite, à entendre de la musique ou du son.

[00:18:35.520] — Virgile : C’est complètement ce que tu disais tout à l’heure aussi Loïc, ce sont des normes implicites en fait.

[00:18:41.370] — Loïc : Avez-vous d’autres exemples de normes comme ça qui sont implicites et qu’on n’a pas forcément en tête quand on développe une application ou un produit quelconque ?

[00:18:50.740] — Anthony : Je peux prendre le parallèle avec le jeu vidéo parce que c’est ce que je connais le plus. Aujourd’hui, si on essaie de jouer à un jeu de type “on tire sur un petit peu tout ce qui bouge” comme un Call of Duty ou autre, tirer c’est le bouton gauche de la souris, recharger c’est le bouton R, mettre la lampe torche c’est le bouton F… Et si on sort de ce carcan-là, on perd l’utilisateur et les jeux sont en général considérés comme étant mal faits, mal pensés, alors que le jeu est potentiellement très bien. Mais ce sont juste des normes et on ne peut pas vraiment les changer. En général, quand il y a des modifications de choses qui sont aussi ancrées dans la tête des gens, ça fail. Il n’y a pas quelqu’un qui arrive et qui révolutionne le monde, en disant “maintenant, c’est comme ça” et tout le monde qui dit “ah ouais, c’est génial, bravo !” Même si potentiellement, d’un point de vue factuel, c’est peut-être mieux que ce qui a été fait, comme c’est ancré dans l’utilisation des gens, ça ne fonctionne pas.

[00:19:52.500] — Vincent : Je ne sais pas s’il y a, par exemple, des normes en terme de qualité. Je parlais tout à l’heure dans l’intro des ISO 9000 pour l’industrie. Est-ce qu’il y a des équivalents côté logiciel ?

[00:20:01.370] — Benmar : Oui, absolument. Je pourrais pas te les réciter mais effectivement, il y a des normes ISO dans la qualité.

[00:20:04.490] — Vincent : Quoi ? Tu ne les connais pas ?

[00:20:06.511] — Benmar : Par coeur !

[00:20:07.150] — Loïc : On veut les numéros.

[00:20:08.060] — Benmar : Je voulais toutes vous les réciter mais, en fait, je prendrais plus que l’heure donc voilà…

[00:20:12.920] — Loïc : On fera une annexe.

[00:20:14.840] — Vincent : Dans quel genre de domaine ça s’applique ?

[00:20:16.230] — Benmar : Typiquement, je pense que tout ce qui est nomenclature de types de tests et de méthodologies est très clairement stipulé par des normes. Il y a notamment l’ISTQB qui se porte plutôt garant d’avoir cette espèce de lexique, de vocabulaire via des syllabus ou autre.

[00:20:37.010] — Anthony : Il y a des normes de performance, il y a des normes de portabilité, c’est-à-dire qu’une application doit par exemple fonctionner sur plusieurs types de device et pas seulement un seul. Je ne les connais pas toutes non plus mais ce sont des choses assez standards, qui sont même hyper logiques, qui, aujourd’hui, sont faites un petit peu de manière…

[00:20:56.000] — Vincent : C’est devenu du commun…

[00:20:57.630] — Anthony : Oui, c’est ça. Sans y penser, sans le savoir, on sait juste que oui, quand on sort une application sur iOS 15, elle doit marcher sur iOS 16, quand on sort une application Android, elle doit fonctionner sur un Huawei, on sait qu’une application ne doit pas mettre trois heures à se lancer. Ce sont des normes un petit peu basiques qui manquent un petit peu d’échelons, c’est-à-dire de savoir exactement ce qu’on devrait fixer. Là, on a plus des normes proposées par des GAFAM — comme Google par exemple, qui a beaucoup de normes côté SRE et qui demande à avoir des choses très carrées qui disent “c’est ça qu’on vous propose”. Quand on parle de disponibilité d’un service par exemple, on parle des “trois neufs”, des “quatre neufs”, d’”error budget” aussi pour expliquer que les équipes doivent faire en sorte que la disponibilité du service soit maintenue à des niveaux respectables et qui sont un petit peu définis par Google. Mais c’est vrai que sur les normes ISO, ça manque un peu de concret et de métriques à atteindre.

[00:21:52.800] — Virgile : Et si je peux ajouter quelque chose là-dessus, je pense que des boîtes comme Deezer qui fonctionnent en Agile, c’est très difficile de… Enfin, ce n’est même pas un objectif d’aller chercher ces normes-là. L’idée, c’est de s’en inspirer, que ce soit dans notre tête au quotidien et que l’on essaie de tendre, évidemment, vers le produit le plus quali possible. Mais on a aussi cette notion d’avancer, d’avancer vite et bien. Et du coup, l’équilibre est parfois difficile à trouver entre produit qualitatif et temps à respecter pour les livrables, les deadlines, etc. C’est un peu la grosse problématique collective.

[00:22:28.100] — Vincent : Et du coup, au quotidien, comment appréhendez-vous les User Stories dans le cadre d’une équipe de développement ? Toi en plus, Virgile, qui as la casquette de Product Manager, comment faites-vous ?

[00:22:38.470] — Virgile : C’est quelque chose qu’on fait vraiment de plus en plus chez Deezer en ce moment : on essaye de faire des kick-offs sur chaque initiative, de mettre chacun des futurs acteurs de l’initiative le plus en amont, d’être très transparent sur les objectifs de l’initiative. Et même dans ce que l’on appelle “l’idéation”, on va inclure et même responsabiliser chacun de ces acteurs : développeurs, QA, product, designers ; on a même parfois la data qui est avec nous — Data Analysts, Data Scientists aussi. Et tout ça dans l’idée de sensibiliser tout le monde, toute l’équipe, à l’objectif de l’initiative, et d’arriver à repérer un peu les angles morts, à trouver les edge cases, les trous dans les specs tout simplement, tous ensemble.

[00:23:22.240] — Benmar : Ce concept d’idéation est relativement nouveau chez Deezer et ça marque très clairement cette tendance à shifter un peu vers la gauche sur tout ce qui est qualité en général. On en parlait tout à l’heure, c’est un peu l’évolution qu’il y a dans l’industrie et c’est — j’ai envie de dire — en cours d’implémentation. C’est encore très évolutif et on essaie de trouver la formule idéale, effectivement, pour ne pas mettre trop de temps à démarrer les projets et ne pas perdre trop en vélocité, mais aussi pour s’assurer que tout est propre au démarrage, qu’on a anticipé un maximum d’erreurs potentielles et de problèmes de qualité en tout début d’initiative.

[00:24:01.470] — Virgile : Là on parle de qualité, mais même en termes de valeur produit et de temps de livraison, ça permet d’identifier des “no-go” en amont, des choses qui seraient trop complexes, ou même des “quick wins”, des choses qui seraient très simples et qui ont beaucoup de valeur. Ça, c’est précieux comme discussion en amont d’un projet.

[00:24:18.570] — Loïc : Mais du coup, je me pose la question — ça va être la question fâcheuse, on va dire — est-ce qu’on n’est pas en train de revenir vers cette façon de procéder qu’on a chassée sur les dix ou quinze dernières années dans la tech, en voulant avoir cette phase de spécification, certes qui implique tout le monde — donc, ça, c’est le côté positif que je vois — mais par contre, qui prend du temps et qui peut-être ne prend pas en compte ce que l’agilité apportait, c’est-à-dire le fait de construire petit mais rapidement, et d’avoir du coup du retour rapidement aussi ?

[00:24:42.990] — Virgile : Ça va peut-être être une réponse un peu bateau mais on gagne tellement de temps en faisant ça qu’au final, on est gagnant. Et je pense surtout qu’on n’a pas perdu en termes d’agilité. On arrive à délivrer quelque chose qui a plus de valeur dans un temps quasi similaire donc je trouve qu’on ne perd pas du tout en agilité.

[00:25:00.810] — Loïc : Vous avez déjà des effets positifs notables ?

[00:25:04.260] — Virgile : Moi, j’en ai vu. Après, c’est un peu bâtard parce que ce qu’on appelait “agilité” aussi avant — même toujours aujourd’hui — mais ce qu’on pouvait labéliser “agilité”, c’était le fait de commencer un projet et en plein milieu de se dire : “hop, on arrête, en fait, on se rend compte que ce n’est pas une bonne idée et du coup, on va passer à telle initiative”. Ça, en effet, c’est agile. Mais si on peut se permettre de ne pas travailler sur un projet qui, au final, n’a pas de valeur, et si on peut manger une semaine pour se rendre compte de ça, moi je signe direct ! Et c’est ce qu’on est en train d’essayer de faire justement.

[00:25:35.320] — Anthony : Oui, je pense que ce n’est pas antinomique non plus de se dire qu’on va travailler un petit peu plus sur les spécifications par rapport au fait de se lancer directement. Comme dit Virgile, déjà, il y a des gains directs. Mais aussi, on est plutôt sur un découpage différent d’une feature. On peut très bien avancer de cette manière sans se dire “on réfléchit aux specs entières, on réfléchit à tout” mais justement en travaillant ensemble, au fur et à mesure, sur la spécification d’une nouvelle feature, sur une petite partie. Et le but est d’avoir justement le développeur, le product, la personne qui va être plutôt côté QA, et qu’ils parlent ensemble. En réalité, on est dans l’agilité parce qu’on est sur une phase de spécification mais on est aussi sur une phase de test, c’est-à-dire que le développeur et le QA sont en train de tester des specs directement. Donc on est, justement, vraiment plus sur ces notions d’agilité. J’ai beaucoup vu de fausse agilité dans les entreprises où on se dit “oui, on est agile”, du coup on a des pseudo specs qui arrivent, le développeur commence directement à coder, le QA va tester le truc qui a été codé par le développeur, mais personne ne s’est parlé et en réalité, on est dans des mini waterfalls. On n’est pas du tout dans de l’agilité. Finalement, dépendamment du scope des spécifications, on peut rester dans de l’agilité assez facilement, mais avec une phase de préparation en amont.

[00:26:51.210] — Benmar : Complètement en phase avec les deux interventions, d’autant plus qu’on peut contribuer à un meilleur découpage. Donc ça permet d’être encore plus agile, donc de mieux définir quels seront les potentiels livrables de valeur ajoutée les plus minimes qu’on va livrer d’abord, et ensuite les itérations. On reste sur de l’itératif dans tous les cas. Tout le monde a cette mentalité agile quand on participe à ce genre de phase d’idéation, donc : quels sont les quick wins qu’on peut aller chercher et qu’est-ce qu’on peut vraiment faire tout de suite ? Sur quoi va-t-on itérer ensuite techniquement ? Au niveau même de la phase de test, qu’est-ce qui est plus rapide à valider, à mettre en production pour avoir une valeur ajoutée le plus rapidement ? Donc, en gros, ça contribue aussi au concept d’agilité en soi.

[00:27:30.870] — Anthony : Et autre chose qui est hyper important en faisant ce genre de travail : il y a une certitude, c’est qu’un bug coûte de plus en plus cher au fur et à mesure du cycle de livraison. Si un bug est trouvé en production, c’est ce qui coûte le plus cher à corriger parce qu’il est déjà en prod, donc c’est peut-être un rollback complet qu’on va être obligé de faire — ce qui est faisable sur le web mais alors sur mobile, quand on a des cycles de release qui prennent plusieurs semaines, voire des mois pour certaines entreprises, là, on parle de rollback très complexe. Et du coup, si l’on est déjà en train de tester les spécifications — qu’elles soient techniques ou produit, parce que c’est hyper important de remettre un petit peu de tests sur les techniques aussi, de vraiment vérifier — on peut commencer à parler de testabilité, d’observabilité des features, de ce qu’on est en train de produire, et d’avoir beaucoup plus d’indicateurs qui nous permettent de détecter ces problèmes le plus tôt possible, avant que ce soit en prod. Et donc, tout ça va nous permettre d’avoir tout simplement une meilleure efficacité au fur et à mesure, et de garder une vélocité ou même d’augmenter notre vélocité sur nos projets.

[00:28:32.310] — Benmar : Oui, je rebondis là-dessus, plutôt sur la phase de test. Concrètement, un truc qui peut coûter beaucoup de temps, c’est de ne pas avoir anticipé ou prévu soit la testabilité, soit le fait que la feature est testable, mais que l’on n’a pas le jeu de données qui va bien pour tester. Ça, ça peut faire beaucoup d’allers-retours et des points de blocage sur… On n’est pas en mesure d’aller plus loin dans la phase de test, et revenir en arrière pour organiser mieux cette phase de test-là, c’est effectivement très coûteux en temps. Souvent, c’est justement au moment où l’on était très proche de livrer la feature que l’on se rend compte de ce délai additionnel, c’est très contre-productif.

[00:29:12.570] — Loïc : À vous écouter, si l’on fait le parallèle avec le début du podcast où vous disiez que, globalement, l’industrie est en train de se déplacer d’un modèle de validation a posteriori pour valider qu’un produit correspond à ce qu’on voulait et, à la fin, pour poser un tampon “ça passe / ça ne passe pas”, à quelque chose qui est beaucoup plus diffus, où l’on va avoir cette responsabilité sur toute la chaîne, avec les phases d’idéation, de précision des specs, avec un maximum d’intervenants impliqués. Aujourd’hui, Deezer en est à peu près à quelle étape de ce shift ? Et est-ce que vous auriez des exemples de choses qu’on a pu faire ou qui sont mieux grâce à ce changement de paradigme ?

[00:29:48.140] — Virgile : Moi, j’ai vu des initiatives dont le développement n’a pas été lancé parce qu’il a été estimé trop compliqué. Même si la valeur utilisateur était là, il y avait des “no-go” de la part des équipes techniques par exemple — ce que je ne dis pas négativement évidemment. Typiquement, il n’y a pas eu de specs design trop poussées qui ont pris du temps, qui ont demandé à être estimées, etc. C’est vraiment encore plus en amont qu’on a eu ce retour des développeurs qui disaient : “ça, c’est inenvisageable”.

[00:30:15.450] — Loïc : Et qui prenait la décision ou qui a pris la décision “le rapport coût-bénéfice n’est pas intéressant”, et a dit “non” au final ?

[00:30:22.340] — Virgile : C’est à l’équipe Produit de faire ça.

[00:30:25.370] — Benmar : Au niveau de ce shift, de cette transition vers ce nouveau standard, ce nouveau modèle de ce que se veut une équipe qualité, chez Deezer, j’ai envie de dire qu’on n’en est encore qu’au tout début. On se pose encore beaucoup de questions. On participe à des meetups, à des conférences où on a des retours d’expériences. Du coup, ça nous rassure parce que la plupart des boîtes qui ont réussi à faire cette espèce de transition ont mis beaucoup d’années. Ce n’est pas un truc qui se fait du jour au lendemain, c’est une transition longue. D’ailleurs, en attendant que tout soit mis en place, tu ne peux pas te permettre de ne pas faire de validation en bout de chaîne, puisqu’on en dépend trop aujourd’hui. Donc il y a vraiment une double casquette à porter pendant un certain temps. Et dans cette évolution-là, un peu comme ce que disait Anthony, il y a des éléments importants à intégrer dans cette équipe de qualité : effectivement, des spécialistes sur des technos vont arrêter de faire du développement sur de la feature et porter une casquette de référent ou de superviseur architecte craftmanship — on voit le titre “craftmanship” qui circule beaucoup ces temps-ci, qui sont des cordes à ajouter à nos arcs d’équipe qualité sur lesquelles on n’y est pas du tout encore. Là, on reste plutôt sur des profils testeurs, QA Analysts ou QA Engineers-automaticiens. Et le shift ne peut pas être complet sans ajouter d’autres types d’éléments dans cette équipe qualité si l’on veut vraiment aboutir à cette transition.

[00:31:44.690] — Virgile : Après, ce shift-left n’est pas non plus nouveau. Peut-être qu’il est un peu plus extrême par rapport à avant, mais il y a eu tout un process de code review qui a été mis en place par exemple, qui est déjà un pré-test dans le sens où ce sont les développeurs de la même stack qui vont regarder le code et qui vont approuver ou invalider une pull request — donc une modification dans le code. Et ça, avant que la QA checke. Ça fait longtemps que ça a été mis en place chez Deezer — je crois que c’est depuis que je suis là au moins, ça fait donc au moins six ans. Donc ce shift-left avait déjà commencé. Et là, on le pousse encore plus loin.

[00:32:20.030] — Anthony : Oui, tout à fait. Il y a déjà du contrôle qualité sur le code aujourd’hui pour la plupart des stack techniques. On a aussi l’équipe SysOps au sein de Deezer qui a mis en place des archi reviews sur tous les nouveaux services qui arrivent chez Deezer, qui vont être créés. Ça aussi, c’est du contrôle qualité en amont. Donc ce sont potentiellement des initiatives d’équipe plus qu’un process global chez Deezer. Mais on a déjà, comme dit Virgile, des process de qualité en amont pour vérifier qu’on a un certain cahier des charges qualité, quand même, qui est validé. Après, je voudrais juste mettre un petit bémol à ce que tu disais Loïc : en effet, on a parlé d’un système un peu changeant en amont et autres, mais encore une fois, ça dépend énormément du contexte de l’entreprise. Si l’on a une entreprise qui livre, comme nous, tous les jours sur le web, où l’on essaie d’être vraiment très rapide dans notre vélocité, en effet, on ne peut pas être bottleneck à un endroit en disant “on teste à la fin”. Ce n’est pas possible. On a essayé, ça ne marche pas. Ou alors on ne scale pas et on est obligé de recruter à tire-larigot et ça ne fonctionne pas. Par contre, sur des entreprises qui ont des cycles de release de six mois voire un an — parce que ça existe ce genre d’entreprise — personnellement, je ne suis pas convaincu qu’il y ait vraiment besoin d’aller sur du shift-left et de l’amont. Je pense qu’on peut avoir une équipe de qualité en fin de chaîne qui, régulièrement, va regarder un petit peu où ça en est — parce que de toute façon, il va y avoir six mois / un an de développement pour fixer tous les problèmes. Voilà, je pense qu’il y a des sortes de guidelines, de choses qui vont dans le bon sens, mais qu’il n’y a pas une seule vérité. Mais un petit peu comme tout. Dans le développement, c’est la même chose, que ce soit en termes de choix de techno ou autre. Ça dépend du contexte des entreprises quand même.

[00:34:01.580] — Loïc : Mais du coup, le fait de livrer tous les six mois et de transitionner d’une livraison rare comme ça à une livraison quotidienne, voire de multiples fois par jour, est-ce que ce n’est pas justement aussi contribuer à ce process de qualité ? Parce qu’il est souvent admis qu’avec plus de livraisons, plus de fluidité dans les mises à jour de nos produits, vient, en vrai, plus de qualité. Souvent on met la rapidité de réaction face au changement et la rapidité de feedback, de retours, comme étant les vecteurs de cette qualité. Du coup, le fait que Deezer livre régulièrement et qu’une autre entreprise ne livre que tous les six mois, c’est, en soi, un problème qu’il faudrait peut-être résoudre — à partir du moment où c’est possible… Je ne suis pas en train de parler de livrer tous les jours des firmwares pour TGV ! Mais pour des produits web comme ça, qui n’ont pas des implications sur nos vies si importantes que ça — parce qu’un site de e-commerce ou d’écoute de musique, s’il ne fonctionne pas tout à fait optimalement pendant deux heures, ce n’est pas très grave.

[00:34:57.200] — Anthony : Oui, tout à fait, je pense que tu as raison. Tu as mis le point en parlant de sites comme SNCF par exemple pour TGV… Même si ce n’est pas vrai en réalité, ils ont des releases assez rapprochées et sont même très moteurs, par exemple, au niveau QA en termes de conférences pour montrer des choses qui fonctionnent, pour essayer de faire évoluer leur métier. Donc ce ne sont pas les moins bien lotis ! Par contre, ça dépend énormément des clients en effet, de l’utilisateur comme vous et moi. N’importe qui avec son application va avoir envie d’avoir un petit peu de changement, d’avoir des améliorations. Si l’on prend les banques par exemple, elles ne vont pas vouloir changer de firmware toutes les deux semaines ou avoir de nouvelles choses qui vont arriver. Les banques vont avoir besoin d’un truc très fiable qui ne bouge pas et, potentiellement, une livraison tous les six mois / un an avec des améliorations de performances tout en gardant une stabilité correcte, ça leur suffit. Donc c’est très dépendant, je pense, des besoins et des clients qui vont être détectés. Je prends un exemple tout bête mais on a eu des discussions chez Deezer là-dessus : faire une nouvelle application tous les jours sur iOS et Android, je ne suis pas sûr que ce soit une bonne façon de faire. On a envie d’avoir des modifications tout le temps sur le web. Sur mobile, nos clients n’ont peut-être pas forcément envie de faire des mises à jour tous les jours de leur app, qui vont prendre potentiellement du forfait mobile s’ils ne sont pas en wifi. Voilà, ce n’est pas forcément quelque chose qui est voulu par les clients d’avoir des nouveaux trucs tous les jours, toutes les deux heures. Alors que sur le web, en effet, on est plus sur : “dès qu’un truc est prêt, envoyez-le”.

[00:36:29.390] — Loïc : Il y a un sujet que l’on n’a pas du tout abordé : l’automatisation.

[00:36:33.800] — Vincent : J’imagine qu’effectivement, le fait de changer cette manière de penser, d’essayer de ramener la qualité plus en amont, fait que l’on ne va plus forcément faire beaucoup de tests à la fin. Et du coup, j’imagine que ces tests que l’on faisait, il faut bien faire en sorte qu’ils aient un équivalent. Donc effectivement, on va les automatiser. Du coup, j’imagine que c’est aussi un changement de métier pour les gens qui font de la QA à l’heure actuelle ?

[00:36:54.340] — Anthony : Personnellement, je pense que c’est un changement de métier pour tout le monde. Parce qu’en effet, pour les tests automatisés, on parle souvent de la QA. Dans pas mal de boîtes, la QA va créer les cas de tests. L’automatisation pure, le code pur, va être fait par des développeurs mais ensuite, les cas de tests vont être écrits, ou en amont, par la QA. Chez Deezer, par exemple, ce n’est pas le cas. On a formé en interne les QA pour qu’ils puissent faire du test automatisé, pour qu’ils puissent coder aussi — alors ils sont sur un software ou avec une librairie qui a été créée pour eux pour faciliter le travail aussi, pour ne pas leur demander trop de compétences techniques mais assez pour créer des tests automatisés. Mais en réalité, quand on parle de tests automatisés — on a parlé de tests unitaires, les développeurs font du test automatisé, et bien avant que la QA se mette à faire du test système sur de l’automatisation. En fait, c’est un changement de métier pour tout le monde parce que c’est juste une façon de voir le test automatisé, de le mettre dans une réalité de production différente qui a évolué depuis le moment où ça a été mis en place.

[00:37:49.210] — Vincent : Ce qui en plus impose — c’est plutôt la démarche qualité qui fait ça — aux développeurs de réfléchir à la testabilité de leur code, ce qui n’était pas le cas il y a encore une dizaine d’années — en tout cas, dans les stacks que j’ai pu voir dans les dix dernières années, c’est vrai que c’est quelque chose à laquelle on ne pensait pas. Et d’ailleurs, je me souviens qu’au tout début de Deezer — je ne pense pas trahir un secret en disant que très souvent on faisait le code et puis après, si on pouvait tester, on testait, sinon tant pis.

[00:38:13.330] — Loïc : Il y a aussi un truc, c’est que côté développeur, l’aspect qualité via les tests automatisés se limitait aux tests unitaires. Alors les tests unitaires, c’est bien, il faut les faire, etc. mais c’est souvent le développeur qui parle avec lui-même parce qu’il a besoin de tester que ce qu’il a écrit correspond à ce qu’il voulait déjà faire. Là où ça devient plus intéressant, c’est quand on commence à monter la pyramide et que ça devient plus compliqué : on arrive dans ces problèmes-là où on se dit “je ne sais pas faire” ou “on n’a pas l’habitude” et du coup, c’est rarement fait — même si c’est fait de plus en plus maintenant, mais avec un peu de peine et un peu de découverte, ce qui fait que ça prend un peu plus de temps.

[00:38:49.100] — Anthony : Oui et en plus, je pense que c’est encore plus vrai dans les stacks techniques qui ont énormément de bagage où, quand on essaie rien que de monter sur du test d’intégration, on se rend compte qu’en fait, il nous faudrait une centaine de mocks et de stubs pour réussir à faire fonctionner un test parce que tout est dépendant. Donc on en revient à ce qu’on disait sur le test de spec technique : c’est justement aussi pour parler plus de modularisation et avoir du code indépendant qui permette de plus facilement tester son intégration dans une application plus grosse.

[00:39:18.820] — Virgile : Pour faire écho au début de notre discussion, je parlais d’entreprises qui n’ont pas d’équipe QA, ça passe entièrement par l’automatisation des tests. Donc clairement, c’est une solution. Je ne dis pas que c’est une solution pour se débarrasser de l’équipe QA, mais l’équipe QA aujourd’hui chez Deezer est là en tant que chef de projet qualité, en tant qu’évangéliste. Mais l’automatisation, c’est la solution pour plus tard, ça c’est sûr.

[00:39:41.670] — Vincent : D’autant que j’imagine que les tests qu’une équipe qualité peut continuer de faire après l’automatisation, ça va être aussi du test exploratoire, peut-être aller chercher les choses auxquelles on n’a pas forcément pensé et se dire : “ok, toutes les specs ont été backées, maintenant, est-ce que l’on a des cas à la limite auxquels on n’a pas pensé ?”

[00:39:58.690] — Virgile : Exactement. Et c’est là la valeur d’une équipe QA comme on a chez Deezer. C’est l’exploratoire. C’est sortir un peu des sentiers battus, aller chercher les edge cases, etc. L’automatisation sert aussi à ne pas revenir sur des tests qu’on a déjà faits, ce qui est un peu une tannée si l’on peut dire — c’est LA grosse tannée des QA Analysts chez Deezer. Mais les tests exploratoires ont une énorme valeur aujourd’hui chez Deezer en tout cas.

[00:40:21.520] — Benmar : Si l’on peut faire une séparation, c’est un peu tout ce qui est tâches de régression par nouvelle version, tests de non-régression. C’est clairement une mauvaise utilisation des ressources et de l’expertise de l’équipe qualité. En soi, c’est un peu un travail redondant qui, en plus, peut finir par biaiser l’analyse parce qu’on cherche souvent le cas passant. Je pense que c’est clairement un travail à dédier à des machines. Chez Deezer, on a fait le choix que cette responsabilité, en tout cas pour l’instant, demeure dans l’équipe QA. On a fait monter en compétence les QA Analysts pour qu’ils soient autonomes sur cette création-là et sur cette passation-transition de faire tous ces tests de non-régression manuellement à les automatiser eux-mêmes, en compagnie de l’expertise de l’équipe d’Anthony justement. Ça pourrait effectivement être sous-traité ailleurs, même par d’autres boîtes ou chez les développeurs, ou en tout cas des équipes dédiées à l’automatisation. Mais en fait, si on ne se débarrasse pas de ces vérifications de non-régression de manière manuelle, on n’arrive justement pas à faire du shift-left et apporter cette expertise sur du test exploratoire.

[00:41:30.040] — Anthony : Exactement. Les tests automatiques, comme les tests manuels, ne sont qu’un outil pour faire du contrôle qualité. Et du coup, il faut trouver les bons outils qui permettent d’être le plus efficace et de pouvoir produire comme sont les recommandations de chez Deezer : on veut produire rapidement donc on a besoin d’avoir les meilleurs outils, les outils les plus performants. Et comme disaient Virgile et Benmar, s’il n’y a pas d’intelligence derrière un test, autant le remplacer par un robot et laisser l’intelligence faire son travail.

[00:41:57.630] — Vincent : Je pense que c’est une très belle phrase sur laquelle on va pouvoir conclure cette discussion. Merci beaucoup à tous les trois pour tous les insights que vous nous avez donnés. En tout cas, c’était très intéressant, encore une fois. On va terminer l’épisode avec les coups de cœur que vous aurez envie de partager avec les auditeurs.

[00:42:22.620] — Loïc : On va commencer par Benmar.

[00:42:25.020] — Benmar : Il faut en partager combien ? Un, deux, trois, … ?

[00:42:27.780] — Loïc : C’est 42, je crois, le standard.

[00:42:29.940] — Benmar : 42 ?!

[00:42:31.260] — Virgile : Je n’en ai préparé que 40…

[00:42:33.050] — Loïc : Eh bien, dépêche-toi d’en trouver deux autres.

[00:42:36.120] — Benmar : Alors, mes coups de cœur depuis que je suis arrivé en France — parce qu’il faut savoir que je suis Québécois à l’origine. Bon, les gens ne vont pas découvrir grand chose en France avec moi mais Lomepal et Orelsan sont vraiment mes coups de cœur français depuis que j’écoute plus de musique française. Par contre, j’ai quand même envie de faire découvrir des artistes de chez moi, entre autres Loud, un rappeur. Donc “Loud”, comme le son très fort en anglais, L-O-U-D. Il y a David Giguère que j’aime beaucoup et Peter Peter que je recommande à tout le monde.

[00:43:05.270] — Vincent : Cool. Virgile ?

[00:43:07.500] — Virgile : Oui, moi, je suis en grosse phase de découverte de nouvelles musiques en ce moment. Moi, je me suis mis à la batterie au confinement — mes voisins étaient très heureux. Et du coup, j’ai pas mal geeké sur des batteurs et j’ai découvert un mec qui s’appelle Louis Cole, que j’adore. Pour ceux qui connaissent un peu Vulfpeck, il a pas mal joué avec eux. Je vous conseille une chanson qui s’appelle “When You’re Ugly” qui décrit comment s’en sortir dans la vie quand on est moche. C’est très drôle !

[00:43:34.330] — Loïc : Nice !

[00:43:36.380] — Vincent : Et Anthony ?

[00:43:38.330] — Anthony : Si vous aimez la batterie et la double pédale, je conseille des bons groupes de power comme Powerwolf, qui est un groupe allemand avec des sons un petit peu d’église au synthé et les paroles sont assez marrantes. Et sinon, en pop-rock un peu moins connu en France, il y a un groupe qui s’appelle Feeder, que je suis depuis mes années collège et que je trouve absolument extraordinaire. Moi, j’adore en tout cas ! Donc “Feeder”, F-E-E-D-E-R. À ne pas confondre avec ceux qui jouent mal à League of Legends !

[00:44:12.410] — Vincent : Ok !

[00:44:12.860] — Loïc : Merci beaucoup !

[00:44:14.120] — Benmar : Je réalise juste qu’on manque un peu de diversité, de femmes, dans cette liste de recommandations, donc j’en profite pour faire une nouvelle reco. Du coup, c’est une femme québécoise aussi qui s’appelle Charlotte Cardin. Elle commence à être plutôt connue à l’international. Je recommande entre autres sa chanson “Main Girl”. Vous allez adorer !

[00:44:30.500] — Vincent : Cool ! Je pense qu’on mettra tous les liens avec l’article sur deezer.io qui accompagnera ce podcast. Encore une fois, merci à tous ! C’était super ! Moi, j’ai passé un très bon moment. Je ne sais pas, vous ?

[00:44:42.050] — Anthony : Oui, c’était très bien.

[00:44:43.071] — Virgile : Avec grand plaisir, merci à vous !

[00:44:43.080] — Loïc : Merci beaucoup !

[00:44:44.930] — Vincent : Un grand merci également à Pauline, sans qui ce serait très compliqué de faire ses émissions. Elle fait un gros boulot en amont. Et puis voilà ! On se revoit bientôt. D’ici là, ne pétez ni les plombs, ni les crons. Salut !

[00:44:58.220] — Loïc : Bye bye !

[00:44:58.460] — Benmar : Merci !

[00:44:59.090] — Virgile : Ciao tout le monde !

Références

À propos du podcast

Deez is la tech propose d’aborder des sujets relatifs aux mondes du streaming musical et de la “tech” au sens large (incluant développement, produit, design, qualité, data, recherche, etc.), et d’explorer les coulisses de certaines des fonctionnalités phares de Deezer. Le tout à l’occasion de discussions entre collègues et pairs, en toute décontraction, mêlant partage d’expériences, bonnes pratiques et réflexions sur les évolutions possibles du secteur.

Un nouvel épisode est publié le premier mercredi de chaque mois (ou un mois sur deux, en fonction de notre bande passante !) sur de nombreuses plateformes d’écoute et un transcript est mis à disposition en parallèle sur notre blog deezer.io.