Comment appréhender l’Assurance Qualité pour un produit ?

Photo par SpaceX via Unsplash

Les Clubs Métiers du Hub sont une initiative née de la volonté de créer un savoir commun au sein des startups investies par les fonds d’investissement en capital risque de Bpifrance. Le principe est simple :  réunir des experts d’un même métier pour croiser les points de vue et les pratiques. Le Club Produit a été initié en janvier 2021 par notre Operating partner Octave Letellier. Les publications issues des sessions du club sont principalement destinées aux numéros 1 des équipes produit des participations Bpifrance.

Dans ce nouveau rendez-vous du Club Produit du Hub, la réunion des expert.e.s du Product Management, destinée à créer un savoir commun au sein des startups investies par les fonds d’investissement en capital risque de Bpifrance, il est question d’un domaine souvent négligé mais pourtant fondamental pour un produit : la QA.

Pour rappel, la QA (pour “Quality Assurance”, ou Assurance Qualité en français) est, comme son nom l’indique, la manière de garantir la qualité des développements et des fonctionnalités réalisés. Pour qu’in fine, le produit puisse être utilisé sans désagrément par les utilisateurs.

Pour faire la lumière sur ce sujet et son lien avec les fonctions Tech et Produit, deux experts de chez Livestorm, la plateforme française d’engagement vidéo sans téléchargement ni plug-in, partagent leurs retours d’expériences concrets :

• Tom Forlini, le CTO et cofondateur de Livestorm
• Farah Chabchoub, ex-head of QA de Livestorm et aujourd’hui CPO de Votelab

Commençons par raconter la petite histoire de la QA au sein de Livestorm, avant d’aborder les outils qu’ils utilisent en la matière puis les façons dont les équipes QA œuvrent concrètement pour faciliter le travail des product managers et des ingénieurs.

Pourquoi et comment Livestorm à mis en place sa QA ?

La question de la QA est venue spontanément aux équipes de Livestorm. “Plus on signait de nouveaux clients et plus on constatait une augmentation des bugs et du support clients à effectuer”, se rappelle Tom Forlini.

Les temps de recette partaient aussi à la hausse avec, au lancement de chaque nouvelle fonctionnalité, un test de l’ensemble de la plateforme à faire manuellement qui prenait des heures. Sachant qu’à chaque fois qu’un bug était trouvé, il fallait recommencer le test manuel du départ !

De quoi miner le moral des équipes et provoquer une perte de confiance dans le produit, aussi bien du côté des clients que des salariés.

Conséquence ? Trois solutions ont été adoptées :

• Mise en place de tests automatisés

Première chose : reproduire tous les tests manuels de manière automatique. Un bon début mais il fallait encore les lancer manuellement.

• Adoption de l’intégration Continue (CI)

Ceci afin, justement, d’automatiser le lancement des tests automatisés à chaque changement de code. Et donc de retester plus simplement le produit à chaque modification. “Un gros changement qui a provoqué un gain flagrant”, souligne Tom. 

• Changement des processus

Enfin, dernière solution non technique : la modification des cycles et des processus de release. Autrement dit, finis les lancements le vendredi soir par exemple, afin de pouvoir intervenir rapidement en cas de découverte de bugs.

Quelle est la philosophie de la QA chez Livestorm ?

Avec du recul, voici les trois points que retient Tom Forlini à ce sujet :

• La responsabilisation des ingénieurs 

Chez Livestorm, les mises en production ne se font pas en mode cascade où chacun fait sa part puis passe le relais à l’équipe suivante. Produit – design – développement – QA – Infrastructure. Non.

Au sein de la plateforme vidéo, l’ingénieur va être impliqué tout au long de ces étapes. Et donc, concrètement, faire lui-même la QA et écrire les tests automatisés. Ces derniers font donc partie de la définition of done dans le funnel de delivery. Pas de mise en production si pas de test désormais.

« Au début, comme on n’avait pas d’ingénieur QA, c’était les ingénieurs par défaut qui le faisaient. Et on s’est rendu compte que c’était une chose très bénéfique qu’il fallait garder.« 

Tom Forlini, CTO et cofondateur de Livestorm

