En-tête-canalplus
10 mai 2023

Testing Talks avec Isabel Evans

Mathilde Lelong
Blog > Agile
Testing Talks avec Isabel Evans

Testing Talks est une série d'interviews mettant en avant des personnalités du monde de la qualité et des tests de logiciels. Dans ce nouvel épisode, nous avons eu le plaisir de nous entretenir avec Isabel Evans.

Isabel Evans a plus de 30 ans d'expérience dans le secteur des technologies de l'information, principalement dans la gestion de la qualité, les essais, la formation et la documentation. Elle a surtout travaillé avec des clients des secteurs de la finance, des communications et des logiciels.

Pouvez-vous vous présenter et décrire votre parcours ?

Je m'appelle Isabel Evans. J'ai obtenu un diplôme d'informatique dans les années 70 et je travaille depuis les années 80 dans le domaine des tests de logiciels et de la qualité des logiciels, à différents postes. J'ai travaillé en tant qu'analyste de test, responsable de test et enfin en tant que responsable de la qualité, ce qui est un rôle légèrement différent. Il consiste à examiner les processus au sein d'une entreprise, pas seulement au niveau des logiciels, mais dans l'ensemble des activités de l'entreprise. J'ai également travaillé en tant que consultante dans différents domaines liés aux tests et à la qualité, et j'ai également enseigné dans ce domaine. Depuis 2017, je travaille en tant que chercheuse de troisième cycle à l'Université de Malte, où j'étudie les expériences des testeurs avec les outils qu'ils utilisent.

Qu'aimez-vous le plus dans votre travail ?

Je pense que c'est intéressant avec les tests de logiciels en particulier, parce que les gens pensent parfois que c'est un travail ennuyeux ; et je dirais que c'est l'inverse. (...) Il faut beaucoup réfléchir, c'est un travail très habile : on travaille très souvent sous pression, on résout constamment des problèmes et on est toujours à l'affût des risques. (...) Mais je pense que c'est ce qui m'a plu dans ce métier, c'est en particulier la résolution de problèmes, ou lorsqu'il y a des conflits entre les contraintes et les risques d'un projet. Par exemple, lorsqu'il y a des conflits entre les exigences des différentes parties prenantes, il faut trouver des moyens de gérer ces conflits et d'obtenir le meilleur résultat possible pour l'organisation et pour ses clients.

(...) Je dirais donc que c'est ce que j'ai le plus apprécié au cours des 40 dernières années, car on apprend toujours quelque chose, et cela s'est répercuté sur mes activités de recherches. J'étudie maintenant des méthodes de travail sur des sujets que je n'ai jamais eu à traiter auparavant. 

Que pensez-vous des équipes de test qui refusent de passer à l'automatisation ? Avez-vous des conseils à leur donner ?

Je pense que c'est une question très intéressante parce que l'automatisation n'est pas vraiment possible pour tous les tests. Je dirais cependant que de grandes parties des tests, même de l'exécution des tests, devraient être effectuées par une personne, le cerveau d'une personne, et qu'elles doivent être effectuées à grande vitesse. Parfois, aller aussi vite que possible - ce qui est l'une des raisons pour lesquelles les gens automatisent - n'est pas la meilleure façon de trouver les problèmes. De temps en temps, le fait de ralentir, de réfléchir très lentement, d'avancer et d'examiner les choses de manière critique est un meilleur moyen de comprendre ce qui se passe et de trouver les problèmes. Si j'avais une équipe qui refusait d'automatiser, je voudrais comprendre ses raisons. Très souvent, il y a de très bonnes raisons à cela. Il y a des aspects de ce qu'ils font qui ne peuvent pas être automatisés. Et même si vous automatisez une partie de l'exécution des tests, certains aspects de l'ensemble de l'activité de test doivent faire l'objet d'une analyse réfléchie. Prenons l'exemple de cette équipe, dont les responsables peuvent souhaiter l'automatisation des activités qui requièrent des capacités cognitives - puissance cérébrale ou réaction émotionnelle, comme certains tests. (...) Je dirais que si une équipe refusait d'utiliser tout outil, je lui montrerais comment les outils peuvent l'aider dans certaines tâches. Mais je ne pense pas que l'automatisation soit nécessairement un bon objectif en soi.

