L’écosystème est en constante accélération et croissance. Il devient encore plus difficile de suivre le nombre de startups passant à l’échelle alors que des licornes apparaissent dans différentes parties du monde. Mais est-on capable de garder ce rythme à moyen terme ?

Le Quality Engineering présente un intérêt croissant pour les entreprises qui cherchent à offrir en permanence de la valeur à leurs utilisateurs. Ils doivent équilibrer l’expérimentation réussie d’expériences à valeur ajoutée tout en garantissant des fondations technologiques évolutives.

Ce défi du Quality at Speed ​​est plus facile à dire qu’à faire. Dans cette interview, Filipe Carvalho, Senior Engineering Manager chez TalkDesk, l’une des licornes du Portugal, partage son point de vue sur l’utilisation de la qualité pour relever de tels défis.

Suivez la QE Unit pour accéder à plus de contenu exclusif sur le Quality Engineering.

À propos de Filipe Carvalho

Filipe Carvalho est actuellement Senior Engineering Manager, à la tête des clusters de Developer Experience SRE et Core Platform Talkdesk. Il travaille en tant que lead dans plusieurs équipes dans le domaine SRE depuis mi-2019.

Auparavant, il a travaillé dans plusieurs entreprises comme Rocket Internet, Farfetch et Talkdesk en tant qu’ingénieur logiciel en test et spécialiste en CI/CD, soutenant les efforts de qualité pour différentes applications et stacks techniques dans leur ensemble. Il a également été impliqué dans plusieurs communautés telles que Porto Testers Meetup et des événements comme Commit Porto.

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

J’ai commencé comme la plupart d’entre vous en tant qu’ingénieur logiciel. La qualité a toujours été un sujet que j’aime beaucoup. J’ai commencé à travailler dans le domaine de la qualité fin 2014 en tant qu’ingénieur qualité axé sur l’automatisation des tests et des pipelines. Le contexte principal était sur le mobile pendant 3 à 4 ans. Ensuite, j’ai évolué vers différentes entreprises dans ce domaine.

Après un certain temps dans le domaine mobile, j’ai décidé de relever un défi différent en travaillant dans les applications back-end et front-end. De cette expérience, j’ai senti que je voulais relever un défi différent. Actuellement, je suis Senior Engineering Manager travaillant dans le domaine du Site Reliability Engineering (SRE).

Antoine : Une expérience large à la fois sur le front, le back et les opérations. Si tu prends du recul par rapport à ces expériences, quels problèmes principaux dois-tu régulièrement adresser pour améliorer la qualité des applications ?

Habituellement, la Qualité n’est pas un first-class citizen. Toutes les étapes de développement du logiciel doivent inclure la Qualité. Cela commence par le codage, le déploiement, le monitoring, etc. Il y a beaucoup de domaines à aborder, sans se limiter aux tests. Mais qu’est-ce que le test ? Est-ce qu’il s’agit de vérifications? S’agit-il de créer des contrôles automatisés ? Pense-t-on à la fonctionnalité et à la valeur qu’elle apporte au client ? Qu’est-ce que la Qualité ? C’est la première question à répondre avant de pouvoir cascader les techniques de test adéquates. 

Nous pouvons nous appuyer sur des résultats de tests, effectués manuellement ou automatiquement. Généralement, le code des tests automatisés manque lui-même de qualité. Son niveau de Qualité est aussi important que le code testé. Ce problème, le manque d’inclusion de qualité dès la conception, crée toutes sortes de problèmes de mise en œuvre par la suite.

En plus de cela, nous avons un problème de stratégie ; plus précisément, celui du manque de stratégie. Nous avons des projets d’automatisation qui commencent à se concentrer uniquement sur « l’automatisation ». Le fait est qu’il existe une application où les tests font partie de l’application. Ce n’est pas un autre ou un projet différent. Il doit être compris comme une partie intégrante de celui-ci. C’est mon point de vue sur l’inclusion de la qualité.

“La qualité fait partie du cycle de vie du développement logiciel. Elle doit être mise en œuvre au bon niveau à chaque étape.”

Filipe Carvalho

D’après mon expérience, les projets d’automatisation séparés ont tendance à être abandonnés, à mourir ou à changer régulièrement de périmètre. Il y a un manque apparent de stratégie et de concentration sur ce que l’équipe essaie d’accomplir. Cela correspond également à la tendance à fournir systématiquement du code au mieux au lieu d’un réel souci de la valeur livrée, en mettant de côté la qualité.