A noter que cette philosophie est similaire côté produit : les PM participent grandement aussi à la QA. “Le département QA est là pour les accompagner et donner une vision stratégique de la QA au sein des équipes produit”, indique Tom. “On les sensibilise par exemple à ce qui doit être automatisé au niveau des tests”, ajoute Farah.

• L’importance de l’automatisation 

Comme évoqué précédemment donc. Tom remarque que tous les tests sont faits avec le même langage que dans le backend pour limiter les frictions. Et n’oublie pas de mentionner que cela prend également un peu de pédagogie pour faire comprendre l’intérêt de ces tâches !

• La faculté à se donner les moyens

En effet, un des points importants à ses yeux, c’est de ne pas rester bloqué sur ses anciens process. En l’occurrence, sur des problèmes de tests manuels dans le cas de Livestorm.

Pour effectuer ce changement et passer à l’automatisation, l’équipe y a passé entre un et deux mois. A ne faire que ça, en laissant le reste de côté. Un investissement qui a des résultats concrets sur le long terme.

“Maintenant, je peux dormir la nuit et le week-end sans souci !”, note avec une réelle satisfaction Tom Forlini.

LES RESTITUTIONS DÉTAILLÉES DE CES ARTICLES SONT DOCUMENTÉES DANS L’ESPACE NOTION DÉDIÉ AUX NUMÉROS 1 DU PRODUIT DES PARTICIPATIONS BPIFRANCE

SI VOUS AUSSI VOUS ÊTES UNE PARTICIPATION BPIFRANCE, N’HÉSITEZ PAS À NOUS CONTACTER POUR ACCÉDER À CET ESPACE AINSI QU’AU SLACK CPO

Lors de l’arrivée du 1er ingénieur QA, Tom rappelle que toute la QA était déjà automatisée. “Sa mission, c’était de tout remettre en ordre et de bien remettre au propre les bonnes pratiques et les guidelines en la matière”.

• L’apport majeur de la QA : faire de la productivité un moyen d’innovation

Parler de QA revient évidemment à aborder la question de la qualité… Mais qu’entend-on par qualité ? Cette notion est en effet très subjective. D’autant que la qualité, à elle seule, ne peut pas être un but en soi.

Pour Farah, l’objectif est surtout d’être orienté plus vers l’innovation que sur la gestion de problèmes et de bugs. C’est-à-dire que c’est ce vers quoi doit être essentiellement porté la productivité des équipes.

Et cette dernière, que l’on peut aussi appeler vélocité, comprend trois composantes : l’innovation donc (comme la création de nouvelles fonctionnalités), la gestion des problèmes (les bugs par exemple) et l’amélioration continue.

Toute la question est donc d’arriver à mettre le curseur au maximum sur l’innovation et de réduire au minimum les efforts sur les deux autres composantes. Voyons comment.

• Les actions à mener aux différents moments clés pour le produit

Prenons le cheminement traditionnel de la conception d’un produit : Les spécifications – le développement – les tests – la mise en production – et enfin la détection de bugs potentiels. Les équipes QA peuvent intervenir à deux phases distinctes (shift left / shift right).

1) Shift left : le 1er momentum avant d’arriver en production 

Ici, les équipes QA peuvent se concentrer sur deux KPI :

• Le time to market : le temps passé entre l’étape des spécifications et la mise en production
• Le time to release : le temps entre le développement et la mise en production

L’objectif étant évidemment d’arriver à réduire ces durées sans compromettre la stabilité et la qualité du produit. Voici ainsi comment peuvent concrètement intervenir les équipes QA à ce stade :

Avant le développement

• En validant la testabilité des spécifications. Dit autrement, que les ingénieurs aient tout ce dont ils ont besoin quand ils vont se mettre à développer la fonctionnalité et les tests automatisés (par exemple, l’ensemble des scénarios d’usage utilisateurs possibles) 
• En participant à la définition de la stratégie de tests. Il ne sera jamais possible de tout automatiser donc, ici, l’idée est de voir comment les clients utilisent le produit pour mettre les automatisations aux endroits les plus importants et critiques pour le business.
• En mettant en place l’infrastructure de test. On parle ici de tout l’aspect outillage et process. Tout ce qui pourra être épargné aux développeurs.

