Avenir du test

Les spécialistes du test dans le monde de demain: Julien Mer

Bonjour, peux-tu rapidement te présenter ?

Je m’appelle Julien Mer, je suis architecte QA et consultant indépendant. J’ai commencé dans l’informatique il y a environ 26 ans, bien avant d’avoir « QA » sur une fiche de poste. Administration système, environnements industriels, validation, management : j’ai connu plusieurs endroits où l’on découvre assez vite la différence entre ce qui est prévu et ce qui fonctionne.

Aujourd’hui, je travaille sur la stratégie de test, l’automatisation, l’architecture et la formation. Je maintiens aussi OculiX, la continuation open source de SikuliX, un outil d’automatisation par reconnaissance visuelle.

J’aime comprendre les mécanismes. Quand une explication ne tient pas, je vais regarder le code. Et quand on m’annonce qu’une chose est impossible, j’aime bien vérifier sur quoi repose l’affirmation.

Qu’est-ce qui t’a amené à travailler dans le domaine du test et de la qualité ?

Le terrain. Quand tu administres des systèmes, que tu gères des sauvegardes ou que tu travailles sur des équipements industriels, tu apprends que « l’opération s’est terminée sans erreur » ne répond pas à toutes les questions. Ta sauvegarde est verte ? Très bien. Maintenant, restaure.

Cette exigence m’a suivi dans la validation puis dans la qualité logicielle. Je veux savoir ce qu’on a réellement vérifié pour affirmer que ça fonctionne. Avec quelles données, dans quelles conditions, et ce qu’on n’a pas couvert.

C’est ce qui m’intéresse dans ce métier. On peut avoir une procédure impeccable, un rapport propre et un système qui ne rend pas le service attendu. À un moment, il faut aller regarder le système.

Comment fais-tu ta veille technologique ?

Je lis des publications, je suis des projets open source, je regarde ce que font les autres et j’échange. Mais je passe surtout beaucoup de temps à essayer. Une annonce me donne une piste ; elle ne me donne pas un résultat.

Quand un outil promet quelque chose, je monte un cas, je regarde son comportement et je mesure ce qui m’intéresse. Quand le code est disponible, je vais le lire. Et si le résultat contredit mon idée de départ, c’est mon idée qu’il faut revoir.

J’utilise aussi l’IA tous les jours, notamment pour développer, explorer et confronter des explications. J’en tire un bénéfice réel. Mais une réponse bien formulée reste une réponse à vérifier. Faire répéter la même chose à trois modèles ne transforme pas une hypothèse en preuve.

Quels sont les principaux changements dont tu as été témoin depuis que tu travailles dans le test et la qualité ?

Les cycles de livraison ont raccourci. Le test s’est rapproché du développement, l’automatisation a pris davantage de place et les frontières entre les métiers se sont déplacées. Pour comprendre un incident, il faut parfois suivre le problème de l’interface jusqu’à l’infrastructure. La fiche de poste ne suffit pas à décider où l’on s’arrête.

Les outils permettent aussi de produire beaucoup plus vite. Avec l’IA, cette accélération touche maintenant le code, l’analyse et la documentation. Je l’utilise moi-même, je ne vais donc pas prétendre que le gain est imaginaire.

Mais on confond encore trop facilement le volume produit avec la qualité obtenue. Mille tests construits sur une mauvaise compréhension du besoin ne corrigent pas cette compréhension. Ils peuvent même la rendre plus difficile à remettre en cause, parce que tout le tableau de bord est vert.

Il y a actuellement énormément de changements dans l’industrie logicielle. Quels sont, selon toi, les deux qui impacteront le plus le métier d’ici cinq ans ?

Le premier, c’est la prise en charge d’une partie de nos activités par l’IA. Écrire du code, préparer des tests, analyser un incident, produire une documentation : plusieurs métiers sont concernés, parfois dans le même workflow. Dire que l’IA ne remplacera personne et qu’elle sera seulement un assistant, c’est une promesse que je ne ferais pas. Quand des activités demandent moins de travail humain, ça peut changer les effectifs et l’organisation.

Le deuxième, c’est l’élargissement du périmètre sur lequel une personne pourra intervenir. Avec les outils, on peut déjà aller plus loin dans l’analyse et la réalisation. Encore faut-il comprendre ce qu’on leur fait faire et reconnaître quand le résultat est mauvais.

Pour un spécialiste du test, savoir exécuter un scénario ne suffira pas toujours.

Si ton activité se limite à suivre une procédure et à cocher le résultat prévu, oui, elle est fortement automatisable. Ce qui demande de l’expertise, c’est aussi de voir que la procédure est mauvaise, que le résultat attendu est faux ou qu’on a complètement oublié son risque et son fonctionnement. Lire le code de l’application, par exemple, permet de vérifier des hypothèses qu’on passerait beaucoup de temps à discuter autrement. Tout le monde n’a pas besoin de devenir développeur, mais on ne peut pas faire de l’incompréhension technique une protection du métier.