ChatGPT est le sujet de prédilection du moment. Que pensez-vous de son utilisation pour la création de tests ?

J'ai dû essayer Chat-GPT et je l'ai consulté pour voir ce que d'autres personnes en ont fait. Je pense qu'il s'agit d'un instrument un peu contondant. Personnellement, je ne l'utiliserais probablement pas pour créer des tests, parce que là où je l'ai vu utilisé, il me semble que vous obtenez des réponses qui sont plausiblement correctes, car elles sont très standardisées. (...)

Je ne suis pas sûre que ce soit quelque chose en quoi j'aurais confiance. Les personnes que j'ai vues l'utiliser avec succès, et pas seulement dans les tests de logiciels, sont des personnes qui savent suffisamment ce qu'elles attendent des résultats. Et ils passent suffisamment de temps à vérifier les résultats pour pouvoir faire la différence entre ce qui a fonctionné et ce qui n'a pas fonctionné. Je pense que le problème est qu'il faut probablement faire beaucoup de travail pour vérifier. 

Par exemple, j'ai récemment rédigé un rapport pour quelqu'un, qui comportait une analyse détaillée… La personne a passé une partie de mon rapport par ChatGPT pour obtenir un résumé. Mais en fait, lorsque j'ai vu le résumé et que je l'ai vérifié dans le rapport, il y avait un décalage. Il y avait des choses que j'avais trouvées dans le rapport qui n'étaient pas passées par le résumé ChatGPT, et il y avait des choses dans le résumé Chat-GPT qui étaient génériquement plausibles comme étant des choses dont j'aurais pu parler à la suite de l'analyse, mais qui en fait n'y étaient pas. (...) Le problème est que vous obtenez des résultats qui semblent plausibles. Mais en fait, la quantité de travail que vous devez faire pour tout vérifier est inutile.

L'erreur que j'ai commise dans ce contexte particulier est que j'aurais dû faire un résumé plus court, que j'aurais pu faire moi-même, et cela aurait été le bon résumé plus court - au lieu du mauvais. Je ne pense pas que nous en soyons encore là, mais je suis très préoccupée par le fait que les gens commencent à lui faire confiance et à l'utiliser de différentes manières.

Quels sont les principaux enseignements de votre article intitulé "Test tools : an illusion of usability" ?

C'est une bonne transition par rapport à la question précédente. Je pense qu'il y a des choses illusoires. Nous voyons des choses en surface qui proviennent des outils ou de la manière dont les outils se comportent, mais cela ne reflète pas nécessairement la réalité. Lorsque j'ai commencé mes recherches, je pensais qu'il y avait un problème avec la facilité d'utilisation des outils de test. Lorsque j'ai effectué mes recherches de manière rigoureuse et académique, j'ai commencé par demander aux gens non pas s'ils avaient un problème, mais quelles étaient leurs expériences. J'ai pris du recul.

Les résultats ont montré que les gens avaient eu de bonnes expériences et d'autres de moins bonnes, puis j'ai analysé ces données et l'une des choses qui est ressortie est que les gens avaient un problème avec la facilité d'utilisation des outils. Pour un grand nombre de testeurs qui m'ont fait part de leurs observations, les outils qu'ils devaient utiliser n'étaient pas suffisamment performants du point de vue de la convivialité. Mais si l'on creuse un peu plus, on s'aperçoit qu'il y a plusieurs raisons à cela. Certains de ces outils avaient en fait de très bonnes interfaces utilisateur - attrayantes, claires et apparemment faciles à utiliser - mais ils ne soutenaient pas correctement le flux de travail réel du testeur. L'utilisabilité avait été appliquée de manière très superficielle. (...) La facilité d'utilisation était une illusion. 

