Commencer une pratique de Qualité seul n’est pas facile. Le véritable défi est d’apporter de la valeur à la mission et aux objectifs de l’organisation en alignant les différentes parties prenantes sur les bonnes priorités.

Lina Kulakova est la fondatrice de la communauté QualityTalks. Elle a rejoint tb.lx pour relever le défi de piloter la qualité dans l’entreprise. Dans cette interview, nous partageons son point de vue, ses apprentissages et ses convictions basé sur son expérience.

Nous couvrons les thèmes suivants à travers cet entretien :

• Comprendre le contexte, l’objectif et la mission de l’entreprise
• Aligner les attentes des parties prenantes sur la valeur à délivrer
• L’importance de développer les habitudes, l’autonomie et la collaboration
• Comment mettre en œuvre des boucles de feedbacks rapides pour expérimenter
• Sélectionnez la bonne architecture et les technologies au service des objectifs
• Concentrez-vous sur la prévention plutôt que sur la réaction
• Utiliser la mesure en ayant conscience de ses limites

Suivez la QE Unit pour accéder au contenu exclusif et régulier de la communauté.

Lina Kulakova

Antoine : Peux-tu commencer par te présenter ?

Je suis dans le monde de la QA depuis plusieurs années maintenant. Je n’ai pas de formation en ingénierie, je suis surtout devenue passionnée par l’informatique et  l’assurance qualité. J’ai commencé dans le testeur manuel, puis j’ai rapidement élargi mes connaissances car j’étais motivé par tout ce que je voyais au quotidien. J’ai essayé d’apprendre différentes techniques rapidement. 

Comme j’étais généralement la seule personne de Qualité de l’équipe, j’avais du mal à obtenir des feedbacks et du partage sur mon travail ; il n’y avait personne avec qui échanger directement. C’est pourquoi j’ai lancé QualityTalks en 2017 en tant que communauté portugaise d’assurance qualité. Nous fournissons maintenant du contenu à un public plus large en anglais. Nous étions habitués aux rendez-vous mensuels. Il a évolué en ce moment avec plus de talks, d’interviews et une chaîne Youtube.

En parallèle, j’ai assumé le rôle de responsable QA dans une startup suisse. J’ai dû définir la stratégie à partir de zéro, créer tout le département QA, puis développer l’équipe. C’était un énorme défi pour moi, j’ai beaucoup appris. Depuis, j’ai découvert mon positionnement et une autre passion au sein de l’assurance qualité : définir, penser et aligner la stratégie en se concentrant sur les grandes priorités des entreprises.

En plus de cela, je contribue à Portuguese Women In Tech (PWIT) en tant que mentor, participant à différentes initiatives. Nous travaillons à attirer plus de femmes dans le monde des technologies.

Antoine : Intéressant ce que tu partages sur la transversalité et l’apport de valeur de la Qualité à l’entreprise dans son ensemble. 

C’est un exercice très intéressant. Je dois réussir à me mettre de côté, penser à la situation dans son ensemble. C’est très intriguant et stressant à la fois. Je pense que c’est aussi pour ça que j’aime tant le domaine de la Qualité. C’est vraiment gratifiant quand on commence à en récolter les fruits.

Antoine : Je comprends que ton entreprise – tb.lx – est basée à Lisbonne et fait partie d’un groupe plus important dans le secteur des transports. Peux-tu nous en dire un peu plus ? Quels problèmes essayez-vous de résoudre, pour qui ?

J’apprécie vraiment tb.lx. Nous sommes dans le sweet spot, une startup au sein d’un grand groupe. Nous avons toujours la liberté de faire des choix technologiques, d’expérimenter, d’apprendre rapidement dans un environnement agile. En parallèle, nous avons l’appui d’un très grand groupe, Daimler. Notre mission est de créer des solutions de transport durables pour les camions, fusos et cargos Mercedes-Benz.

Tb.lx se concentre sur une grande mission et je suis très fier d’en faire partie. Nous travaillons sur le transport durable pour notre avenir, ce qui est crucial. Nous nous concentrons sur les camions et les bus, qui sont inévitables et nécessaires pour livrer de la nourriture et des marchandises. C’est incroyable de faire partie d’une entreprise avec cet objectif.

