Testing Talks est une série d'interviews mettant 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 Michael Bolton. Voici un résumé de son interview.
Pouvez-vous vous présenter ?
Je m'appelle Michael Bolton. Cela fait maintenant 35 ans que je travaille dans le développement et le test de logiciels. Et c'est bizarre parce que je n'ai pas vu passer ces 35 ans. Mais c'est le cas, je suppose. Avant cela, je travaillais dans un théâtre. (...) Tout au long des années 1990, j'ai travaillé pour une société appelée Quarterdeck, où j'ai été assistant technique, testeur, gestionnaire de programme, développeur, documentaliste, puis à nouveau gestionnaire de programme. En 1998, je suis devenu indépendant. Et en 2001, j'ai rencontré James Bach. En 2003, nous sommes devenus collègues pour enseigner et présenter le test rapide de logiciels, qu'il avait conçu et développé. En 2006, j'ai coécrit ce document et depuis, je présente des approches, des formations et des écrits sur les tests rapides de logiciels dans le monde entier. Cela fait 20 ans que je suis impliqué dans les tests rapides de logiciels.
Comment mettre en place une stratégie de test efficace ? Quelles méthodologies recommanderiez-vous ?
Pour élaborer une méthodologie de test efficace ou en appliquer une, je suggérerais les tests rapides de logiciels. C'est conçu pour fonctionner dans n'importe quel contexte, car la méthodologie et l'approche sont axées sur le contexte. Le fait est que les tests dépendent de la situation. La situation affecte également nos choix, et ces deux éléments peuvent changer au fil du temps. Vous trouverez un document sur le site de James, Satisfies.com, qui répond à la question de savoir comment élaborer une stratégie de test réussie. Mais notre principale motivation est de nous concentrer sur les problèmes. L'accent est mis sur les problèmes. Et c'est une façon de voir les tests qui est différente de celle de beaucoup de vos auditeurs. En effet, le point de vue d'un développeur sur les tests n'est pas le même que celui d'un testeur. Les développeurs sont fondamentalement des créateurs. Leur idée est de créer des choses qui permettent de résoudre les problèmes. Un testeur est le genre de personne qui va chercher et trouver des problèmes partout où il regarde. La différence entre les tests orientés vers les développeurs et les tests orientés vers les testeurs est que les développeurs essaient de déterminer si leur travail correspond à ce qu'ils voulaient créer. (...)
Une bonne stratégie de test intègre ces deux types de tests. (...) Une grande partie des tests effectués par les développeurs n'est pas vraiment axée sur des données riches, stimulantes et complexes. Une grande partie des tests effectués par les développeurs n'est pas axée sur le développement d'une solide compréhension de la manière dont les gens utilisent réellement le produit. Dans la pratique, les développeurs n'ont pas le temps de mettre en place des environnements de test, des plates-formes, différents appareils mobiles, Safari, Windows, etc.
Une bonne stratégie de test englobe - de notre point de vue - la compréhension de votre environnement et de votre contexte. La mission consiste à tester les informations dont vous disposez. Vos relations en tant que testeur avec l'équipe de test, l'équipement et les outils disponibles ou ce dont vous allez avoir besoin pour développer et construire le calendrier. Ces éléments ont une grande influence sur la stratégie. Le type de stratégie appliqué au test d'un jeu est très différent de celui appliqué à une application bancaire, qui est encore différent d'un dispositif médical.
En fait, une stratégie est axée sur le risque, élaborée sur la conviction qu'il existe des problèmes dans le produit et à propos du produit qui comptent. Elle est pratique, réalisable, spécifique au produit et au projet. Ce sont là quelques-uns des éléments les plus importants d'une stratégie. Il existe un autre document auquel je me réfère dans le cadre des tests rapides de logiciels et qui s'appelle le modèle heuristique de stratégie de test. Il peut être assimilé à une métastratégie, car il s'agit d'une stratégie de test. Un autre élément vraiment important de toute stratégie de test d'un produit est qu'elle sera unique pour ce produit et pour cet ensemble de conditions, dans cet ensemble de circonstances.
Que recommandez-vous pour passer des tests manuels aux tests automatisés ?
Abandonner l'idée. Les tests ne sont pas manuels et les tests ne sont pas automatisés. Quelle est la stratégie pour passer du développement manuel au développement automatisé ? Il n'y en a pas, car le développement n'est pas un processus automatisé ou manuel. C'est un processus cognitif, social et intellectuel. Les tests sont les mêmes, la gestion est la même. Personne ne parle de passer d'une gestion manuelle à une gestion automatisée. Personne ne parle de passer de la recherche manuelle à la recherche automatisée. Pensons plutôt à ce concept que les gens appellent les tests automatisés. Nous devrions plutôt parler de vérification automatisée des résultats. Vérifier la sortie d'un processus mécanique, en utilisant des moyens mécaniques pour effectuer le contrôle qui peut être automatisé. Mais la partie test pour effectuer ce test nécessite une intention, une conception et un encodage... Elle explique à la machine comment effectuer les éléments de cette tâche. Maintenant, qu'en est-il de la vérification ? Cette partie peut être accomplie par la machine, automatisée, et recommencée. Le test est l'application d'un oracle, d'un principe ou d'un moyen par lequel nous reconnaissons un problème.
Et ce n'est pas parce qu'un chèque est retourné en rouge qu'il y a un problème dans le produit. Il peut s'agir d'un problème dans notre conception ou d'une mauvaise compréhension de ce que le chèque est censé faire. Le contrôle et le produit peuvent donc être corrects, mais ils ne se rencontrent pas. Cessez donc de penser en termes de tests automatisés et commencez à considérer la vérification automatisée comme un outil que nous utiliserions. (...) L'autre chose qui me rend fou à propos des tests automatisés - ainsi appelés - c'est qu'ils ignorent absolument toutes les autres façons dont nous pourrions utiliser des outils pour nous aider à tester, à générer des données, à configurer et à reconfigurer les machines, à analyser, analyser, rechercher, trier les données et les résultats, à modéliser le produit de diverses façons intéressantes.
Toutes ces choses sont des applications d'outils et sont normales pour les testeurs. Il ne s'agit pas d'une transition. Il s'agit simplement d'approfondir vos compétences et vos perspectives sur la manière d'utiliser les outils de test. C'est donc une question qui a été le déclencheur de toute ma carrière. (...) Le test est bien plus que cela. Le test est un processus heuristique, pas un processus algorithmique.
Quels sont les principaux enseignements de votre livre "Rapid Software Testing" ?
(...) Premièrement, le développement et le test de logiciels sont fondamentalement des processus sociaux humains. Et ils dérapent pour toutes les raisons qui font que les processus sociaux humains dérapent. L'incompréhension est motivée par des considérations économiques, par l'ambition et influencée par le risque et la récompense. (...) Le testeur joue un rôle crucial dans le projet. Alors que tous les autres se concentrent sur la construction et la réussite du produit, le testeur s'assure qu'il répond aux attentes des humains et des machines.
En tant que testeurs, nous nous concentrons sur les problèmes qui se situent entre les deux. Dans les tests rapides de logiciels, nous essayons de le faire de la manière la plus rapide, la plus efficace et la moins coûteuse, tout en fournissant d'excellents résultats dans la réalisation de la mission des tests, qui est de trouver les problèmes importants avant qu'il ne soit trop tard. (...) Le testeur devient un élément central du processus de test. Pas les outils, pas la documentation, pas le modèle de processus, mais le testeur et ses compétences.
Il existe une série d'articles de blog, trois articles de blog assez courts que James et moi avons écrits sur le sujet. Ils sont hébergés sur mon site developsense.com. Cherchez "rapid software testing premises" et vous les trouverez.
Un conseil que vous donnez toujours à propos des tests agiles ?
J'essaie toujours de donner du crédit à mon ami Scott Barber qui dit que les tests rapides de logiciels et les tests en général doivent répondre à n'importe quel contexte dans lequel ils se trouvent. L'une des choses sur lesquelles le manifeste pour le développement Agile met l'accent, c'est sur les individus et les interactions plutôt que sur les processus et les outils. Je pense que ce qu'ils voulaient dire était "modèles de processus", puisque les interactions peuvent être considérées comme des processus, qu'il s'agisse d'interactions entre individus ou de processus eux-mêmes. Le développement de logiciels est donc également un processus. Mais je pense qu'ils parlent d'individus et d'interactions plutôt que de modèles de processus et d'outils parce que nous développons constamment de nouvelles choses et que chaque description d'un processus est essentiellement une histoire à son sujet. (...)
Mais il est intéressant de noter que le travail sur les logiciels n'est pas notre activité dans les tests rapides de logiciels, ce qui va secouer beaucoup de gens. Notre objectif est que les gens soient conscients de l'existence du logiciel et qu'ils aient des connaissances à son sujet. Si le logiciel fonctionne, c'est très bien. S'il ne fonctionne pas, nous voulons en être informés et nous voulons que les autres le sachent aussi. Au lieu de se concentrer uniquement sur les logiciels qui fonctionnent, nous pourrions ajouter un petit changement à la charte du manifeste Agile. (...)
Je ne vois pas beaucoup cela dans le monde des tests, et il serait vraiment bon de le voir plus souvent parce que c'est ainsi que nous allons trouver des problèmes plus profonds. D'un autre côté, c'est la raison pour laquelle le support client est une excellente voie de migration pour les personnes travaillant dans une organisation de développement. Si vous avez de l'expérience dans l'assistance à la clientèle, vous allez avoir toute une série d'informations sur la façon dont les clients interagissent et utilisent un produit et sur la façon dont ils rencontrent des problèmes, ce qui permet d'éclairer ce que sont vraiment les tests. Pour nous, du point de vue d'un testeur, tester c'est expérimenter, explorer et expérimenter le produit. Et comme je le dis dans le monde des tests Agile, l'accent est souvent mis sur les fonctions du produit. Vérifier les résultats. Et c'est, bien sûr, important, mais ce n'est en aucun cas la seule chose à vérifier. Il y a maintenant un quatrième élément dans le manifeste.
(...) Le produit change constamment. Et donc notre stratégie de test aussi. Elle doit évoluer et s'adapter à ce qui se passe dans le projet. Notre approche des tests dans un projet est plus large que ce qui est généralement considéré dans certaines notions de tests axées sur les développeurs dans des contextes agiles.
Que pensez-vous de l'IA dans les tests ?
Un de mes amis, Leonard Zurman, un programmeur qui m'a engagé à un moment donné sur un projet basé sur l'apprentissage automatique, a un t-shirt qui dit : "Je ne suis pas tellement inquiet de l'intelligence artificielle. C'est la stupidité naturelle qui m'inquiète". Nous sommes très éblouis par les affirmations relatives à l'IA. Certains testeurs parlent beaucoup ces jours-ci, dans certains cercles, de la façon dont l'IA va tout changer. Mais en réalité, lorsque j'y regarde de plus près, ce dont ils parlent n'est pas du tout de l'IA. Il s'agit de logiciels. Du bon vieux logiciel ordinaire. Les gens parlent de l'IA comme d'un terme de marketing. À mon avis, ce n'est pas vraiment un terme d'ingénierie. D'une part, votre question pourrait porter sur la manière dont nous testerions l'IA. Ma réaction à cette question est la suivante : nous devrions tester l'IA avec un énorme scepticisme. Voici pourquoi. Lorsque nous appliquons des modèles d'apprentissage automatique, en particulier, nous jetons des spaghettis contre le mur et choisissons ceux qui collent. Essentiellement, ce que nous faisons, c'est que nous avons un algorithme qui tente de faire des classifications, et parfois c'est une chose terrible qu'il essaie de faire.
Cependant, il est impossible de faire des prédictions précises sur le comportement humain en se basant uniquement sur des données passées. Il est possible de contourner ce problème, chargé de certains types de biais, en se basant simplement sur l'endroit où les données sont obtenues. Elles sont obtenues à partir de données électroniques. Ensuite, les algorithmes génèrent d'autres algorithmes, et nous ne savons pas ce que ces algorithmes font réellement. Ce n'est pas comme un programme que nous avons écrit intentionnellement, où nous pouvons voir une ligne de code et dire qu'il y a un problème. Nous pouvons corriger cette ligne de code. Nous pouvons corriger cette chose qui génère une conclusion erronée ou un résultat erroné. Nous ne pouvons pas faire cela avec l'apprentissage automatique. À moins d'avoir quelqu'un qui soit vraiment, vraiment doué en langage d'assemblage. Nous pouvons découvrir quel paramètre a incité le produit à produire ce résultat, mais il est peu probable que cela se produise. L'IA est essentiellement un emploi à vie pour les testeurs en tant que critiques, parce que nous n'avons aucun moyen de vérifier, d'examiner et de lire le code. Cela signifie que nous aurons des testeurs qui se concentreront sur la possibilité d'exploiter et d'utiliser le produit de manière à lui faire cracher ses problèmes.
Pour notre type de testeurs, c'est faisable. Pour les testeurs qui dépendent d'un processus de vérification automatisée étape par étape, formellement décrit et structuré par des procédures, cette méthode est sans espoir dans le domaine de l'IA. Voici donc une chose que vous pourriez faire lorsque vous appliquez l'IA aux tests. Vous pouvez l'utiliser comme un jiggler. Vous pouvez utiliser chatGPT, par exemple. Vous pouvez l'utiliser pour générer un échantillon d'idées de tests. Mais ne les utilisez pas. Utilisez-les de manière critique. Utilisez-les pour stimuler vos propres idées. (...)
Bien sûr, cela dépend de l'application de cette idée, de notre façon merveilleusement humaine de prendre quelque chose et de lui donner un sens. C'est également le cas de l'IA. L'IA n'est pas quelque chose que nous devrions considérer comme acquis parce qu'elle est réellement en train d'être générée. Concrètement, le type d'IA dont je parle maintenant, ce sont ces grands modèles de langage qui génèrent des choses qui ont l'air humaines. Je recommande un article de Stephen Wolfram, qui explique essentiellement que nous lions ensemble des séquences de contenu qui sont susceptibles d'être cohérentes. (..)
Ainsi, si vous utilisez un grand modèle de langage comme moyen fiable de penser aux tests, le résultat sera désastreux. Nous avons donc besoin d'un raisonnement et d'un rejet conscient de l'idée que cette chose est intelligente. Ce n'est pas le cas. C'est Emily Bender qui l'a le mieux exprimé : "C'est un perroquet stochastique". Il ne comprend pas vraiment ce qu'il dit. Et en tant qu'humains, nous devons faire très attention à ne pas l'anthropomorphiser, à ne pas le rendre plus que ce qu'il n'est.
Sur quoi dois-je me concentrer lorsque je commence une carrière dans le domaine des tests ?
De nombreuses personnes arrivent dans le monde des tests en venant d'ailleurs. Les universités, les établissements d'enseignement supérieur et toute autre forme d'éducation formelle ne consacrent pas beaucoup de temps aux tests. (...) C'est donc à vous de décider quand vous commencez. J'ai remarqué que les gens tombent très souvent dans cette carrière par hasard et par accident. Et c'est très bien. C'est formidable parce que nous avons besoin d'une grande variété de personnes issues d'une grande variété de disciplines. Avec des origines culturelles, ethniques ou éducatives différentes et avec des tempéraments, des compétences et des préférences différents. Tous ces éléments contribuent à enrichir la communauté des testeurs. Et c'est important parce que ce dont nous avons le plus besoin dans les tests, c'est d'un point de vue extérieur. Tout test basé sur ce que pensent les développeurs, comment les développeurs pensent, comment le code est fait.
(...) Mes principales suggestions seraient de développer votre connaissance des tests et votre compréhension des tests en vous immergeant dans les communautés de test. Prenez ce qui vous intéresse et trouvez un moyen de le relier à la recherche critique sur les produits et les projets. C'est ce que je recommanderais.
Un dernier mot pour cette interview?
J'encourage les gens à se pencher sur notre matériel et sur nos offres de test : Developsense.com - mon site - et Satisfies.com - le site de James Bach. Mais chers testeurs, s'il vous plaît, concentrez-vous sur les problèmes. C'est ce que nous devons faire. Nous sommes les seules personnes sur le projet dont la mission est de se concentrer sur les risques, les problèmes, et d'apprendre de chaque bug (...). Les tests ne font pas cela tout seul. Mais nous fournissons un ensemble puissant de projecteurs, de microscopes, de télescopes, d'antennes paraboliques, de microphones, grâce auxquels nous pouvons mieux comprendre le produit et aider à transmettre cette compréhension aux personnes qui l'améliorent.
.png)