Une autre illusion de la facilité d'utilisation était qu'elle ne suffisait pas. Même si la facilité d'utilisation est bonne, elle n'est pas suffisante sans d'autres attributs de qualité et d'utilisation. L'une des choses que les gens ont signalées à maintes reprises, c'est qu'ils disposaient d'outils pour soutenir les tests qui n'étaient donc pas maintenables. Le logiciel testé change, donc tout ce qui se trouve dans l'outil de test doit changer. Et si les outils ne prennent pas en charge ce changement continu, ils deviennent inutilisables. Les gens se rendaient compte qu'ils achetaient un outil, qu'ils l'utilisaient pendant un certain temps, qu'il devenait inutilisable à cause des problèmes de maintenance, qu'ils passaient à un autre outil et qu'ils rencontraient les mêmes problèmes.

Je parle également des attributs techniques ou des attributs de qualité et d'utilisation, qui n'étaient pas non plus bien étayés. Certains testeurs ont signalé, par exemple, que l'outil posait des problèmes de sécurité. Non pas en termes d'insécurité parce qu'il laissait sortir des données, mais en termes d'insécurité parce qu'il ne permettait pas aux testeurs d'entrer. La sécurité d'accès à l'outil était telle qu'ils ne pouvaient pas faire le travail qu'ils voulaient faire. (...)

Il y avait des personnes qui n'étaient pas particulièrement techniques et qui trouvaient les outils trop difficiles à utiliser sur le plan technique, de sorte qu'elles n'étaient pas soutenues dans leur apprentissage initial. Il y avait aussi des personnes qui avaient des compétences techniques et qui se rendaient compte qu'elles ne pouvaient pas utiliser les outils d'une manière techniquement compétente parce que l'interface de l'outil ne leur permettait pas de le faire. Il n'y avait pas de place pour les différents types de personnes et il n'y avait pas de place pour la croissance au fur et à mesure que les personnes apprenaient leur métier, le domaine des logiciels et l'ensemble des outils.

Je pense qu'il serait vraiment formidable que les outils de test puissent soutenir les personnes dans leur développement personnel et dans les changements apportés au logiciel testé. Tels étaient les messages clés de cet article.

Pouvons-nous avoir un aperçu de votre prochain article ?

J'ai commencé à penser que la raison pour laquelle la facilité d'utilisation était traitée de manière superficielle était peut-être que les concepteurs d'outils d'essai n'avaient pas une compréhension claire des personnes qui effectuaient les essais. Et il m'est apparu clairement, à partir de ces premières données, qu'il y avait un plus grand nombre de personnes que ce à quoi je m'attendais, malgré toute mon expérience dans l'industrie. J'ai effectué une autre recherche sur les personnes qui effectuent des tests, une enquête à l'échelle de l'industrie auprès de 70 répondants sur eux-mêmes, leurs passe-temps, leur façon de travailler... Il s'avère que les personnes qui effectuent des tests sont très hétérogènes.

Si l'on examine les ensembles d'outils dont ces personnes vont avoir besoin, on constate que les besoins sont très divers. Même si la fonctionnalité sous-jacente est la même, elle s'adresse à différents types de personnes ayant des besoins différents, des objectifs différents à des stades différents, et venant d'horizons très hétéroclites. Je pense que c'est une idée intéressante pour les concepteurs d'outils. Je travaille sur ce sujet en ce moment, avec des documents en cours de rédaction et en cours de révision. J'essaie de trouver des heuristiques qui pourraient aider à guider les personnes qui conçoivent des outils de test. (...)

Il y a une richesse et une diversité de personnes, d'activités, de types de tests et d'objectifs... ce qui signifie que le simple fait d'utiliser le mot automatisation est trop mince. J'espère qu'une partie de ce travail débouchera sur un meilleur ensemble d'outils pour les testeurs, bien que nous en soyons encore loin. Il s'agit d'une idée de départ dans ce que je fais.

Pouvez-vous nous raconter une anecdote sur votre carrière en tant qu'intervenante ?

Je suis devenue conférencière par accident ! Je n'avais pas prévu de devenir intervenante lors de conférences, ni d'enseigner les tests. C'est arrivé presque par hasard, en cours de route. Je me souviens que je participais à une réunion d'un forum et que Dot Graham était présente. Je l'avais rencontrée à plusieurs reprises - il s'agissait d'une sorte de réunion d'un groupe d'intérêt spécial. Nous avions discuté de différentes choses au sein d'un groupe sur la qualité et les essais, et elle m'a dit : "Vous devriez venir faire un exposé". J'ai été très surpris, j'ai dit "Non, ce serait une idée ridicule"... Mais elle m'a persuadé.  