Notre entreprise n’est pas si grande, nous sommes plus de 60 personnes et continuons à grandir. Nous sommes basés à Lisbonne avec une forte culture de la confiance. Nous travaillons dans des configurations hybrides entre travail présentiel et remote, en mettant l’accent sur la diversité. Les membres de notre équipe viennent d’horizons divers et sont également basés en dehors de Lisbonne.

Antoine : Votre challenge était de mettre en place une pratique Qualité au sein de l’entreprise, pourquoi ?

L’entreprise disposait d’une solide équipe d’ingénieurs, déjà consciente du besoin de qualité. De plus en plus, nous voyons dans différentes entreprises le besoin de qualité apparaître plus naturellement. Je dirais que l’image a beaucoup changé au cours des deux dernières années. Alors qu’il y a quelques temps nous devions convaincre les gens que nous avions besoin d’un service de qualité, maintenant c’est plus naturel pour tout le monde. C’est comme un terrain d’entente mutuel que nous avions besoin d’une équipe d’assurance qualité.

Bien que l’équipe d’ingénierie ait commencé à faire des choses sans que quelqu’un soit officiellement affecté en tant que QA, elle a estimé qu’elle aurait besoin de quelqu’un pour canaliser ses efforts et structurer l’approche. L’entreprise et l’équipe grandissaient avec un nombre croissant de livraisons. Ils pensaient qu’ils auraient besoin de plus de structure et bénéficieraient d’un défenseur qui les guiderait tout au long du processus de qualité. Par exemple, ils voulaient créer des produits plus fiables. 

Antoine : La croissance a entraîné le besoin de quelqu’un avec une perspective plus large, reliant les points entre les différentes perspectives de valeur. Cette culture de la qualité a-t-elle été intégrée dès le départ ? Comment tout cela a-t-il commencé ? Quelles ont été tes priorités pendant les 90 premiers jours ?

Justement, j’ai poussé pour que la qualité n’apparaisse pas comme un contrôleur de police dans l’entreprise. Je ne suis pas le gardien, la personne qui dit “go” ou “no go”. Je suis là bien plus pour favoriser la collaboration des équipes, leur donner plus de responsabilités, les guider quand ils en ont besoin.  

Ce n’était pas facile pour être honnête. Bien qu’ils aient mis en place des tests unitaires et d’intégration, nous devions préciser le terrain d’entente entre nous. Cela a commencé par aligner où nous sommes et où nous voulons être, quel type de tests nous avions besoin, quel niveau de test. Nous avons aligner les conventions de nommage et le vocabulaire, ce n’était pas une tâche facile. Les tests d’intégration signifient différentes choses pour différentes personnes ; certains les appelleraient de bout en bout. La première chose était vraiment de définir ce vocabulaire partagé entre nous tous.

“La première chose était vraiment d’aligner un terrain commun entre toutes les parties prenantes : notre situation actuelle, un vocabulaire partagé, leurs attentes.”

Lina Kulakova

Après cela, je me suis focalisée à comprendre ce que nous voulions livrer et quelles étaient les contraintes. Il n’y avait pas de solution universelle. Nous devions comprendre le point de vue et les motivations de l’entreprise. Je devais analyser et ressentir ce dont nous avions besoin et quelles seraient les principales difficultés. Je savais que nous voulions offrir les meilleurs produits pour le monde Daimler, avec un degré élevé d’interactions avec une variété de parties prenantes. 

C’était comme une étoile pour moi parce que je savais que nous avions besoin de quelque chose capable de fournir un bon niveau de communication entre différentes personnes.

Antoine : J’imagine que la gestion des relations était clé. Comment as-tu abordé ce sujet ? As-tu plutôt privilégié des méthodes 1to1 ou plus collaboratives pour aligner une définition partagée de la qualité et de la valeur ?

J’ai dû interagir avec un large éventail de parties prenantes, pas seulement en 1to1. Je pense que beaucoup de gens s’attendaient à ce que je commence. Au moment où j’ai démarré, tout le monde partageait déjà avec moi pour réserver des rendez-vous, pour certains en groupe. Je me suis présenté et ait partagé quelles étaient mes priorités.