En fin de compte, lorsque nous discutons d’une mauvaise ou du manque de stratégie, nous allons vers le sujet des acteurs, de leur niveau de connaissances et de compétences. On constate par exemple sur le marché portugais une pénurie d’expérimentés de Quality Engineer. Ce n’est pas un problème de personnes; il y en a de bons et prometteurs avec du potentiel ; c’est plus un problème de reconnaissance et de besoin au sein de l’écosystème. Il n’y a pas assez de professionnels dans l’écosystème pour amener plus d’entreprises au niveau supérieur.

Cette carence est même négative pour les profils existants qui peuvent se sentir seuls et démotivés dans leur contexte. Ils auront tendance à chercher des environnements où ils pourront grandir. Nous voulons être avec des pairs dont nous pouvons apprendre beaucoup, sans être le seul professionnel de haut niveau. Certes, un senior peut toujours apprendre d’un junior, mais l’émulation est requise du point de vue de l’expertise et de l’apprentissage accéléré. 

Antoine : Si nous commençons notre SWOT sur la Qualité, quelles forces et faiblesses identifiées-tu ?

L’une des bonnes pratiques régulières que j’ai constatée est l’implication de l’équipe, sans cloisonner leurs priorités. Évidemment, nous pouvons avoir un ingénieur QA dédié mais cela ne signifie pas que la définition, la structuration et la mise en œuvre de la qualité seront meilleures qu’une équipe composée d’ingénieurs s’occupant de la qualité (et pas nécessairement dédiés à la qualité). Une whole-team approach to quality peut également être très productive. Le contexte est très important. Je crois que tous les ingénieurs devraient contribuer à la Qualité et grandir personnellement en améliorant leurs pratiques de Qualité.

J’ai vu bien fonctionner des revues de code axées sur la logique du code et ses implications. Cela signifie que les équipes ont déjà automatisé les revues triviales et moins intéressantes en se concentrant par exemple sur le formatage. Nous devons nous demander et améliorer la façon dont nous pouvons aider l’équipe à effectuer une meilleure revue de code. L’implication des ingénieurs qualité dans la revue de code s’est également avérée utile, encore plus, s’ils sont familiarisés avec le code.

En plus de cela, une équipe peut vouloir tester une fonctionnalité d’un collègue. Cela devrait être aussi simple que de vérifier le code et de l’exécuter sur notre machine ou dans le cloud. Cela signifie qu’une automatisation fonctionnelle doit être disponible. Parfois, nous avons juste besoin de faire une vérification du comportement de l’application avec des itérations rapides. La capacité d’effectuer rapidement et facilement ces vérifications est essentielle pour des boucles de rétroaction rapides, en exécutant l’application localement ou à distance.

Pour de nombreuses fonctionnalités, nous ne savons même pas si elles seront utiles à nos utilisateurs. Nous devons livrer rapidement pour apprendre et nous adapter plus rapidement en fonction de l’expérimentation. Dans de nombreux cas, les fonctionnalités ne seront activées que sur une petite partie du trafic.

Suivent ensuite, les faiblesses.

J’en ai aussi un peu parlé, mais toujours considéré la qualité et les tests comme du nice to have est un vrai problème. Si un développeur lance une fonctionnalité en réalisant qu’il aurait plus de confiance dans les tests unitaires et d’intégration par la suite, les choses commenceront à se casser. D’après mon expérience, si nous voulons livrer plus rapidement, nous sacrifions la Qualité à court terme mais nous nous heurtons alors au problème de ne pas pouvoir itérer par la suite. 

Un autre sujet est la difficulté des connaissances transversales à matérialiser les diverses implications des différentes pratiques. Nous pouvons difficilement être des experts dans tous les domaines. Nous pouvons avoir plus d’expérience dans le code, les tests, le monitoring, l’observabilité, les exigences. Nous avons besoin à la fois d’apprendre en permanence et de rester curieux tout en étant capable de collaborer avec différents acteurs. Parfois, nous pouvons simplement manquer d’expérience dans un sujet spécifique ; reconnaître un écart est la première étape pour le combler. 

Antoine : Dans ce contexte, quelles opportunités identifies-tu?

Je vois quelques opportunités. Premièrement, il y a beaucoup de motivation et d’intérêt dans ce domaine. On peut le juger contradictoire avec ce que j’ai dit précédemment sur les profils expérimentés. Le fait est que nous avons besoin de différents défis pour garder notre motivation. L’intérêt accru pour la Qualité crée plus d’opportunités pour les personnes désireuses d’apprendre et de grandir. Tout le monde a la possibilité d’en apprendre plus sur les domaines, avec beaucoup de contenu librement accessible.

