Testing Talks est une série d'interviews qui met en lumière 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 George Dinwiddie.
George Dinwiddie est un coach en développement de logiciels qui aide les organisations à développer des logiciels plus efficacement. Il aide les organisations, les gestionnaires et les équipes à résoudre les problèmes auxquels ils sont confrontés en offrant des services de conseil, d'encadrement, de mentorat et de formation au niveau de l'organisation, des processus, des équipes, des relations interpersonnelles et des techniques. Il est également propriétaire d'iDIA Computing.
Pouvez-vous vous présenter et décrire votre parcours ?
Après 25 ans d'ingénierie, quelques années de travail dans le domaine du matériel, puis une transition vers les microprogrammes et enfin les logiciels, je suis devenu consultant et coach indépendant, depuis 18 ans maintenant. J'ai en fait écrit ma première routine de multiplication à partir d'un schéma. Et avant cela, j'ai eu plusieurs emplois : j'ai été technicien audiovisuel, maraîcher biologique, machiniste de théâtre, éclairagiste et machiniste de scène… Et à l'âge de 14 ans, j'étais réparateur de télévision !
Comment avez-vous débuté dans le secteur du développement de logiciels ?
Au début des années 1980, je travaillais sur une puce de traitement des signaux numériques personnalisée pour un égaliseur adaptatif de modem. Le contrôleur de ce circuit était une machine à états, et il était programmé en code machine pur. J'ai donc obtenu de véritables informations sur le fonctionnement d'un processeur en travaillant sur ce circuit. À peu près à la même époque, je travaillais aussi à la construction de mon propre ordinateur CPM.
Vous avez écrit quelques articles sur la méthode Agile. Que pensez-vous de l'avenir de la méthode Agile ?
Lorsque j'ai découvert les méthodes Agile, cela avait déjà du sens pour moi, car cela ressemblait à la façon dont je travaillais déjà. Commencer avec un petit système fonctionnel et le faire évoluer au fil du temps, en construisant au fur et à mesure ce que vous avez besoin de faire. De cette manière, il est plus facile de vérifier que les choses fonctionnent. La partie qui n'avait pas de sens pour moi avec la programmation extrême était donc la première partie. Venant d'un milieu matériel, je ne pouvais pas imaginer comment vous pouviez tester quelque chose qui n'existait pas. J'étais très sceptique. Mais je communiquais avec des gens que je respectais, et ils disaient que ça marchait pour eux. J'ai donc fait un essai et cela a également très bien fonctionné pour moi. C'était avant que le nom Agile ne soit appliqué. On parlait alors de "méthodologies légères", et ces approches et leurs nouveaux perfectionnements continueront d'être utilisés par des personnes dans des organisations qui veulent que les choses soient faites - à la fois bien et rapidement.
Il continuera également à y avoir des personnes dans des organisations qui sont quelque peu isolées des conséquences de leurs actions, qui penseront qu'elles peuvent tout planifier et faire en sorte que les gens suivent ce plan. C'est leur perte.
Quel est le plus grand défi que vous ayez eu à relever, et comment l'avez-vous surmonté ?
Il y a eu tellement de défis à relever, souvent très différents les uns des autres, et j'ai survécu à tous. Le plus difficile pour moi a peut-être été d'apprendre à aider efficacement les gens. J'ai grandi en pensant en termes techniques, et j'avais l'habitude de penser qu'il suffisait de donner la réponse aux gens. Mais cela n'a pas donné les résultats que j'ai vus. Des personnes comme Dale Emery, Jerry Weinberg et Esther Derby m'ont aidé à m'engager sur la voie de l'apprentissage de méthodes plus efficaces pour travailler avec les gens.
Qu'est-ce qui vous plaît le plus dans l'accompagnement des personnes dans le développement de logiciels ?
J'aime aider les gens, vraiment. J'aime aussi apprendre des choses. Grâce à ces deux éléments, j'éprouve une grande joie à voir d'autres personnes s'illuminer lorsqu'elles apprennent quelque chose qui les aide !
Quel conseil donnez-vous toujours en matière de développement de logiciels ?
J'aime rappeler aux gens les concepts de couplage et de cohésion de Larry Constantine, qui, selon moi, constituent la base de presque toutes les bonnes conceptions et architectures logicielles. Beaucoup de patrons plus compliqués ne sont que des couches superposées, ou des moyens spécifiques d'y parvenir.
Quels sont pour vous les points essentiels pour réussir la transformation agile ?
Il y a deux choses qui, à mon avis, sont terriblement importantes et auxquelles on n'accorde souvent pas assez de crédit lorsque les gens commencent à travailler. La première est de faire de petits pas.
Et de faire attention à ce qui se passe. Cela fonctionne aussi bien avec le code qu'avec la transformation elle-même. Essayez des choses, regardez les résultats que vous obtenez et ajustez.
L'autre consiste à respecter les gens et à honorer leur humanité. Très souvent, les personnes qui ont l'habitude de travailler avec des machines prennent l'habitude de le faire et traitent les gens qui les entourent comme des machines également. Mais ce n'est pas le cas. Ce sont des personnes vivantes, qui respirent et qui ont leurs propres idées. Et leurs idées peuvent mieux fonctionner dans cette situation que les idées avec lesquelles vous avez commencé.
Vous avez écrit un livre sur le code d'automatisation des tests. Pouvez-vous nous parler de l'écriture de ce livre ?
Le livre s'intitule Evolutionary Anatomy of Test Automation Code. Et il est disponible sur Leanpub.
Lisa Crispin m'a contacté. Elle faisait partie du comité de programme de la première conférence technique d'Agile Alliance, qui s'est tenue à Raleigh en 2016. Elle m'a demandé si cela m'intéresserait d'y faire un discours, et j'ai répondu : "Bien sûr". J'étais d'accord avec presque tout ce que Lisa Crispin me demandait ; mais ce n'était pas une chose difficile à accepter. Elle m'a demandé : "Quel est le titre de votre intervention ?". J'ai réfléchi au fait que les exemples en ligne d'automatisation des tests ont tendance à être très petits. Ils présentent les capacités d'un outil particulier et ne montrent pas comment les choses évoluent avec le temps. Ils ne montrent pas comment faire évoluer un système en utilisant cet outil. J'ai donc pensé que l'anatomie évolutive du code d'automatisation des tests serait un bon sujet dont le secteur avait vraiment besoin. Je lui ai alors donné ce titre, et j'ai réalisé que pour produire cet exposé, j'allais devoir écrire une base de code importante pour démontrer les choses dont je parlais. J'ai passé un mois à travailler seul sur ce code - et ce n'est probablement pas le meilleur code que j'ai jamais écrit. Je n'avais personne avec qui échanger des idées et personne pour le regarder avec moi. Et puis, je devais faire coïncider tout cela avec d'autres choses que je faisais. Mais j'ai développé ce code. Ce n'est pas seulement le code, mais c'est l'histoire du code à obtenir au fur et à mesure. J'ai finalement terminé le code, et j'ai pris des notes au fur et à mesure, et je me suis assis pour faire la conférence ; et c'était difficile. Ma première version de la conférence est devenue le livre. J'ai passé plus de 40 heures en un week-end à écrire la première version du livre pour essayer d'organiser l'exposé. Ensuite, j'ai montré ce que j'avais à un collègue et il m'a dit : "Combien de temps dure cet exposé ?" J'ai dû supprimer la majeure partie de l'exposé, car il aurait été beaucoup trop long. Mais j'ai peaufiné le livre et l'ai publié sur Leanpub.
Quelles seraient vos meilleures pratiques pour écrire un bon code d'automatisation des tests ?
La chose la plus importante avec le code d'automatisation des tests est qu'il doit communiquer clairement l'intention. Je ne sais pas combien de fois j'ai rencontré des organisations et des programmeurs qui ont exercé le code qu'ils ont écrit et démontré à leur satisfaction qu'il fonctionne. Mais vous ne pouvez pas dire ce que le système est censé faire quand vous le lisez, et cela rend très difficile de comprendre plus tard quand quelque chose ne fonctionne pas. Eh bien, qu'était-il censé faire ? Et il est très difficile de comprendre où sont les trous dans cette couverture de test, quelles sont les choses qui ne sont pas testées. L'autre chose est que l'automatisation des tests est aussi du code - et il doit être maintenable à long terme. Maintenant, rendre l'intention claire vous aide à maintenir. Mais, il doit aussi être bien structuré et structuré pour ses besoins. Il y a quelques différences entre la structure du code de test et celle du code de production, mais beaucoup de concepts identiques se retrouvent. Ainsi, le code doit aussi se décrire lui-même.
Un dernier mot pour terminer cette interview ?
Mon conseil est le suivant : soyez fier de ce que vous faites. Quoi que ce soit. Et ne cessez jamais d'apprendre. Et si vous êtes bloqués, demandez de l'aide. Il y a presque toujours quelqu'un qui peut vous donner un avis, des idées, même si vous pensez qu'il n'en sait pas autant que vous sur le sujet. Parfois, les questions des novices sont plus utiles que celles de quelqu'un qui connaît bien le problème. Et si vous ne connaissez personne qui puisse vous aider, si vous n'avez personne de disponible, n'hésitez pas à me contacter ! Comme je l'ai dit, j'adore aider les gens. Et je serais ravi d'y réfléchir avec vous !
.png)
