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 Melissa Eaden.
Elle a été rédactrice chez Ministry of Testing pendant plus de trois ans et est aujourd'hui directrice principale de l'ingénierie chez Unity. Elle est également intervenante, auteure et défend une culture de la qualité et des tests dans l'ingénierie.
Pouvez-vous vous présenter et décrire votre parcours ?
Je m'appelle Melissa Eaden. Je suis senior technologist. J'ai occupé tous les postes, du testeur manuel à l'automaticien, jusqu'à l'ingénieur en chef. QA Manager et maintenant responsable de l'ingénierie. Je travaille actuellement chez Unity Technologies. Unity Technologies est avant tout une société de moteurs de jeux, mais elle propose également plusieurs autres offres autour des graphiques virtualisés, du rendu 3D et des publicités pour les jeux mobiles et de bureau. Il se passe beaucoup de choses chez Unity aujourd'hui, et c'est très agréable d'y travailler. Il y a des moments un peu stressants, mais on s'amuse beaucoup à cause de toutes les choses intéressantes qui se passent.
Quelle est la meilleure partie de la direction d'une équipe QA ?
Ce qui est le plus intéressant, c'est de pouvoir interagir avec tous ceux qui ont des connaissances spécifiques. Tout le monde arrive avec des expériences différentes. Certains sont plus doués que d'autres pour le codage. D'autres ont des compétences plus poussées en matière de processus, pour savoir comment trouver les lacunes, entrer et faire le travail de collage...
Si vous n'êtes pas familier avec ce terme, consultez la rubrique "glue work". Et je suis sûre qu'il y aura beaucoup d'informations à ce sujet. C'est sur ces points que j'aime travailler avec l'équipe, trouver les points forts de chacun, les exploiter et déterminer le type de travail qu'ils veulent faire, leurs objectifs de carrière et la manière dont nous pouvons nous aider mutuellement en tant qu'équipe.
Tout cela est très intéressant pour moi et, honnêtement, j'espère que c'est ainsi que fonctionne chaque équipe, quel que soit le travail qu'elle accomplit. Mais parfois, ce n'est pas le cas, et c'est ainsi que j'aime aider mes équipes à travailler. Je préfère le coaching et la gestion axée sur le service plutôt que la microgestion. Je m'efforce de demander comment je peux aider l'équipe à faire son travail, et c'est ainsi que j'ai appris à gérer et que j'aime travailler avec eux.
Quelle est la meilleure façon de faire travailler ensemble les testeurs et les développeurs ?
Il y a tellement de réponses à cette question. En fait, je pense qu'il est préférable de consulter un testeur, un QA ou un coach pour déterminer la meilleure approche. Cela peut aller du jumelage à un modèle de coaching où ils ont des questions sur les tests et où vous les aidez à formuler leur réponse. Il peut s'agir d'une approche plus pratique et d'un travail avec les développeurs dans le code, ou simplement d'une démonstration du code et des tests entre les développeurs et les testeurs.
Je pense que chaque équipe a sa propre dynamique et sa propre façon de travailler. Cela dépend également du modèle de livraison de logiciels que vous utilisez. Pour un atelier de développement de logiciels, la situation sera différente selon qu'il utilise le modèle Waterfall, Agile, Scrum ou Kanban, et tout sera donc un peu différent. Si vous avez travaillé dans un style particulier, la première réaction est parfois d'essayer d'utiliser à nouveau ce même style. Mais je pense que d'une équipe à l'autre, la façon dont j'ai travaillé avec les développeurs est différente. Cela dépend vraiment de la dynamique de l'équipe, et le fait d'en tenir compte, de travailler avec eux et d'établir une base de confiance est plus important que n'importe quel style particulier.
Quels sont les livres que vous recommandez sur la qualité et les tests, dans le domaine de l'ingénierie ?
Je recommande "Rocket Surgery Made Easy".
"Ne me faites pas penser à la facilité". Tout cela est axé sur la conception UX et les cas d'utilisation généraux... Une très bonne base pour les testeurs.
"The digital quality handbook", un très bon document de référence, en particulier pour le travail dans les environnements en nuage et les environnements mobiles. Je le recommande vivement.
Et nous ne pouvons pas ne pas mentionner les tests agiles de Lisa Crispin et Janet Gregory. Il y a aussi plus de tests agiles et des tests agiles condensés. Je pense qu'il y a quelques autres livres après celui-ci, mais si vous devez en acheter un, c'est celui-là.
Même si vous n'êtes pas un manager, même si vous êtes un responsable QA ou quelqu'un qui interagit avec beaucoup d'équipes ou beaucoup de personnes, "Les cinq dysfonctionnements d'une équipe". Définitivement recommandé pour les responsables ou les managers. Quel que soit votre rôle, cette formation est vraiment utile pour poser les bases d'un meilleur fonctionnement de votre équipe.
"Mesurer ce qui compte". Si vous cherchez à savoir comment mesurer les choses, qu'il s'agisse d'indicateurs de performance clés ou de mesures, ce livre est un très bon ouvrage de base. Il parle des OKR, mais je pense que vous pouvez tirer beaucoup de choses de ce livre parce que souvent les gens mesurent les bugs, et le bug est un symptôme d'un problème plus important. (...) Ce livre aide vraiment à clarifier beaucoup de choses.
Et si vous êtes quelqu'un qui a du mal à savoir comment entamer une conversation ou comment avoir la bonne conversation : "Crucial conversations". Je ne saurais trop recommander ce livre. Il s'adresse à tous ceux qui travaillent dans le domaine des logiciels ou de la technologie. Je pense que nous n'avons pas suffisamment l'habitude d'avoir la bonne conversation. C'est là que nous nous heurtons à des réunions répétées. Nous ne retirons pas d'actions des réunions. Nous ne trouvons pas la clarté. Ce livre m'a vraiment aidé à me concentrer sur ce que je demande et sur la raison pour laquelle j'organise une réunion. Quelque chose d'aussi simple qu'un ordre du jour peut vraiment clarifier et rendre la réunion utile. Ce livre traite de ce genre de choses et de la manière dont vous pouvez faire en sorte que chaque conversation soit pertinente et utile.
Pouvez-vous nous dire une chose que tout nouveau testeur de logiciel devrait apprendre ?
(En rapport avec le livre '30 choses que tout nouveau testeur de logiciels devrait apprendre')
Heather Reed et moi-même avons été les éditeurs de ce livre. Ce fut une expérience extraordinaire ! Je pense qu'il s'agissait d'une première en classe lorsque nous l'avons fait à l'origine, et qu'elle a été répétée un peu partout.
La nouvelle chose que j'ajouterais est d'apprendre le tableau et la loi de Conway, car ces deux éléments sont en quelque sorte imbriqués. De nombreux éditeurs de logiciels développent leurs logiciels sur la base du diagramme. Si vous comprenez le diagramme, vous pouvez trouver où se situent les lacunes en matière de qualité et quel est le problème initial. En se concentrant sur ce point, il est possible de trouver des solutions faciles à mettre en œuvre pour améliorer rapidement la qualité d'un produit, simplement en comprenant comment le produit est assemblé et qui est impliqué dans quelles parties du produit. Une fois que j'ai appris la loi de Conway, ma façon d'aborder les tests a changé, car ce n'est pas nécessairement aux développeurs que je dois m'adresser pour résoudre ce problème. Ce sont peut-être les responsables des produits ou les experts en la matière qui doivent comprendre ce dont ils ont réellement besoin et en faire part aux ingénieurs.
Les ingénieurs et moi-même, en tant que testeur, QA ou coach, pouvons même mieux l'expliquer et construire un processus autour de l'amélioration de cet élément particulier, surtout s'il se trouve en haut de la file d'attente des plaintes des clients. Cela demande un peu de recherche et de compréhension, mais une fois que l'on a compris, il est beaucoup plus facile de voir les schémas à un niveau macro qui pourraient affecter la qualité plutôt que simplement la fonctionnalité ou le code. (...) Si vous arrivez à le comprendre, vous pourrez faire des choses extraordinaires en matière de qualité.
Quelle est l'erreur à ne pas commettre au début d'une carrière en tant que QA Manager?
Je viens d'écrire une newsletter sur les questions que vous devez poser en tant que nouveau manager – vous pouvez le consulter à l'adresse suivante : melvitechie@substac.com. La question que vous devez absolument poser dans toute nouvelle situation de management est la suivante : "Quelles sont les attentes par rapport à votre rôle ? Êtes-vous le responsable du recrutement ?" Vous devez savoir comment retenir les gens. Si vous devez licencier quelqu'un, vous devez comprendre comment cela fonctionne et quel est le processus à suivre avant même de mettre les pieds dans une équipe ou de le découvrir assez rapidement.
L'autre chose est de comprendre ce que l'on attend de vous. Êtes-vous là uniquement pour gérer des personnes ? Êtes-vous une personne de contact ? Doit-on s'attendre à ce que vous fassiez du travail d'IC, de contributeur individuel, en plus de votre travail de gestion ? Êtes-vous censés développer la carrière de vos collaborateurs ? Y a-t-il des choses que vous devez réaliser en tant qu'équipe et qui vont affecter les KPI ou le résultat net, ou tout autre élément de ce type ?
Il suffit de poser des questions sur ce que l'on attend du poste et de s'assurer que c'est très clair (...) parce que j'ai constaté, surtout avec les nouveaux managers, qu'on ne sait pas exactement quelles questions poser.
Au bout de trois ans, je savais que si j'acceptais un autre poste de direction, c'est à cela que cela ressemblerait. Il est important de bien comprendre le travail que l'on entreprend et de ne pas faire de suppositions. Dans le cas contraire, les gens peuvent essayer d'élargir votre champ d'action, ce qui peut conduire à redéfinir le projet. Si vous travaillez en freelance, cette redéfinition peut modifier votre mode de rémunération. En tout cas, vous devriez l'être, surtout s'il s'agit d'un travail supplémentaire. Si vous êtes employé à temps plein, cela peut modifier la quantité de travail que vous essayez d'accomplir, et vous devez être en mesure de vous y opposer. Les nouveaux managers doivent s'enquérir des attentes, des règles à suivre et d'autres informations importantes. Sans cela, ils risquent de se sentir perdus et de ne pas s'acquitter efficacement de leurs tâches de gestion.
Racontez-nous une anecdote sur votre carrière de senior technicienne ?
Au cours des deux dernières années, j'ai travaillé en tant que technologist en gestion de l'ingénierie, dans des domaines plus généraux. Cela m'a permis de prendre des éléments du domaine de la qualité qui étaient très étroits, très spécifiques, et de les appliquer à des projets plus vastes, plus importants, qui peuvent s'étendre à des unités commerciales et même parfois à des entreprises.
J'ai tout fait, des tests QA , évidemment, à la gestion des programmes et des produits, et parfois à l'analyse, et analyse des données. J'ai vraiment élargi le champ de mes connaissances et de mes activités pour les rendre plus stratégiques et plus utiles à la qualité en général.
J'aime combiner les processus et la technologie pour aider les gens à tirer le meilleur parti des deux. J'aime aussi créer des canaux de communication qui n'existaient pas auparavant, en fonction du produit, et observer les résultats étonnants qui en découlent. La communication est le fondement de la création de logiciels. Je pense que l'idée d'être dans un coin et de coder ou d'écrire des tests est en grande partie un héritage du passé. Nous devons sortir de cette situation et être beaucoup plus collaboratifs que ce à quoi nous sommes habitués. L'industrie reflète également cela en ce moment.
J'aime cette collaboration. J'aime pouvoir aider les gens, les réunir et parler de problèmes qui les passionnent et me passionner avec eux pour la résolution de ces problèmes.
Quelle est la meilleure rencontre que vous ayez eue et qui vous a inspiré pour votre carrière ?
La meilleure rencontre a eu lieu au Ministry of Testing Test Bash, à New York en 2015. J'ai rencontré Abby Bengsinger, qui est maintenant un grand gourou dans le monde DevOps et qui fait toutes sortes de choses formidables. À l'époque, nous étions tous les deux testeurs et nous avons eu une très longue conversation jusqu'à 3 heures du matin sur la croissance et le développement de carrière et toutes ces choses.
Si je ne l'avais pas rencontrée, si je n'avais pas eu une très bonne perspective et si je n'avais pas compris ce que je voulais faire, c'est-à-dire devenir consultant et travailler pour ThoughtWorks, je ne pense pas que je serais ici. Je pense que je ferais autre chose, ou que je serais encore peu connue. Abby et le groupe Ministry of Testing ont donc eu un impact considérable sur ma carrière.
Ensuite, j'ai rencontré des gens comme Lisa, Janet, Ash Coleman, Martin Henier, Angie Jones et Alan Page – avec qui j'ai travaillé pendant un certain temps. Je pense que toutes ces rencontres n'auraient pas été possibles sans cette rencontre avec Abby. Je pense qu'elle s'en rend compte, mais j'aime bien le lui dire de temps en temps. C'est une raison importante, et elle m'a beaucoup aidée à ce moment-là.
Avez-vous un dernier mot à dire ?
Que vous soyez un testeur fonctionnel mobile, quel que soit le type de testeur que vous êtes, ne vous inquiétez pas tant d'être licencié ou de perdre votre emploi. Vous avez des compétences et des capacités que vous pouvez adapter à de nouvelles technologies, à de nouvelles idées, à de nouveaux flux de travail. Vous devez cependant être ouvert à cette idée.
Je pense que j'ai souvent rencontré des testeurs qui ont fait le même type de travail pendant plusieurs années. Lorsque les choses commencent à changer dans l'entreprise, ils sont parmi les premiers à partir parce qu'ils ne se sont pas adaptés aux nouveaux programmes, aux nouveaux logiciels qui aident à tester. Un très bon exemple à l'heure actuelle est la tentative de compréhension de l'IA et de son impact sur les tests, car il n'est pas question d'éliminer les tests. Il faudra des experts en IA pour aider à programmer les modèles et comprendre ce qu'ils font, et c'est un tout autre rôle, mais cela pourrait toujours faire partie des tests et de la compréhension. Quelles sont ces données ? Ces données sont-elles bonnes ou mauvaises ? Comment éviter que ces données ne modifient les algorithmes et les modèles que nous utilisons tous les jours pour nos logiciels ?
Pour faire carrière en tant que testeur, il faut garder l'esprit ouvert et savoir s'adapter. Si je peux vous donner un autre conseil, ce serait celui-là : si vous vous lancez dans les tests de logiciels, apprenez tout ce que vous pouvez et continuez à vous adapter. En dehors des rôles de développement, les tests QA et les aspects de qualité ou les rôles de qualité sont probablement les plus faciles à intégrer. Mais à partir de là, vous devez vraiment réfléchir à votre carrière et à la manière dont vous pouvez l'adapter pour aller de l'avant et envisager d'autres rôles également. Vous n'êtes pas obligé de rester dans le domaine des tests. Je vous recommande simplement de faire preuve d'ouverture d'esprit et de capacité d'adaptation. Ne vous inquiétez pas de l'évolution de votre poste, car vous allez le faire évoluer et vous pourrez toujours évoluer vers un autre poste. Il vous suffit de garder un œil sur ce que fait l'entreprise ou de trouver une autre entreprise qui fait quelque chose qui vous permet de progresser dans votre carrière. C'est ce que je recommande.
.png)