Mes premières semaines et premiers mois ont été dédiés à bien comprendre ce que nous voulions offrir et délivrer en tant qu’entreprise. Puis, lorsque j’ai eu une compréhension très claire de notre vision, de nos objectifs et de nos valeurs, j’ai progressivement rencontré plus de parties prenantes du monde extérieur de tb.lx, à savoir Daimler.

Antoine : Quelles étaient vos priorités de Qualité ? Comment les avez-vous alignés sur les priorités de l’entreprise ? Comment avez-vous priorisé l’effort ?

Une priorité majeure pour la Qualité était d’aligner les priorités par la communication. Nous sommes une entreprise avec des acteurs internes et externes. Nous devions garantir que nous étions tous sur la même longueur d’onde et parfois la communication n’est tout simplement pas facile. Nous sommes dans une configuration à distance ; nous travaillons dans des endroits différents et avons des fuseaux horaires différents. L’objectif était d’aligner tout le monde sur la même vision de ce que nous livrons et de ce que nous devions livrer.

À partir de là, j’ai concentré notre stratégie davantage sur les TDD (Test Driven Development) et ATDD (Acceptance Test Driven Development) pour m’aligner avec l’équipe de développement. Nous avions vraiment besoin que leurs efforts se concentrent sur ce que le client attendait de nous. J’ai trouvé un outil qui n’est pas bien connu ou largement adopté, KarateDSL. C’est une variante de Cucumber avec Gherkin. Karaté à une couche de complexité en moins que Cucumber ; il est donc beaucoup plus simple d’implémenter, de coder et d’écrire des tests.

J’ai pu garantir que nous irions plus vite grâce à cet avantage de simplicité. De plus, nous aurions une documentation vivante avec des cas de test clairs que tout le monde au sein de l’équipe comprendrait. C’était aussi le cas pour les développeurs. Même s’ils ne participent pas quotidiennement à la pratique de l’assurance qualité, ils peuvent rapidement ouvrir les tests et comprendre exactement ce que nous testons.

“La qualité est un catalyseur de boucles de rétroaction rapides de communication entre les différentes parties prenantes.”

Lina Kulakova

C’était notre point de départ : aligner avec les partenaires métier sur ce qu’ils attendaient exactement de nous, puis transformer cela en tests. À partir de là, l’équipe de développement pouvait travailler et opérer leur magie. Ils ont la liberté de choisir les meilleurs langages de programmation, frameworks, etc., tant qu’ils garantissent de répondre aux exigences de nos parties prenantes.

De plus, la performance est essentielle car nous collectons des données massives de la flotte de véhicules ; nous avons investi dans des tests de performances avec Gatling. Il est possible de lier les scénarios KarateDSL aux tests de performance pour garder un alignement. La sécurité est également critique. À cet effet, nous essayons de couvrir différents types de domaines de sécurité. João Proença partage divers thèmes en QA et en particulier sur le risk storming.

La sécurité et la performance étant si importantes pour nous, nous avons travaillé à intégrer des processus de prise de risque au sein de notre équipe. Nous commençons tout développement par un risk-storming, puis partageons avec les parties prenantes comme les Product Owners pour définir les différents tests. Nous poursuivons le développement et les parties de code, y compris l’analyse statique et de sécurité à différents niveaux. Maintenant, je me concentre sur les moyens systématiques d’assurer la sécurité en implémentant un framework DevTestSecOps plutôt qu’un simple framework de QA.

Antoine : Pour les parties prenantes tel que le product owner, l’impact de la qualité a été de partager leurs attentes et de s’impliquer dans des sessions de risk storming. Quels ont été les résultats les plus visibles et créateurs de valeur de leur point de vue ?

L’entreprise voit et valorise un alignement transversal du travail. Le changement le plus important que nous ayons pu remarquer concerne l’équipe d’ingénierie elle-même. Ils n’avaient aucune idée précise de ce qu’on attendait d’eux. Ils étaient principalement concentrés sur l’ingénierie, la technologie et la conception de solutions plutôt que sur les perspectives plus globales des entreprises et des clients. Par exemple, ils ont commencé à réfléchir beaucoup plus à ce qui peut arriver dans des scénarios de panne de camion. C’était quelque chose qui n’arrivait pas dans le passé. Ils ont maintenant une bien meilleure structure, comme une recette et des processus clairs sur lesquels ils peuvent composer, ajouter des ingrédients et réaliser des variations.

