Bonjour, qui êtes-vous, quel est votre métier et quelles sont vos activités professionnelles ?
Marcelo Kamenetz Szwarcbarg, KS pour les intimes.
Je suis actuellement ingénieur de tests logiciel pour Amadeus et mes activités professionnelles sont centrées sur la qualité logiciel.
Je m’occupe de la qualification de produits en phase de « End to End », de bout à bout, avec la rédaction et l’exécution de cas de tests, la création et la communication des rapports de tests, la création et le suivit de rapports d’anomalies et d’évolutions, la préparation de café pré et pos-lecture de spécifications ainsi que de l’évaluation de risques.
Pouvez-vous décrire simplement votre métier ?
Je suis le gars qui va vous dire si le pont va s’effondrer et comment il s’effondrera.
En résumé, je vérifie que le produit logiciel fonctionne comme il est attendu ; ce juste avant de vous le remettre. En prime, s’il y a des choses qui ne vont pas, je vous le ferais savoir avec précision ainsi que ses conséquences et ses probabilités d’arriver.
Selon vous quel est le but de votre métier ?
Être détesté par les personnes qui veulent juste délivrer et se délivrer des projets ?
Avec plus de sérieux, le but de mon métier est de donner une bonne visibilité sur ce que fait le produit, que ce soit attendu ou non. Comme précisé précédemment, mon job est de fournir le maximum de détails sur ce qui fonctionne et sur ce qui ne fonctionne pas, ainsi que du comment.
Le métier d’ingénieur de test est central, surtout dans la phase de tests dans lequel j’agis. Nous ne vérifions pas uniquement un produit, mais une intégration dans des contextes clients particuliers, le tout au pluriel.
Que conseillez-vous pour atteindre ce but ?
Selon moi, il y a certaines questions qui se doivent d’être posées en toutes circonstances : le QQQCP
QUI, QUAND, QUOI, COMMENT, POURQUOI
En addition, on doit se dire « Et si je… ? », comme par exemple : « Et si je le fais quand même ? »
Deux autres points importants : ANALYSER et COMMUNIQUER.
Trouver des incohérences ou des anomalies n’est qu’une partie du travail. Il ne suffit pas de savoir que ça ne va pas, mais il faut préciser comment ça ne va pas et savoir pourquoi, quel est l’impact, la probabilité que ça arrive, quand la réparation est-elle attendue et qui sont les points de contacts impliqués dans l’anomalie.
Une fois toutes ces informations en main, il est indispensable d’en faire part à toutes les personnes impliquées dans les projets qui peuvent ou sont être impactés par le souci détecté. Sinon, autant jeter votre travail à la poubelle et se dire que l’on a mérité 3 ans de vacances dès que vous rencontrez un souci.
Qu’est-ce qui vous plait le plus dans votre métier ?
Soyons cash : le coté pécunier. On est plutôt à l’aise entre notre part de responsabilité et notre part d’intérêts et de reconnaissance en termes de salaires et bonus.
J’apprécie également d’être comme un filet de sauvetage pour les développeurs. Trouver les problèmes et les communiquer aux développeurs pour qu’ils délivrent le meilleur de ce qu’ils savent faire ; c’est assez gratifiant.
Finalement, ayant toujours un côté curieux et aimer expérimenter, j’apprécie pouvoir découvrir un outil en l’utilisant. Rappelons que la différence entre la science et faire n’importe quoi c’est qu’en science nous notons ce que l’on fait et les résultats obtenus. C’est un peu pareil entre expérimenter et tester. J’aime bien me jeter dans des tests exploratoires ou dans du « chaos testing » et mettre à l’épreuve un outil en cliquant un peu partout.
Quels conseils donneriez-vous à des débutants ou des personnes tentées par votre métier ?
LISEZ LA DOC
Tester n’est pas uniquement se baser sur son expérience ou sur un ressentiment. Imprégnez-vous des besoins et des spécifications offertes par le client et votre équipe. Comprenez les objectifs du produit. Comme disent les professeurs d’informatique : RTFM, Read The F**king Manual.
SUIVEZ VOS ANOMALIES
C’est bien de remonter un souci. Mais ne laissez pas ce dernier vivre, soyez cet inspecteur de police de série américaine qui ne lâche pas l’affaire tant que le dossier n’est pas clos. Nous ne parlons pas de pousser à résoudre tout soucis rapidement, mais de savoir tout sur le souci, y compris sa date prévisionnelle de fin, et de retester le scenario à sa fin.
« Je ne sais pas quelle anomalie vous êtes. Je ne sais pas ce que vous voulez. Si c’est un problème de production que vous espérez, dites-vous bien que je n’ai pas fait ma clôture de compagne de tests, par contre ce que j’ai, c’est des campagnes de non régression particulières, que j’ai acquises au cours d’une longue analyse avec les analystes de besoins clients. Des tests qui font de moi un véritable cauchemar pour vous. Si vous êtes réparé par des développeurs maintenant, ça s’arrêtera là. Si vous ne diminuez pas votre sévérité, je vous chercherai vos logs, je les trouverai et je vous communique aux équipes concernées. »
- Moi après avoir trop vu de séries la soirée précédant à l’ouverture du ticket pour suivre une anomalie.
OSEZ
N’hésitez pas à proposer aux équipes des améliorations en termes d’expérience utilisateur. Un testeur teste des cas d’utilisation, vous êtes un utilisateur !
Faire partie du projet vous donne la possibilité de participer à son amélioration, ne perdez pas cette occasion. Vous êtes un ingénieur et non que testeur : INNOVEZ ! Ceci est aussi applicable sur les méthodes et outils de tests utilisés. Dans ingénieur, il y a génie (et ‘’in’’, qui est privatif…).
Pouvez-vous nous donner une expérience/anecdote marquante ainsi que ce qu’elle vous a apporté ?
Non.
Allez, vous m’avez l’air intéressé pour en être arrivé à cette partie de l’interview, je vais vous faire part d’une expérience amusante : ma première anomalie qui est devenue une fonctionnalité.
Pendant mes études d’informatique, j’ai eu l’occasion de participer dans de nombreux projets. Ici, il s’agissait d’un portail de vente en ligne simple avec le minimum de fonctionnalités.
Bon à savoir : je développe comme un dieu : Bacchus après une fête trop arrosée. Avec astuce et recul, mon équipe et moi-même avions décidé que ma collaboration sera plus appréciée sur les documentations et les tests. Pratique, vu que le testeur doit comprendre le produit, autant le mettre à le décrire si l’équipe est trop petite.
Parmi mes tests, je vérifiais que les données d’un utilisateur ne pouvaient pas être accessible par un autre utilisateur. Et vous devinez l’anomalie trouvé : il y avait bien un moyen, peu commun, de récupérer les informations d’achats et la liste de produits désiré. Il suffisait d’une manipulation SQL pour arriver à ses fins.
Et là, l’épiphanie s’offrit à notre équipe : et si l’on permettait le partage des listes de souhaits, dans le cadre où l’utilisateur l’autorise ?
Et ainsi, après discussions et planifications, nous avons ajouté cette fonctionnalité au produit. Par manque de temps, nous n’avons pas corrigé complètement le problème et nous l’avons communiqué au jury du projet d’une façon originale : c’est un développement non terminé d’une fonctionnalité que nous proposons.
La morale de mon histoire : une anomalie peut être une opportunité si l’on ne se limite pas à dire : un test en erreur est un bug. Il peut être une évolution.
Quel est le cliché ou l’idée reçue de votre métier qui vous énerve le plus ? Pourquoi ?
Un ingénieur en qualité ne fait que des tests.
Pour citer Julien Lepers : Alors là, c’est non.
Notre métier n’est pas que tester, mais aussi construire des stratégies pour assurer la qualité, partager des avis sur les documentations et les fonctionnalités, innover avec les développeurs et analystes du besoin client. Mais aussi de faire le projet progresser, de le suivre. Et en plus, je considère faire un très bon café.
Je me refuse d’être réduit qu’à une tache en tant qu’ingénieur, c’est pour cela que le clicher m’énerve particulièrement.
Quel est le cliché ou l’idée reçue qui vous fait le plus sourire ? Pourquoi ?
Les collègues qui testent sont ceux qui retardent le projet.
Bah… oui. Ecrire des documents ça prend aussi du temps. Et faire un code commenter, oh là là, que de temps consommé. Le client ne veut que l’outils après tout.
A travers mon cynisme, vous aurez compris mon point : techniquement, tout peut retarder le projet. Mais considérer que, parce que la dernière tâche avant la livraison au client se termine plus tard que prévu est la raison du retard projet, c’est un raccourci un peu trop simple.
Gardez un œil sur l’évolution du produit au lieu de regarder que la date de fin, c’est ainsi que l’on détecte ce qui consomme le plus de temps.
En prime, mesurez bien les besoins en termes de personnel, parfois un retard est dû à un problème de ressources. Un seul testeur sur un gros projet n’est pas toujours une bonne idée. Sentez mon regard s’appuyer sur certains éditeurs.
Quelle est la difficulté la plus fréquente à laquelle vous avez dû faire face dans votre métier tout au long de votre carrière ?
La barrière psychologique que les développeurs peuvent avoir. Quand on trouve une anomalie, on ne remet pas en cause les compétences du développeur, mais il arrive que ce dernier le prenne trop personnellement, dégradant la relation dans l’équipe. C’est normal vu que c’est une erreur dans le code.
Faire attention aux formulations afin de faire passer un message positif pour un problème est une difficulté récurrente dans mon métier, surtout où chaque individuel réagira différemment.
Nous pouvons dire donc que c’est le coté humain du travail qui sera la difficulté omniprésente tout au long de la carrière d’un ingénieur de tests.
Quelles sont les personnes qui vous inspirent le plus ?
Evidemment, les membres de ma famille qui ont été des modèles sur plusieurs domaines.
A eux réunis, ils sont le modèle de réussite en groupe, de collaboration, d’ingéniosité, de persévérance et d’intelligence.
De manière plus comique, tous les développeurs m’inspirent à leur façon.
Il n’y a pas d’erreur ridicule, mais j’avoue prendre du plaisir à trouver des petites anomalies drôles qui donne des idées de tests sur d’autre projets.
Pour donner un exemple : j’ai eu à tester une caisse de distributeur fictive. Encore aujourd’hui, quand je teste un payement, j’ai ce test du génie diabolique qui ne paye qu’en petite monnaie retiré de cette caisse virtuelle. Il y a également cet utilisateur qui remplace toutes les devises par du chocolat. Un jour, cette anomalie deviendra un besoin, qui sait… ?
Comment continuez-vous à apprendre ?
En faisant des erreurs aussi grosses que Bibendum, la mascotte de Michelin. Il y aura toujours des moments pour expérimenter, échouer, progresser.
Je suis également des formations pour évoluer sur des compétences diverses nécessaires dans mon travail. C’est très appréciable, toutes les compétences du métier ne sont pas que technique.
Et finalement, les sites tels que la taverne du testeur permettent de rester à jour sur les méthodes de tests et les outils possibles. Je rappelle que cet interview n’est pas sponsorisé. 🙂
Quel est l’outil qui vous semble indispensable pour exercer votre métier ?
Ma messagerie. On échange constamment dans mon métier.
Parmi tous les outils indispensables, je donne les honneurs à ma messagerie qui me permet de communique sur l’ensemble de mes analyses mais aussi de recevoir toutes les informations venant du développement ou du client.
Sans cet outil, j’aurais dû marcher des kilomètres, surtout quand le client ou le développement est fait dans un pays à l’autre bout du monde.
Quelles sont, selon vous les prochains challenges que votre métier devra affronter ?
Encore l’occasion de sortir ce merveilleux mot : un problème pécunier.
Je pense que dans un monde où on parle de bénéfices et de rentabilités, certaines économies seront à prévoir. Le challenge sera donc de tester toujours plus, mieux et pour moins cher.
Les solutions vont évidemment apparaitre, comme l’automatisation ou la création de méthodologies (coucou Agile). Mais, il faut les faire apparaitre ces solutions. Là est notre challenge : ne jamais cesser d’innover.
Avez-vous une devise ou tout autre chose qui vous semble importante dans votre métier ?
Délivrer ou ne pas délivrer, il n’y a pas de questions, que des résultats, des recommandations et une liste de problèmes détectés.
Ne vous faites pas d’idées, les testeurs n’ont pas le pouvoir absolu : le choix de délivrer est au niveau projet. Mais si votre liste est grande est de couleur rouge ou pourpre, le choix sera un peu plus biaisé. Les menaces de morts sur les rapports de tests sont à éviter pour des raisons évidentes.
Fait amusant : vous pouvez ajouter un smiley à vos rapports de tests. Plus il est heureux, moins il y a de risques pour le client. Ça permet d’aérer un peu ses rapports avec un indicateur visuel sympathique.
Souhaitez-vous ajouter quelque chose ?
Un grand merci à mes collègues d’Amadeus Hôtel pour la superbe collaboration qui continue de durer sur plusieurs années, ainsi qu’à mon équipe avec qui nous nous amusons en travaillant.
Je remercie également Marc HAGE CHAHINE, qui m’a un peu formé sur quelques outils, qui m’a proposé de belles opportunités et me permet de rester dans le coup en discutant des dernières innovations pour la qualité grâce à son groupe LinkedIn ‘’Le métier du test’’ et au site ‘’La taverne du testeur’’.
Et merci à vous pour votre lecture, j’espère que mon écriture plus légère vous a été agréable.
Interview inspirées des interviews du blog Lyon testing qui sont très intéressantes et que je vous conseille.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