Après le développement

• • En assurant le suivi de l’automatisation. En vérifiant que les guidelines ont bien été suivies et que le processus est bien toujours efficace.
  • Par la détection, la remontée et l’assurance de la résolution des bugs

• Par l’audit et l’analyse des processus de delivery

2) Shift right : au-delà de la mise en production

En « Shift Right », les KPI à suivre ne sont plus les mêmes et l’on va regarder :

• Le time to detect : le temps de détection des bugs à partir de la mise en place d’une nouvelle fonctionnalité.
• Le time to recover : le temps de résolution des bugs à partir de leur détection.

Un autre point à vérifier à ce stade : la façon dont sont remontés les bugs. Soit de manière réactive (par les clients) soit de manière pro-active (avant que ces derniers les remontent).

Les équipes QA peuvent, ici, mener différentes tâches :

• Participer à la mise en place et l’amélioration du monitoring fonctionnel. Chez Livestorm, on regarde le nombre de participants par événement, s’ils arrivent à y accéder sans problème, le nombre d’appels au support par événement… Autant d’indicateurs pour suivre la fiabilité de l’expérience client.
• Assurer le suivi de la fiabilité de l’expérience client en production
• Gérer les incidents (internes ou externes)

• Les gains engendrés par les équipes QA

En conclusion, Farah voit trois bénéfices majeurs à son département :

1) Une meilleure gestion du risque

Les équipes QA ne vont pas éliminer le risque mais elles seront capables d’identifier où il faut concentrer les efforts pour les réduire.

2) Une meilleure productivité

Elles participent aussi à ce que les équipes et les clients gagnent en confiance dans le produit. Ce qui aura, on l’a vu en introduction, un effet sur la motivation et la productivité des premières… et la satisfaction des derniers.

3) Une baisse du churn

En effet, un produit « pionnier » et stable entraîne une meilleure rétention de ses clients… voire du bouche à oreille positif et des recommandations !

Les outils QA utilisés chez Livestorm / La stack des outils QA chez Livestorm

• Les outils pour assurer la qualité du code

Codacy : Pour réaliser une revue systématique de la qualité du code (performance, code inutilisé, sécurité, détection de complexité dans le code etc.). “Il ne faut pas se baser à 100 % dessus mais cela donne un bon ordre d’idée”, précise Tom. 

Commit Convention : Livestorm utilise le conventional commit. “Quand on commence à avoir plus d’une quinzaine d’ingénieurs sur la code base, il devient important d’avoir ce type de guide, estime Tom. Cela apporte une certaine fluidité et qualité, notamment au niveau de l’investigation des bugs pour les retracer plus rapidement”.

• Les outils pour faciliter l’intégration continue

Circle CI : Le plus facile à mettre en place dans le cas de Livestorm. Mais il en existe beaucoup d’autres. 

Github Action : Pas aussi puissant que Circle CI mais plus simple à utiliser. Permet d’améliorer la qualité des commits et d’automatiser des petites tâches plus rapidement, comme mettre des labels automatiquement. 

Gits en « pre-commit » : Livestorm a créé certaines validation pour éviter de déclencher toute les CI payantes en ligne.

• Les outils pour la gestion du design system

Oui, car on sous-estime aussi parfois que le design system peut avoir une influence sur la qualité, notamment côté front end.

Storybook : Un sorte de dictionnaire de tout le design system pour une meilleure synchronisation entre les équipes design et ingénieurs. Cet outil est d’ailleurs intégré directement dans leur CI. Quand un développeur va ajouter un composant, une synchronisation avec Storybook permettra de vérifier que tout est correct.

Chromatic : Un outil qui fait de l’UI review (à l’image du code review) pour détecter les changements de composants côté front-end afin de garder une bonne cohérence globale.

Percy.io : Outil utilisé pour les régressions visuelles. Alors que Storybook ou Chromatic analysent un seul composant à la fois, cet outil permet de détecter les incohérences lors d’un changement de composants ou d’ensemble de composants.

Cypress.io : Fonctionne en complémentarité de l’outil précédent pour vérifier la cohérence, en faisant des tests d’intégration du front end.