Interview d’un testeur #1 – Julien Blanc

Interview d’un testeur #1 – Julien Blanc

Nous débutons cette semaine une nouvelle série où nous avons décidé de donner la parole à des testeurs Français. Le premier à s’être pris au jeu en acceptant de répondre à nos questions est Julien Blanc, qui a commencé sa carrière chez BlaBlaCar et est actuellement QA Engineer chez Deezer, player de musique en streaming Français bien connu.

Laissons-lui tout de suite la parole.

Qui êtes-vous, que faites-vous, où travaillez-vous ?

Deezer

Je m’appelle Julien Blanc, j’ai 25 ans et je suis actuellement QA Engineer chez Deezer depuis un an et demi. L’équipe QA est constituée de 14 personnes (12 testeurs et 2 engineers). J’ai plusieurs missions au sein de Deezer :

  • Constituer 3 projets de tests automatiques (Web, iOS et Android), afin d’assurer une qualité minimale au quotidien. J’utilise aujourd’hui principalement Selenium pour le web et Appium pour les mobiles
  • Déployer ces projets sur des serveurs Jenkins et faire tourner les tests toutes les nuits sur tout le site et les applications mobiles, et des tests « vitaux » avant chaque mise en production
  • Formation aux testeurs au développement, pour leur permettre d’écrire leurs propres tests (l’écriture de scénario est vraiment facile)
  • Développement d’outils internes pour les testeurs, comme un site de gestion des devices, meilleure visualisation des tests de la nuit, etc..

Comment décririez-vous votre travail à un enfant de 6 ans ?

child

Il y a 3 types de personnes qui travaillent dans l’informatique : des gens qui construisent, des gens qui vont vérifier ce que les constructeurs ont construit, et ceux qui vont installer ce qui a été construit. Moi je fais partie de ceux qui vérifient que les constructeurs ont fait quelque chose de bien. Et pour ne pas toujours tester la même chose, je fabrique des robots qui vont tester à ma place.

Avec le recul, et si vous deviez redémarrer votre carrière de testeur, quels conseils donneriez-vous ?

robot

Si je devais recommencer ma carrière, j’orienterais plus la qualité vers l’automatisation. Il est vrai que je dis ça car je travaille dans l’automatisation aujourd’hui, mais lorsque j’ai mis en place des process au sein de BlaBlaCar, j’étais très orienté tests manuels. Au final, avec le recul, je suis devenu une personne « feignante »; je n’aime pas faire plusieurs fois la même chose. Je perdais beaucoup de temps au début à toujours tester les mêmes fonctionnalités, faire de la non-régression… C’est une fois avoir mis un pied dans l’automatisation que j’ai pris conscience à quel point ça pouvait me faire gagner du temps. Et c’est aujourd’hui ce que j’essaye de pousser le plus auprès des testeurs : laissez moi automatiser tout ce qui est possible, comme ça vous êtes libre de seulement tester ce qui est important.

Racontez-nous une anecdote de votre vie de testeur (bon ou mauvais moment, bug incroyablement dur à reproduire ou analyser…)

phone

J’ai une anecdote « fun » : je testais une fonctionnalité qui venait de sortir en Allemagne utilisant un numéro de téléphone. En France, les numéros de téléphones génériques ne sont pas attribués, comme par exemple 0600000000. J’ai donc utilisé un numéro de téléphone similaire avec le préfixe allemand +49 pour tester ma fonctionnalité. J’ai même commencé à automatiser le test à l’époque. Une semaine après, nous avons reçu un mail de l’avocat de la personne en Allemagne qui utilisait ce numéro de téléphone.. Oups 🙂

Qu’est-ce qui vous énerve le plus dans les fausses idées qu’on se fait sur le test ?

quality

Ce qui m’énerve le plus dans les fausses idées qu’on se fait sur le test est l’image de la QA pour la majorité des développeurs que j’ai rencontré. J’ai la chance d’avoir travaillé avec des personnes « matures », mais je trouve que la QA a une image d’infériorité dans le développement logiciel. Certains développeurs ne vont pas avoir une certaine aptitude aux tests, considérant cette partie comme étant presque inutile. De ce fait, certaines entreprises ne considèrent clairement pas la QA comme une priorité, créant trop souvent un produit de mauvaise qualité (d’ailleurs certains des exemples que j’ai en tête ont complètement changé d’avis après avoir embauché leur premier testeur).

C’est dommage car j’ai eu la chance de travailler avec des américains et des anglais, et j’ai remarqué que ces pays sont beaucoup plus matures quant à la QA, impliquant la qualité dès le début de la construction d’un produit, et ayant une estime des testeurs aussi haute que les développeurs.

Quels sont les challenges que vous avez à affronter en tant que testeur au sein d’une équipe produit logiciel ? Et comment les surmontez-vous ?