Quelles sont, pour toi, les meilleures transformations à venir pour les spécialistes du test d’ici dix ans ?

Pouvoir aller au bout d’une idée sans que le coût de réalisation l’enterre avant même le premier essai. Un outil pour reproduire un incident, préparer des données ou explorer un comportement particulier : beaucoup de choses deviennent plus accessibles.

J’y vois une possibilité de pousser les investigations plus loin. Aujourd’hui, combien de vérifications laisse-t-on de côté parce que leur préparation prend trop de temps ? Si on réduit cette charge, on peut examiner des situations qu’on n’aurait jamais eu les moyens de couvrir.

Ça ouvre aussi des possibilités aux personnes qui connaissent très bien un métier sans maîtriser toute la technique. Mais il faut qu’elles puissent examiner le résultat et le remettre en question. Leur donner un outil qui répond avec assurance sans leur permettre de contrôler ce qu’il fait, ce serait déplacer le problème.

Quelles sont, pour toi, les transformations les plus inquiétantes à venir pour les spécialistes du test d’ici dix ans ?

Le faux sentiment de maîtrise. Du code propre, des tests verts, un rapport convaincant : tout peut donner l’impression que le travail est terminé alors qu’on a validé la mauvaise chose.

Si une IA interprète le besoin, produit le code puis écrit les tests à partir de cette même interprétation, elle peut reproduire la même erreur sur toute la chaîne. Le fait que les éléments soient cohérents entre eux ne prouve pas qu’ils correspondent à la demande. Il faut une référence qui permette de contester le résultat.

Je m’inquiète aussi de la formation des débutants. Si les tâches qui permettaient d’apprendre sont automatisées, il faut organiser d’autres façons d’acquérir de l’expérience. On ne peut pas supprimer les occasions d’apprendre puis se plaindre de ne plus trouver de profils expérimentés.

Enfin, certaines activités pourront demander moins de monde. Je ne sais pas dans quelles proportions, et je ne vais pas inventer un chiffre. Mais rassurer tout le monde en affirmant que chaque poste sera préservé n’aide personne à se préparer.

Au final, comment vois-tu les métiers du test d’ici dix ans ?

Je pense que les frontières vont continuer à bouger. Une partie du test sera intégrée aux outils et aux activités des autres membres de l’équipe. Il restera des spécialisations, notamment sur les systèmes complexes et les domaines où les conséquences d’une erreur sont lourdes.

Je ne crois pas qu’on puisse défendre un métier simplement parce qu’il existe aujourd’hui. Il faudra pouvoir expliquer ce qu’on apporte : quelles erreurs on permet de voir, quelles décisions on éclaire, quels risques on aide à maîtriser. Le titre sur la fiche de poste ne le démontre pas.

Dans ma pratique, j’utilise l’IA pour comprendre et construire. Mais je garde des contrôles dont je peux examiner les règles, les résultats et les traces. Si un test passe, je veux savoir pourquoi. Et si l’outil modifie ce test pour le faire passer, je veux savoir ce qu’il a changé et qui l’a autorisé.

Dans dix ans, les outils auront changé. La question restera : qu’est-ce qui nous permet d’affirmer que le système fait bien ce qu’on lui a demandé ? Tant qu’on aura besoin d’une réponse sérieuse, il y aura du travail. Ça ne garantit pas que ce seront les mêmes postes, ni les mêmes compétences.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

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

Automatisation

Webinaire: Tester avec un robot ? Oui, mais pourquoi ? – 03 mai 2021

Retrouvez le webinaire de la taverne sur l’automatisation des tests avec un robot. De nombreux sujets sont abordés comme: La complémentarité des tests avec les solutions usuelles et les tests avec un robot mécanique Une présentation du robot, de son fonctionnement et de ses applications Un retour d’expérience Une démo

Lire la suite »
Agilité

Livre CFTL – Le rôle des testeurs dans les projets/équipes agiles

Avec l’agilité, le cycle de développement est bouleversé. Le logiciel n’est plus livré en une fois mais en de multiples versions embarquant chacune une ou plusieurs nouvelles fonctionnalités. Les tests se font donc à tout moment du projet, il n’y a plus de « période » spécifique dédiée aux tests ou à

Lire la suite »
sur-test vs sur-qualité
Qualité

Duel: sur-test vs sur-qualité

Intro Si vous êtes dans le test, et plus généralement dans l’industrie logicielle vous avez sûrement entendu parler de « sur-qualité ». Ce mot fait peur, surtout parmi les dirigeants, il faut surtout ne pas faire de sur-qualité! L’argument « éviter sur-qualité » est principalement utilisé lorsque l’on parle de test. Dès que quelqu’un

Lire la suite »