Ils n’ont même pas besoin de beaucoup de contenu technique ou de connaissances préalables. Ceci est assez spécifique à la Qualité ; c’est assez différent pour un ingénieur logiciel qui doit approfondir une série de sujets plus techniques. J’ai vu de très bons Ingénieurs Qualité qui ne codent pas mais sont capables de comprendre, revoir, identifier le suivi et ses implications opérationnelles. La combinaison d’expertise fait réellement la différence. 

Parfois, la capacité de code est très appréciée pour un ingénieur qualité. Mais en réalité, ce n’est qu’une facette du rôle requis. Vous pouvez être bon en code mais coder la mauvaise chose. C’est pourquoi le code n’est pas la compétence principalement requise ; la pensée critique, la qualité et l’orientation métier sont des compétences tout aussi importantes.

Antoine : Et si on continue avec les menaces ?

Avec le temps, la rotation des profils qualifiés peut aider à partager les pratiques, mais ils ne sont plus là pour les accompagner ou encadrer l’équipe. Nous avons beaucoup d’ingénieurs récents dans la région, mais ils manquent d’expérience. Dans ce type de contexte, ils ne peuvent croître au niveau d’exigence et de compétences attendu. 

Un autre est la tendance à l’hypercroissance des entreprises. Nous avons beaucoup d’entreprises en croissance rapide, de startup à scaleup. En se développant rapidement, la qualité et les tests sont des choses qui commencent à s’effondrer en premier. Cela tend à mettre complètement la Qualité de côté à moyen terme. On retrouve cela dans l’expression vouloir quelque chose de « bon, de qualité et pas cher ». Habituellement, la qualité est le premier sacrifice. Le produit peut atteindre la valeur minimale attendue par les utilisateurs ; cependant, une série de problèmes internes commenceront à se matérialiser et auront un impact sur les opérations internes. Par la suite, des problèmes plus complexes de fiabilité, d’évolutivité et d’évolution apparaîtront, impactant véritablement l’expérience utilisateur.

Un autre point est que les méthodologies disponibles ne sont pas suffisamment comprises par les acteurs. Il y a beaucoup de contenu, de lignes directrices et de pratiques disponibles, ce qui est déjà une bonne base. Le problème est plutôt la compréhension et l’alignement de l’industrie sur ces pratiques. Habituellement, les gens saisissent partiellement l’idée et les mots à la mode sans comprendre les véritables implications et les changements qu’ils doivent mettre en œuvre. Il y a d’excellent contenus disponibles, mais les filtrer et les rendre utile dans un contexte d’entreprise est différent. Nous devons faire attention au flux constant de « nouveau » contenu. Une grande partie du contenu est réutilisé à partir du contenu existant.

Antoine : As-tu des pratiques spécifiques que tu as trouvé efficaces, ou au contraire, inefficaces dans ton expérience ?

J’ai tendance à aimer les pratiques systématiques. Certaines d’entre elles sont assez simples, nécessitant de petits changements mais étant porteuses de valeur. Lorsque nous avons une série de use-cases qu’un ingénieur logiciel choisit pour commencer son développement, pourquoi ne pas inclure les ingénieurs qualité dès le départ ? Il peut discuter de l’approche, poser des questions et également fournir un deuxième avis. Il peut partager les cas extrêmes les plus probables et discuter des scénarios utilisateurs, améliorant ainsi la sensibilisation et la mise en œuvre du développeur. Au final, cela réduit l’effort de reprise et accélère le cycle de développement, permettant des itérations plus rapides.

Une autre pratique intéressante est l’automatisation des tests pendant le développement de la fonctionnalité. Si l’ingénieur qualité discute avec le développeur, il peut coupler l’implémentation du test avec le code, permettant des interactions et des partages beaucoup plus fréquents. Lorsque nous parlons d’évaluation par les pairs, il s’agit d’une pratique très utile pour toute activité. Dans ce cas, l’application de la révision du code et du test est différenciante d’après mon expérience.

Le point suivant est celui du monitoring. Tout le monde peut avoir une idée de ce que nous devons surveiller pour nos utilisateurs et nos produits. Nous pouvons avoir une variété de rôles suggérant des améliorations. Nous pouvons avoir n’importe quel rôle capable de mesurer, visualiser et utiliser les données pour prendre des mesures correctives. Les acteurs n’ont pas forcément besoin d’être des profils techniques.

Antoine : Quelles sont les clés à retenir pour améliorer l’état de la qualité ?

Je dirais que chaque étape du cycle de vie du logiciel doit intégrer la Qualité. La qualité doit faire partie de chaque étape du processus, et non plus être considérée comme une option. La qualité doit être intégrée dès le début du cycle, avec l’implication continue de toute l’équipe. Pourquoi devrions-nous considérer la qualité ou les attributs de test séparément ? Cela n’a pas de sens pour les fonctionnalités que nous visons à fournir à nos utilisateurs. C’est comme poursuivre un objectif erroné.