Je ne suis plus testeur personnellement actuellement, j’ai une vision un peu différente, mais au final le challenge principal est le même : faire prendre conscience de l’intérêt de la QA. Lorsque je dis ça, je pense particulièrement au Product Manager ou aux commerciaux, qui n’ont pas forcément conscience du travail qu’est le notre. Et je les comprends, je n’ai pas conscience non plus pleinement de leur travail. La difficulté est alors de prendre des décisions de priorité, comme par exemple si on doit déployer une nouvelle fonctionnalité aujourd’hui car le plan de communication est lancé, mais que cette fonctionnalité a créé un bug; quelle décision devons-nous prendre ? Il est alors important d’expliquer l’intérêt de décaler le lancement dans la mesure du possible, et d’écouter les autres équipes pour connaître leurs priorités et ne pas forcément bloquer par principe.

Avez-vous des modèles, des personnes vous inspirant (testeurs ou pas) ?

churchill

Si je devais avoir un modèle dans le monde du test, je dirais James A. Whittaker, qui a entre autre écrit le livre How Google Tests Software qui explique très bien la complexité qu’a dû affronter Google dans leurs tests, et la vision qu’il a du futur qu’il évangélise au sein de Microsoft. Et si je devais avoir un modèle pas forcément testeur, ce serait Churchill pour la gouaille, Elon Musk pour son impact et les loutres parce qu’elles ont l’air d’être trop cool.

Comment continuez-vous à apprendre ?

hackaton

Étant très technique aujourd’hui, j’ai découvert une passion pour les hackathons et l’innovation. Je fais régulièrement des hackathons pour me stimuler et apprendre de nouveaux langages informatiques. Durant ces événements, mais aussi les conférences, je rencontre de nouvelles personnes, on échange sur nos expériences. Ce genre d’échanges est super important, ça permet de prendre du recul sans forcément se planter, ce qui peut faire gagner du temps. Mais c’est aussi important de se planter hein !

Citer un ou des outils qui vous sont devenus indispensables ?

stackoverflow

StackOverFlow sans hésiter, que ce soit pour trouver des réponses ou pour en donner.

Un des challenges que vous avez dû affronter pour tester une fonctionnalité particulière

geoloc

@BlaBlaCar : le challenge principal était la géolocalisation. En effet il y avait une fonctionnalité qui consistait aux utilisateurs de se retrouver sur un plan, le genre de chose pas forcément facile à simuler sur Android et encore moins sur iOS.

@Deezer : vérifier que la lecture d’une track soit bien enregistrée côté back. Pour automatiser ça, je dois faire des vérifications dans plusieurs endroits du site (front, web, mobile, back office, logs etc…).

A quelle révolution les testeurs doivent-ils se préparer ?

Je pense sincèrement que, du moins en France, nous sommes au début de la prise de conscience QA. Déjà techniquement, les principaux frameworks de tests automatiques (Selenium, Appium, Cucumber etc…) sont encore partiellement instables alors que ce sont les plus utilisés dans le monde. Ça montre un certain désintérêt général des développeurs en la matière quand on voit, en comparaison, le nombre de frameworks JS qui apparaissent chaque jour.

Mais cela commence à changer : durant la dernière conférence Selenium qui se tenait à Londres, j’ai pu échanger avec des QA devs de Facebook qui m’ont expliqué la vision QA tech de Facebook qui s’oriente vers l’automatisation avec un parc de devices. Google, Amazon (AWS) et Apple vont aussi dans ce sens actuellement.

Bref, l’automatisation devient un réel cœur dans le monde du développement, et les gros acteurs du Web investissent clairement là-dedans en ce moment.

En revanche, je ne pense pas que ce soit la fin du test manuel pour autant. L’automatisation va grandir en qualité, laissant alors aux testeurs le temps de se concentrer sur des tests recentrés seulement sur la fonctionnalité, sans perdre de temps avec de la non-régression. Je dis tout le temps « Les tests autos ne doivent pas remplacer, mais compléter les tests manuels ».


Merci Julien pour ces retours très intéressants. N’hésitez pas à réagir en commentaire si vous voulez continuer le débat sur un des sujets abordés. Nous aurons un autre invité dans les prochaines semaines, et si vous-même avez envie d’apparaître ici en répondant à ces questions, alors n’hésitez pas à postuler.

3 réactions au sujet de « Interview d’un testeur #1 – Julien Blanc »

  1. L’anecdote du numéro de téléphone me rappelle une de mes propres boulettes ^^

    Un jour, je devais développer un automate pour tester les changements de réservation pour un examen. Je le lance plusieurs fois en environnement de test… Puis, le lendemain, le support reçoit un mail : « Il y a eu une erreur, je veux passer mon examen à Paris, pas à Clermont-Ferrand… »

    Je savais bien que la base de données de l’environnement de test contenait des vraies adresses e-mail. Ce qui n’était indiqué nulle part, c’est que les changements de réservation généraient un envoi de mail automatique…

    Super idée cette série d’articles !

    1. Et surtout, quid de si ton environnement de test est câblé pour envoyer de vrais emails, il y a intérêt à surveiller la config! Chez nous, j’ai toujours l’impression d’avoir cet épée de Damoclès sur la tête ou, malgré les précautions prises, les tests de charge pourraient être lancés un jour avec une config valid d’envoi de SMS…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.