Nous travaillons à étendre notre pratique à tous les niveaux et à la maintenir pendant que nous grandissons. Une chose que j’aime dans notre contexte, c’est que nous acceptons d’itérer et d’échouer rapidement si nécessaire. Nous nous concentrons sur la réalisation de boucles de feedback rapides. Nous vous garantissons d’avoir le temps de réfléchir au problème et de le résoudre correctement. Une statistique indique que si vous testez les livrables immédiatement, il faut 4 minutes à un développeur pour corriger le bug. Mais si vous découvrez comme un jour après, cela deviendra déjà une heure et ainsi de suite jusqu’à des semaines s’il est trouvé encore plus tard. Plus nous découvrons le bug tard, plus il prend du temps pour tout le monde.

Aujourd’hui, l’équipe de développement connaît exactement les tests attendus qui doivent être au vert lors de la réalisation des changements ; cela fait partie de notre Definition of Done. Ensuite, nous complétons notre approche par des tests exploratoires pas forcément systématique et qui ne sont pas de la responsabilité de développement. La principale valeur est qu’ils peuvent constamment vérifier par eux-mêmes les résultats des tests. 

Antoine : Les métriques et les KPIs peuvent être à la fois puissants et dangereux dans leur utilisation. Utilisez-vous des métriques et des KPIs spécifiques pour soutenir votre initiative de Qualité ?

Nous aimerions et nous en utilisons quelques unes. Notre objectif principal était de garantir que nous disposions du framework DevTestSecOps et des tests automatisés, en divisant mon temps entre les équipes. Assurer l’autonomie des équipes était un point clé à considérer. Nous suivons par exemple les builds nocturnes et les résultats des premiers tests effectués. Je dirais que nous ne sommes pas encore fortement axés sur les métriques. 

“En fin de compte, les processus de qualité doivent devenir naturels et faire partie de notre culture.”

Lina Kulakova

Nous mettons davantage l’accent sur la prévention que sur la réaction, pour agir le plus tôt possible dans le processus. Nous mesurons la couverture à différentes couches et à différents niveaux de test, y compris ceux d’acceptation. Nous essayons également de garantir que les erreurs et les bugs que nous trouvons sont bien plus nombreux que ceux trouvés par nos parties prenantes.

Notre objectif principal est d’assurer une routine solide, des normes de qualité et des habitudes dans l’organisation. Il s’agit de s’assurer que nous privilégions la qualité, le partage entre les équipes et que les équipes soient claires sur ce que l’on attend d’elles. En fin de compte, le processus doit devenir plus naturel et faire partie de notre culture.

Antoine : On voit régulièrement les questions de qui doit faire les tests. Je pense que cela dépend du contexte. Tu as partagé certains éléments du vôtre ; les tests sont-ils mis en œuvre par les ingénieurs de développement par exemple ?

Je suis d’accord avec toi, ça dépend du contexte. Dans notre contexte, nous avons une équipe d’ingénieurs qui se concentre sur les tests unitaires et d’intégration, et je suis plus concentré sur les niveaux de tests fonctionnels. Bien que je ne sois pour l’instant que le seul QA pour différentes équipes au sein de l’entreprise, ma concentration sur l’ATDD apporte une réflexion critique aux tests. Les tests eux-mêmes en Gherkin ne sont pas très longs à écrire ; nous passons plus de temps à écrire les cas de test. Je collabore avec divers product owner pour m’aider à réfléchir à ce sujet.

Une pratique impactante que nous réalisons est la validation de la définition du test par le Product Owner (PO), soulevant de nouvelles questions en effectuant des peers reviews. Les développeurs vérifient le code lui-même et le PO vérifie les cas d’utilisation. Toutes les étapes sont ouvertes par toute l’équipe. C’est une vraie collaboration entre nous. Même si j’en suis la responsable au global, tout le monde contribue. 