La connaissance et l’importance de la Qualité devraient être vraiment diffusées plus tôt. Je parle même de la formation initiale et des universités. Je vois certaines écoles mettre davantage l’accent sur la qualité du code, la qualité informatique et la partie test de leur programme. C’est un signe positif pour l’avenir, où nous avons encore un long chemin à parcourir.

Tous les acteurs doivent être clairs sur le fait que leur mission et leur travail n’est pas uniquement celui du code mais d’apporter de la valeur à nos utilisateurs. Le code est un moyen d’atteindre ce point, mais pas le seul. Nous pouvons même exiger la suppression d’une fonctionnalité et de code pour y arriver. Nous avons tendance à oublier cette partie, aimant résoudre des problèmes complexes. Pour beaucoup d’expériences, nous devons exceller dans une seule chose. 

Antoine : As-tu des contenus que tu recommandes sur ces perspectives de qualité ou que tu as pu trouver inspirants ou utiles pour rester à jour ?

Même si je ne suis pas exclusivement sur des sujets Qualité, je partagerai comment j’aborde ce domaine. J’ai commencé avec plusieurs ressources différentes. Le blog de test de Google a été l’une de mes premières inspirations, avec des articles peu nombreux mais très profonds et influents. En plus de cela, je recommande le Ministry of Testing. Il existe de nombreuses ressources intéressantes provenant de nombreux testeurs et ingénieurs. Je vous invite à assister à un événement ou à la conférence Test Bash ; Je le recommande vraiment.

De plus, recherchez d’autres communautés et pairs dans votre région, ayant des intérêts communs. Vous pouvez généralement trouver un slack, un forum ou un groupe de rencontre à proximité. Vous serez en contact avec des personnes ayant des intérêts communs où vous pourrez échanger des points de vue, des difficultés et des priorités. Vous grandissez vraiment avec ces partages. Au Portugal, nous avons la QE Unit 😉 mais aussi le PTM & MoT à Porto, Quality Talks à Lisbonne. La plupart de ces événements ont été remote avec moins d’interactions, mais ils restent toujours utiles en tant que connaissances. J’ai organisé PTM pendant quelques années et j’ai gardé contact avec de nombreux contacts depuis cette époque. La discussion et le partage sont excellents pour votre croissance.

Pour ce qui est des livres, je recommande vivement “Crucial Conversations: Tools for Talking When Stakes Are High”. Il apporte de nombreux moyens et pistes actionnables pour communiquer plus clairement, avec plus d’impact et de valeur avec tous les groupes de personnes. La communication est vitale pour de nombreux postes. Pour un Ingénieur Qualité ou un Testeur, c’est également vrai. Les compétences en communication sont clairement un point essentiel de la performance ainsi que de la croissance personnelle.

Antoine : Merci beaucoup Filipe. Dans cette perspective large de la Qualité, ta vision et tes contributions sont utiles pour améliorer l’état de la Qualité. Je te souhaite un bon parcours de Quality Engineering, heureux de te revoir lors d’un prochain entretien ou table ronde.

Nous pouvons résumer l’entretien à travers MAMOS, le Quality Engineering Framework :

• Methods
  • Des méthodologies systématiques sont nécessaires pour inclure la Qualité au bon niveau à chaque étape du cycle de vie du logiciel.
  • Des méthodes simples mises en œuvre étape par étape peuvent faire une énorme différence si mise en place au plus tôt et appliquées à l’ensemble de l’équipe.
• Architecture
  • L’architecture et la technologie de nos produits sont les premières à souffrir lorsque la rapidité et le coût sont privilégiés. Mais au final, des fondations fragiles se traduiront par une expérience utilisateur dégradée. La qualité doit être défendue et intégrée par une argumentation solide, des exemples et des résultats.
• Management
  • Le rôle du leader est d’aligner tout le monde sur la création de valeur pour les utilisateurs, en prenant du recul par rapport aux seules questions d’ingénierie et de technologie.
• Organisation
  • Nous devons lutter contre les silos organisationnels en appliquant l’approche de toute l’équipe à la qualité à travers des rituels transverses systématiques.
• Skills
  • La pénurie de professionnels qualifiés renforce la nécessité de composer des expertises d’horizons divers, en gardant un esprit ouvert, curieux et collaboratif comme fondements.

En vous souhaitant une transformation réussie vers le Quality Engineering, la pratique consistant à contraindre chaque activité du cycle de vie du logiciel à une livraison continue de valeur à nos utilisateurs.

Suivez la QE Unit pour plus de Quality Engineering.