J'ai donné une conférence et cela s'est plutôt bien passé. J'ai simplement parlé du projet sur lequel je travaillais à l'époque. Les gens ont semblé apprécier. Dot m'a dit : "Vous devriez poser votre candidature pour parler à EuroSTAR". J'ai pensé que c'était une idée risible. Mais une fois de plus, elle m'a persuadée. J'ai posé ma candidature et j'ai été accepté. 

Je me souviens d'être allée à la conférence, d'avoir fait mon exposé et d'avoir été si excitée de participer à une grande conférence européenne. Encore une fois, les gens ont vraiment aimé mon exposé, et j'ai été très surprise parce que je me souviens que j'étais très nerveuse à l'avance. Je suis toujours très nerveuse avant de prendre la parole ou de faire quelque chose comme ça. (...) Je pense que le résultat final à ce stade, lorsque j'entends des personnes plus jeunes que moi parler de leurs projets, ma réponse est très souvent d'aller donner une conférence à ce sujet. Je pense que c'est la clé de l'art oratoire. Vous devez parler de votre propre histoire, de quelque chose que vous avez vraiment fait, parce que beaucoup d'autres personnes présentes à cette conférence seront confrontées à des défis similaires et apprécieront d'entendre parler des vôtres.

Je me souviens qu'à l'occasion d'une conférence particulière, j'avais réalisé un projet qui était pour moi le plus grand projet que j'avais jamais réalisé. On m'a demandé de faire un exposé à ce sujet. Le thème était "Les grands projets et la manière dont nous les gérons". J'ai fait mon exposé et j'ai expliqué à quel point cette tâche m'avait semblé immense. Pour moi, c'était vraiment énorme. Au cours d'un exposé, un testeur de systèmes centraux IBM s'est rendu compte qu'un grand projet n'est pas grand simplement parce qu'il s'agit du plus grand projet. Il s'agit plutôt du plus grand projet que vous avez réalisé jusqu'à présent. Quel que soit le défi auquel vous serez confronté dans ce secteur, vous aurez l'impression que c'est le plus grand projet que vous ayez jamais réalisé. N'oubliez pas cela lorsque vous participez à des conférences et partagez-le avec d'autres personnes qui pourraient avoir besoin de l'entendre. 

Votre dernier mot ?

Si je regarde en arrière, à 68 ans, je pense que l'élément clé est l'apprentissage tout au long de la vie. C'est absolument essentiel. Non seulement parce que le secteur change tout le temps, mais aussi parce que vous changez tout le temps. 

J'ai appris les choses que je devais savoir. Vous devez vous dire que dans cinq ans, dans dix ans, dans vingt ans, dans vingt-cinq ans... Vous ferez peut-être quelque chose de complètement différent. Et ce n'est pas grave. C'est en fait cette croissance et cet apprentissage constants qui sont si importants. Saisissez les opportunités qui se présentent à vous. Continuez à saisir les opportunités et faites essentiellement ce que vous voulez faire, parce que vous n'avez qu'une seule vie. Alors profitez-en.

Vous voulez essayer Agilitest ?

Découvrez Agilitest en action. Divisez par 5 le temps nécessaire à la sortie d'une nouvelle version.

Automatiser les tests fonctionnels pour des équipes heureuses.  

  • Des tests manuels aux tests automatisés
  • De l'automatisation des tests à l'automatisation intelligente des tests
  • Trouver les bons outils
ebook-scaling-test-automation-agilitest
Mathilde Lelong

A propos de l'auteur

Mathilde Lelong

Mathilde est Content & Community Manager chez Agilitest et a plus de 4 ans d'expérience en marketing et communication.

logo twitter
logo linkedin

Recevez les actualités du monde du test et d'Agilitest dans votre boîte mail

Rejoignez des milliers d'abonnés. Conforme RGPD et CCPA.