Antoine : Vous avez choisi un outil plus utilisable et compréhensible pour l’équipe plutôt qu’une parfaite boîte à outils technologique. C’est un excellent exemple d’une décision de qualité à valeur ajoutée au vu des objectifs d’entreprise. Quels défis as-tu rencontrés ? Quels ont été les enseignements de ce processus de changement culturel ?

Nous avons eu beaucoup de choses qui n’ont pas fonctionné comme prévu pour plusieurs raisons. Tout d’abord, je dirais que l’un des plus grands défis est de travailler avec beaucoup de données. Il s’agit de données de diffusion en direct et de technologie de live streaming J’ai dû parler à différentes personnes pour comprendre comment nous pouvions le tester.

Le live streaming n’est pas facile. Vous ne pouvez pas prédire exactement ce que vous recevrez. Cela complique la façon dont vous êtes censé le tester correctement. L’une des plus grandes difficultés que j’ai dû résoudre était que nous n’avions pas de véritable véhicule disponible pour les tests. C’était un problème pour définir l’ensemble de données sur lequel nous pouvions nous appuyer.

Nous devions garantir suffisamment de bancs d’essai et de données d’essai. Un apprentissage clé était que nous n’étions pas en mesure de tout tester et de garantir des exécutions rapides et fiables. Nous avons dû construire des jeux de données représentant différents scénarios. Nous nous sommes appuyés sur des ingénieurs pour obtenir des scénarios réalistes et constituer nos ensembles de données.

Le test d’une architecture en streaming n’est pas facile. Je me souviens que j’ai commencé à écrire des tests. Au début, c’était du gâchis car cela ne fonctionnait pas bien dans la majorité des cas. J’ai essayé de réaliser quelques tests avec Postman, mais en raison de la technologie distribuée, il s’agit beaucoup moins d’une vérification de demande/réponse synchrones. Après une série d’itérations rapides, nous avons fini par créer le cadre et trouver les solutions appropriées.

Antoine : Quels sont les principaux enseignements de cette expérience ? Quels conseils donnerais-tu à quelqu’un qui commence comme toi en tant que Head of QA ?

Tout d’abord, nous devons comprendre ce que nous devons livrer. Je pense que parfois, nous voulons nous concentrer directement sur les tests automatisés, implémenter des pipelines et mettre en place beaucoup d’automatisation pour chaque version. Mais on peut vite oublier pourquoi on teste en premier lieu. C’est quelque chose à garder à l’esprit à toutes les étapes.

Lorsque j’ai choisi l’outillage par exemple, j’évaluais en permanence la capacité de collaboration, étant l’une de nos priorités majeures. J’ai rejeté certains choix qui ne répondaient pas à ces exigences en effectuant des expérimentations rapides. Je prenais régulièrement du recul sur ce que j’essayais d’accomplir. Nous pouvons rapidement nous soucier trop des tableaux de bord et des outils sophistiqués plutôt que de la valeur que nous créons.

Ce n’est pas une compétition. Il ne s’agit pas d’avoir le maximum de tests automatisés. L’automatisation vient par exemple supprimer les tâches répétitives et ennuyeuses. Ce n’est pas le but en soi. Nous ne visons pas un nombre particulier de tests automatisés. Parfois, c’est tellement intéressant que nous pouvons rapidement nous concentrer sur l’optimisation de la technologie au lieu de la vraie qualité.

Antoine : On devrait tous mettre un post-it et un rappel quotidien avec « Revenir sur le pourquoi ». En terminant par une note personnelle, as-tu du contenu inspirant, comme des citations, des livres, même en dehors de la qualité ?

Ce n’est pas une réponse facile, non par manque de références mais au contraire, beaucoup de choses m’inspirent.

Je me sens beaucoup inspiré par l’équipe que j’ai. Il n’y a pas d’entreprise, d’équipe ou de circonstances parfaites ; nous savons que l’herbe est toujours plus verte ailleurs. Il est crucial de travailler dans un environnement où vous pouvez faire confiance à vos gens et ils peuvent vous faire confiance. Vous devez être capable de communiquer clairement, d’y arriver et de faire avancer les choses. Avoir le bon contexte, l’équipe et des objectifs d’entreprise est essentiel pour moi.

