Testing Talks est une série d'interviews qui met en avant des personnalités connues du monde de la qualité et des tests de logiciels. Dans ce nouvel épisode, nous avons eu le plaisir de nous entretenir avec John Ferguson Smart.
Vous pouvez regarder l'interview ou accéder directement à la transcription ci-dessous.
Pouvez-vous vous présenter et décrire votre parcours ?
Je m'appelle John Smart. Je travaille dans le domaine Agile depuis plusieurs décennies. J'ai créé un cadre de bibliothèque d'automatisation des tests et j'ai écrit quelques livres sur le développement Agile. L'un d'eux s'intitule "BDD in Action" et la deuxième édition sortira prochainement. Je fais du développement logiciel depuis le milieu des années 90, sous différentes formes. Je me suis impliqué dans le développement Agile à la fin des années 90. J'ai commencé à m'intéresser à BBD, plus particulièrement, lorsque j'ai commencé à travailler à Londres. En fait, je traînais avec les praticiens XP de Londres et j'ai travaillé avec beaucoup de personnes très intelligentes qui circulaient autour d'idées comme TVD et BBD, et d'autres pratiques de ce genre. J'ai appris quelques trucs là-bas et j'ai commencé à les appliquer. J'ai coaché des équipes en XP et Agile, en général. Je crois que la première a eu lieu en Égypte vers 2001-2002.
J'ai en quelque sorte observé l'évolution de l'automatisation des tests au fil des ans, passant de l'automatisation des scripts de test à des outils commerciaux encombrants, puis à des outils Selenium ou JavaScript. J'ai suivi cette évolution avec beaucoup d'intérêt, en voyant apparaître des outils à faible code ou sans code.
Ce que je fais dans mon travail de jour consiste davantage à aider les équipes, mais aussi à mettre les testeurs à niveau et à diriger un programme appelé Serenity Dojo. Il s'agit d'un programme destiné aux testeurs manuels et aux testeurs qui débutent dans l'automatisation des tests, afin de les amener à un niveau que je considérerais comme un niveau supérieur d'automatisation des tests. Parce que je pense qu'il y a trop de testeurs qui sont freinés par le fait qu'ils ne connaissent pas la bonne façon d'aborder l'automatisation des tests, qu'ils ne connaissent pas les bonnes techniques. Et ce ne sont pas nécessairement des techniques compliquées, mais personne ne les leur montre. Et beaucoup de personnes qui enseignent ou beaucoup de cours qui sont donnés ne sont pas nécessairement très utiles la plupart du temps. J'essaie donc de mettre les testeurs à niveau de cette façon.
Qu'est-ce qui vous a motivé à vous lancer dans ce secteur ?
Dans les tests ? C'est une très bonne question. J'ai dérivé vers les tests à partir de l'espace BBD. J'ai toujours été intéressé par le monde des tests. Lorsque j'étais chef de projet technique, j'étais impliqué dans les activités de test, dans la mesure des taux de défauts, dans l'étude des modèles... Je suis impliqué dans le domaine des tests depuis un certain temps, et je pense que tout a commencé à Sydney en 2011. J'y aidais des équipes à faire de l'automatisation des tests. Et puis le manager d'un de mes amis à l'époque a proposé cette idée : et si vous pouviez utiliser les tests pour documenter les applications ? Et si vous utilisiez les tests pour pouvoir documenter les fonctionnalités ? Et donc nous avons parlé de ça. J'ai pensé que c'était une idée assez cool et j'ai créé quelques prototypes. J'ai été plus impliqué dans l'automatisation des tests - je veux dire que j'enseignais l'automatisation des tests avant cela, probablement en 2005-2006 - mais en fait, écrire les outils et créer un outil d'automatisation des tests qui ne se contenterait pas d'automatiser les tests mais qui documenterait aussi les fonctionnalités, c'était nouveau...
Qu'aimez-vous le plus dans votre travail ?
J'aime voir l'évolution que les gens font dans leur travail, dans leur façon de travailler ; lorsqu'ils apprennent à écrire de bonnes techniques d'automatisation des tests ou à utiliser des cadres d'automatisation des tests vraiment efficaces.
Je trouve satisfaisant de voir les tests passer de l'écriture de scripts de test ad hoc très grossiers à des tests qui prennent moins de temps pour écrire de nouveaux scripts. Il s'agit donc en quelque sorte de ce que j'aime voir. Ce que j'aime le plus dans mon travail, c'est de voir cet impact. Voir l'impact de l'enseignement d'une technique à des personnes qui l'assimilent, l'appliquent et l'exécutent, et voir comment cela a un impact sur leur carrière. Il ne s'agit pas seulement de l'idée théorique et esthétique d'écrire du bon code, mais de l'impact concret que cela a sur les projets et sur leur propre carrière.
Avez-vous une anecdote à partager ?
J'ai beaucoup d'anecdotes... Il y a un projet sur lequel je travaillais, et nous faisions une exigence 3 sessions Amigo. Le Product Owner est venu avec les exigences, en disant : "Bien. Bon. Ce qui doit se passer, c'est que nous devons télécharger une feuille de calcul Excel dans la base de données, puis envoyer un message dans notre système de flux de travail où tous les utilisateurs du système doivent être notifiés. Et ensuite, ils doivent être en mesure de mettre à jour l'état du flux de travail ou de changer l'état et de faire cette feuille de calcul. Il s'agissait essentiellement de verrouiller les données. Ils pouvaient télécharger une feuille de calcul, mais elle ne pouvait pas être modifiée. Et la seule façon de la modifier était de soumettre un processus de flux de travail, où ils pouvaient aller dans le flux de travail et modifier les données. Ensuite, ils avaient leurs permissions et leurs droits d'accès. C'était un système très compliqué et l'un des testeurs de l'équipe a dit : "Oui, mais pourquoi devons-nous faire cela ? Quel est le raisonnement derrière tout cela ? Nous adoptions en quelque sorte l'approche BBD qui consiste à avoir trois Amigos et à être très analytiques et critiques à l'égard des exigences, au fur et à mesure qu'elles nous parvenaient.
Je demande toujours, pourquoi tu as besoin de ça ? À quoi cela sert-il ? Et le PO a répondu : "Eh bien, nous devons faire cela de cette façon parce que c'est la façon dont cela a toujours été fait, c'est la façon dont cela a été fait avec la demande précédente". Elle lui a donc demandé pourquoi c'était fait comme ça dans la demande précédente. Et il s'avère que cela remonte à une application précédente, deux applications en arrière. C'est là que ce fichier a été téléchargé, et le fichier était essentiellement un fichier de rapport des vendeurs sur un système d'horaires de bus. Mais en gros, est-ce que les bus passaient à l'heure ? Ils devaient télécharger des statistiques et passer une certaine date. Ils n'étaient pas autorisés à modifier ces statistiques. Et donc ils avaient tout ce workflow en place à cause du système original. Donc, l'un des développeurs a dit : "Eh bien, pourquoi ne pas simplement envoyer un e-mail notifiant à tout le monde que ces données ont été téléchargées ?" Et il s'avère que c'est en fait tout ce qui était nécessaire.
Ainsi, cette exigence est passée d'environ trois mois de travail à environ un jour ou moins parce que le testeur posait ces questions. J'ai donc bien aimé cette histoire. Le ministère a économisé beaucoup d'argent simplement en posant la bonne question. Je pense que cela montre que les testeurs s'impliquent plus tôt, qu'ils ne se contentent pas de tester ce qui sort à la fin du processus, mais qu'ils participent réellement à la découverte des exigences. L'esprit critique que vous avez en tant que testeur peut vraiment aider à prévenir le gaspillage bien plus tôt que les gens ne le pensent souvent.
Quels sont pour vous les points essentiels pour réussir une transformation agile ?
Donc, les principaux critères de réussite d'une transformation agile... Je suppose qu'en fin de compte, est-ce que vous fournissez de la valeur plus rapidement, et pouvez-vous vous adapter au changement ? C'est ce que l'agile est essentiellement au sujet. Pouvez-vous vous adapter au changement plus facilement ? Mais généralement parlant, c'est assez difficile à mesurer, et vous ne mesurez pas vraiment cela jusqu'à un certain temps après la ligne. J'ai donc tendance à garder un œil sur les petites choses, ce que j'appelle les métriques de substitution. Par exemple, à quelle fréquence livrez-vous des logiciels fonctionnels ? À quel moment les développeurs ou les membres de l'équipe de développement, y compris les testeurs, sont-ils impliqués dans la découverte des exigences, dans la discussion des exigences ? Avez-vous une équipe de test ? Si vous avez une équipe de test séparée, ce n'est généralement pas un très bon signe sur le front agile. Avez-vous un espace UAT ? Consacrez-vous du temps aux tests UAT à la fin de chaque phase ?
Les choses me disent que nous ne faisons pas vraiment les choses de manière professionnelle. Donc, quand je vois des équipes qui planifient trois mois de travail, et puis ils ont encore deux mois après cela pour faire effectivement des tests ou des tests d'intégration ou des tests UIT ou peu importe comment ils veulent l'appeler. Cela me dit généralement qu'il y a un processus agile. Leur transformation agile n'est pas aussi optimale qu'elle pourrait l'être. Et ils n'utilisent pas réellement une approche agile si elle est livrée quand tout est prêt. Et cela inclut les tests.
Comment les entreprises doivent-elles organiser les équipes de test pour une meilleure efficacité ?
C'est une bonne question. Donc, comme je l'ai dit, si vous avez une équipe de test, vous n'êtes probablement pas agile parce qu'avoir une équipe de test implique que vous utilisez le test comme une activité séparée pendant que le développement est fait, puis nous allons le remettre aux testeurs. Je veux dire, j'ai vu un post sur les différents types de tests que les tests devraient faire. Quelqu'un a dit que les développeurs ne devraient rien faire, mais que les testeurs devraient tout faire, y compris les tests unitaires. C'est une idée étrange puisque les tests unitaires sont souvent inefficaces lorsqu'ils sont effectués par les testeurs. Les tests unitaires sont une sorte de test que vous voulez que les développeurs gèrent avant qu'ils ne fassent réellement le travail.
Généralement, les tests en équipe sont traités comme une activité "après coup". Vous livrez une fonctionnalité, puis vous la testez, tout comme vous livrez une version, puis vous la testez. Et c'est probablement la façon la plus inefficace de tester que je connaisse. Elle entraîne également beaucoup de gaspillage et d'incertitude dans le processus. Donc je dirais, comment organiser une équipe de test pour être plus efficace ? Eh bien, mettez les testeurs directement dans les équipes. Ainsi, au lieu d'avoir une équipe de test, vous avez des communautés de pratique pour partager, promouvoir et cultiver les meilleures pratiques. Au lieu d'avoir une équipe de test, vous avez des testeurs plus expérimentés ou des ingénieurs en automatisation des tests qui forment les testeurs et les aident à démarrer leur automatisation ou leur approche BBD au sein d'un projet ou d'un module. Mais vous pouvez aussi avoir un gouvernement. Nous les appelons souvent des conseils, ou des communautés de pratique. Ils agissent comme des conseillers techniques qui supervisent les pratiques pour s'assurer que tout le monde est aligné. Les bonnes pratiques sont partagées, mais vous n'avez pas d'équipe de test séparée. Donc ce serait mon premier conseil, dissoudre l'équipe.
Que pensez-vous de l'avenir des méthodes agiles ?
Les méthodes agiles sont en train d'être industrialisées, ce qui n'est pas une bonne chose. De ce que l'on voit aujourd'hui, ce sont les techniques de type waterfall qui sont étiquetées comme agiles, car c'est beaucoup plus facile à vendre au management et aux grandes organisations. C'est une approche rassurante et structurée qui s'éloigne des valeurs fondamentales du domaine Agile.
XP n'a pas adopté l'agilité. C'est dommage, car c'est une technique supérieure à Scrum, en ce qui concerne la livraison de logiciels. Elle est "malheureusement" plus difficile à mettre en œuvre.
Lorsque vous avez des équipes qui maîtrisent la livraison continue, l'intégration continue, le développement piloté par les tests... vous obtenez un véritable processus Agile.
X-Scale est une entreprise que je surveille de près pour les méthodes agiles. Leur approche est qu'il faut réduire les organisations en donnant aux équipes les moyens de travailler ensemble plus efficacement. La plupart des techniques comme Safe ne visent pas à donner aux équipes les moyens de travailler ensemble plus efficacement, elles visent à construire une hiérarchie complexe de commandement et de contrôle. Même si cela ne semble pas être le cas sur le papier, dans la pratique, c'est ce qui se passe. Et le commandement et le contrôle ne sont jamais très propices à de bonnes pratiques agiles.
Vous avez écrit quelques articles sur le BDD. En quoi cela aide-t-il les tests manuels ?
C'est une question intéressante, car le BBD ne concerne pas vraiment les tests. Le BBD concerne la découverte des exigences et la collaboration. Les tests sont une chose totalement différente. Mais que pourrais-je dire, comment le BDD aide-t-il les tests manuels ? Je peux dire comment le BDD aide à effectuer un test manuel. Un testeur manuel dans une équipe pratiquant le BDD s'impliquera dans la découverte des exigences et exigera des conversations sur les exigences et les stratégies de test beaucoup plus tôt que dans une approche conventionnelle. Il aura une vision plus claire de ses exigences et sera en mesure de fournir un retour sur la nécessité de tester efficacement ces exigences avant la mise en œuvre. Cela donne de l'importance aux testeurs, plus que dans une approche de test traditionnelle. Ainsi, avec le BDD, nous avons les sessions des trois Amigos ou même les sessions de découverte plus tôt, où nous prenons une histoire d'utilisateur ou une fonctionnalité et nous la décortiquons. En fait, nous procédons à un examen croisé et recherchons des exemples, des contre-exemples et des règles commerciales. Les testeurs sont très doués pour cela, ils peuvent apporter une valeur ajoutée considérable en apportant leur contribution à ce niveau. Donc, pour un testeur manuel, cela change son rôle de manière assez significative.
Cela leur donne beaucoup plus de poids à un stade précoce. Il peut également réduire la quantité de tests manuels à effectuer, du moins pour les tests manuels ennuyeux, et laisser du temps pour des tests plus exploratoires. Parce que si vous faites bien le BDD en utilisant une approche avec des spécifications exécutables qui dirigent le développement du processus, il y a très peu d'automatisation à faire par la suite. En gros, un product owner mettrait à jour un ensemble de scénarios Cucumber avec l'équipe pour décrire les règles métier qu'ils veulent mettre en œuvre. Cela conduirait à l'échec du développement des tests et à l'échec des scénarios. Ils l'exécutaient à nouveau, et c'était tout. Cela fonctionne très bien, mais il faut beaucoup d'efforts et de compétences pour le mettre en place. Mais une fois que vous l'avez mis en place, vous avez une équipe très performante. Le testeur manuel dans ce rôle sera très impliqué dans l'articulation des exigences et dans le fait que cela fonctionne comme prévu.
Il peut également s'agir d'un moyen pour les testeurs manuels de s'impliquer dans l'automatisation, car l'automatisation d'un processus BDD est beaucoup plus étroitement liée à l'ensemble du flux de développement. Ce n'est pas quelque chose qui se produit de manière isolée. Ainsi, les testeurs manuels peuvent même travailler avec les développeurs pour que cela se produise. Cela peut être un chemin plus doux vers l'automatisation que si vous deviez apprendre l'automatisation à partir de zéro.
Que recommandez-vous pour passer des tests manuels aux tests automatisés ?
Tout d'abord, je vous recommande de ne pas commencer par les cours Udemy sur Selenium ou Cyprus ou autre. Ne commencez pas avec les frameworks. Ne commencez pas par l'automatisation de scripts de test manuels, car cela vous mènera très rapidement à un code sans issue. Fondamentalement, l'automatisation c'est du codage et même avec les outils à faible code. En fin de compte, vous allez penser avec une mentalité de codage, vous devez comprendre le développement. Et donc si vous voulez vous lancer dans l'automatisation, vous devez commencer par coder l'automatisation. Le codage d'automatisation est du codage. Vous ne pouvez pas vraiment vous éloigner de cela. Donc c'est vraiment par là qu'il faut commencer. L'astuce est que la plupart des livres de codage, la plupart des cours de codage sur Udemy sont vraiment écrits du point de vue du développement. Ils sont donc un peu plus larges, et ils examinent des choses dont vous n'avez pas nécessairement besoin en tant que testeur. Ainsi, en tant que testeur faisant de l'automatisation des tests, vous devez comprendre toutes les fonctionnalités du langage ou l'approche du développement, etc. Mais il y a beaucoup de choses dont vous n'avez pas besoin. Il peut donc être utile de trouver des cours de formation qui sont plus axés sur les tests. Le problème est qu'un grand nombre de cours de formation au test sont une sorte de casse-tête difficile parce qu'un grand nombre de cours de formation au test écrits par des testeurs n'ont pas une mentalité de développement. Ils n'ont pas le réflexe d'écrire du code d'automatisation de haute qualité. Il y a beaucoup de mauvaises habitudes dans ces cours, il est donc parfois difficile de trouver le bon mélange. Mais si vous voulez commencer par le côté codage des choses, apprenez à bien coder. Certaines personnes commencent avec des choses comme Python parce que c'est plus facile. Je ne suis pas un grand fan, à moins que vous n'entriez dans une entreprise, ou que vous soyez dans une entreprise qui utilise réellement Python. Je recommanderais de commencer par Java, car c'est le langage le plus utilisé dans le monde de l'automatisation. JavaScript est également utile... Le deuxième conseil que je donne, je suppose, est de ne pas essayer d'être comme certains CVS que vous voyez sur LinkedIn où ils ont 100 outils de test listés. Vous n'en avez besoin que d'un seul. Vous voulez commencer avec un seul et le maîtriser vraiment bien. Et une fois que vous connaissez vraiment bien un outil, que ce soit Selenium ou Playwright ou autre, il est assez facile de transférer les compétences d'automatisation. Toutes ces compétences d'automatisation sont très transférables d'un outil à l'autre.
L'aspect le plus important de l'automatisation n'est pas les outils. Les outils sont relativement faciles. La chose la plus importante est l'état d'esprit et la façon de concevoir l'automatisation. Comment créer, essentiellement pour savoir quels scénarios automatiser, comment les automatiser, quels scénarios ne pas automatiser. Et c'est ce qui pose problème à la plupart des testeurs. Vous devez essentiellement comprendre comment commencer par l'automatisation des exigences et les transformer en spécifications exécutables automatisées significatives. Si vous automatisez les exigences, vous pourriez changer toute l'équipe. Si vous automatisez les scripts de test, vous pouvez peut-être gagner un peu de temps. Il s'agit donc d'une approche très différente et si vous voulez en tirer parti, vous devez comprendre comment automatiser les exigences et comment penser en ces termes. La dernière chose est que vous pouvez apprendre un langage assez rapidement si vous y mettez du vôtre.
Mais ne vous attendez pas à tout maîtriser du jour au lendemain. Je veux dire que le programme de formation que j'organise pour les tests manuels dure six mois. Certains testeurs ont suivi le programme et ils se sont mis à niveau en un mois ou deux et ont obtenu des emplois et de bons nouveaux rôles dans l'automatisation des tests. Mais vous apprenez continuellement tout au long de ces six mois et vous renforcez vos compétences parce que cela ne se fait pas du jour au lendemain. Si les gens disent que vous allez apprendre l'automatisation en 40 heures de cours, ce n'est pas vrai. Vous l'apprendrez à un niveau superficiel, mais vous n'aurez pas la profondeur d'expérience nécessaire pour pouvoir l'appliquer. Ne vous attendez donc pas à une solution miracle du jour au lendemain. Cela prend du temps. Vous devez persévérer, car il y a beaucoup à apprendre.
Avez-vous un dernier mot ? Peut-être quelque chose à retenir pour ce interview?
Je dirais que si vous êtes un testeur qui veut se lancer dans l'automatisation des tests, il y a un problème au départ. Il vient du test manuel. Cela demande une certaine discipline et vous devez faire une action consciente pour dire que vous allez apprendre l'automatisation. Mais cela en vaut vraiment la peine. Je connais tellement de testeurs qui travaillent avec tellement d'autres testeurs qui ne connaissaient pas du tout le codage et qui sont devenus très bons. Même l'une des étudiantes avec qui j'ai travaillé est passée d'un service d'assistance à une transformation BBD dans une banque... Les options de carrière qui s'offrent à vous lorsque vous empruntez ces voies sont donc vraiment satisfaisantes. Mais vous devez faire preuve de discipline et vous y tenir.
.png)