Il y a aussi le monde extérieur. J’ai la communauté QualityTalks et je me sens très inspiré à la fois par les conférenciers que je reçois et par les personnes qui y assistent. Ils posent des questions, expriment leurs doutes et recherchent du mentoring, de l’aide ou des conseils. Cela m’inspire beaucoup pour continuer à pousser et à apprendre. Parfois, j’apprends plus à partir de questions plutôt que de donner des informations. Recevoir une formation et poser des questions est pour moi un excellent moyen d’apprendre. Il a également tendance à tout mettre dans une perspective différente. C’est une super expérience d’avoir cette communauté QualityTalks.

“Avoir une mission est essentiel. Nous devons avoir un impact dans ce monde.”

Lina Kulakova

En fait, j’aime partager des idées avec différents professionnels du domaine comme João Proença. Je connais aussi une personne inspirante qui s’appelle Antoine, je ne sais pas si vous le connaissez dans la QE Unit 🙂 Les gens de l’informatique, en particulier de la qualité, sont accessibles. J’ai récemment partagé par exemple avec Lisa Crispin qui était très motivée à faire une interview ensemble. 

Les livres de Lisa Crispin et Janet Grégory m’inspirent beaucoup. Angie Jones est également une grande source d’inspiration. J’ai tendance à rechercher le leadership et l’inspiration non technique. Les sujets et les questions techniques changent ; un jour c’est DevOps, Cypress puis d’autres outils. Je suis beaucoup plus motivée par un objectif, s’alignant sur le pourquoi et l’impact. Il est important pour moi d’avoir un impact.

En développant une application mobile, vous pouvez aider quelqu’un à accéder à un service particulier qu’il ne pouvait pas auparavant. En travaillant sur une plateforme de voyage, vous aidez les gens à réaliser leurs rêves. J’ai l’immense honneur de pouvoir transformer l’avenir du transport et c’est incroyable. Je recherche des personnes qui m’inspirent en termes de motivation, pourquoi nous sommes dans le QA en premier lieu. Les personnes que j’ai mentionnées ici sont des personnes formidables dans ce domaine et, surtout, une grande source d’inspiration.

Antoine : Avoir une mission permet de maintenir nos efforts même dans les moments difficiles. Je crois sincèrement que nous partageons cette importance du but tant pour les individus que pour les organisations.

Absolument. En fin de compte, nous avons la capacité de faire des choses que nous aimons, qui est la qualité pour nous. Nous avons également la possibilité de choisir entre différentes entreprises. Quand il y a un vrai lien avec notre objectif, cela apporte tout le potentiel de ce que nous faisons.

Cela est également essentiel pour le mélange de la vie professionnelle et personnelle. Pour moi, c’est plus un mélange qu’un équilibre car je n’arrête pas la qualité après 17 ou 18 heures. J’assiste régulièrement à différentes conférences, podcasts, me documente. Avoir un  but est essentiel. Nous devons avoir un impact dans ce monde.

Antoine : Merci Lina d’avoir partagé ton expérience avec humilité. Nous apprenons en partageant et en construisant avec les communautés ; J’apprécie vraiment ce que vous avez partagé et remercie également tb.lx pour cette ouverture d’esprit. Bon voyage dans la construction de votre pratique d’assurance qualité au cours de votre croissance, et tout le meilleur avec QualityTalks.

Vous pouvez suivre Lina sur Linkedin, Twitter et les QualityTalks.

Ressources utiles

KarateDSL https://github.com/intuit/karate 

João Proença (2020). Qu’est-ce que la prise de risque ?Comment débuter sa carrière Qualité ?Comment définir une stratégie QA ? Entretiens de qualité.

Lisa Crispin, Janet Grégory (2008), Agile Testing : A Practical Guide for Testers and Agile Teams. Addison Wesley.

Lisa Crispin, Janet Grégory (2019), Le Test Agile Condensé. Addison Wesley.

ATDD et BDD quelle différence. https://latavernedutesteur.fr/2019/02/25/atdd-et-bdd-quelle-difference/ La Taverne du Testeur