Bitoo

Retour sur la Paris Test Conf 2021

Léa Beaumier

Léa Beaumier

Comment mettre tout le monde d’accord sur la gestion des bugs ?

La qualité chez Lifen – les difficultés

Lifen (entreprise proposant des solutions numériques auprès des hôpitaux) n’a pas encore de QA sur toutes ses missions teams (ou pas assez). Du coup tous les sujets « QA » ne sont pas uniformes au sein de toutes les équipes.

Présence récurrente de bugs, surtout ceux difficiles à prévoir :

  1. Système de santé complexe
  2. Faire face à des setup particuliers (vieux SI, utilisateurs pas technophiles)
  3. Se mettre à la place de l’utilisateur qui est médecin ou secrétaire médical
  4. Connexion avec les autres outils des professionnels de santé

Mise en place de la Fireline

L’entreprise étant en pleine croissance il a fallu la structurer en créant différents pôles de travail.

Pour optimiser la gestion des bugs une Fireline a été mise en place.

Fonctionnement

La Fireline est en quelque sorte une équipe annexe créée uniquement pour tester les bugs.

L’escalation manager fluidifie les échanges entre les équipes tech et non tech et centralise les demandes pour les membres de la Fireline.

Chaque équipe envoie un membre dans la Fireline pour une semaine.  Les membres de l’équipe restent sous la responsabilité de leur manager respectif.

Communication
  • Zoom : Weekly et Daily
  • Slack : Chan Fireline et @Fireline-Team
  • Jira : Slack est pour la communication, les demandes et bugs passent par Jira (tag fireline, fireline_missionteam…)
  • Notion : CR Weekly + documentation process
Types de demandes traitées
  • Bug (uniquement d’un projet terminé ou lancé en prod)
  • Assistance (« Est-ce que c’est normal que… »)
  • Incident
  • Fix sécurité
  • Améliorations pour réduire les 4

Rôle de la QA

Pour le moment il n’y a pas encore de testeur Quality Assurance dédié à la team Fireline

  • Chaque Fireliner gère le fix et sa Mise En Production selon le fonctionnement/release management de sa mission team
  • Si un testeur QA se trouve dans la mission team, le fireliner travaille étroitement avec lui pour tester le fix et la MEP

De manière générale

  • Le testeur QA garde un œil sur le flux entrant des cartes BUG
  • Il peut aider à identifier le bug plus rapidement par ses connaissances métier
  • Surtout après les MEP afin de pouvoir réagir rapidement s’il identifie un lien avec la MEP

Feedbacks

Ce qui est principalement remonté c’est que la Fireline libère du temps de focus sur le build. Les développeurs sont en build et n’entendent pas forcément parler des soucis de run. Ou alors de très loin si ils sont envoyés en renfort sur un sujet. Finalement ils peuvent se concentrer sur le build. Ils sont pas dérangé sans arrêt : Ils ont leur collègue dédié à ça. Et comme c’est sur des durées assez courte (une a deux semaines) le développeur est moins exaspéré par la gestion des bugs car il sait qu’il reviendra ensuite à son projet.

Les membres du support de Lifen quant à eux précisent que la Fireline est très utile car on peut avoir une réponse très rapide a donner au client. La prise en charge est immédiate et les utilisateurs soulignent régulièrement la réactivité des équipes pour le traitement des bugs.

De Quality Assurance à Quality Assistance

Différences

Vincent, QE d’Open Classroom, a commencé par expliquer les différences entre Quality Assurance et Quality Assistance.

L’équipe de Quality Assurance s’assure de la qualité du logiciel en phase de test tandis qu’en Quality Assistance elle assiste les membres d’autres équipes tout au long du processus de conception. Son but est de faire grandir les équipes, les faire évoluer et finir par être dispensable.

Passer de l'un à l'autre

Pour effectuer ce changement il faut que des objectifs soient fixés et clairs pour tous.

Chez Open Classroom ils en avaient choisi trois : accélérer la livraison, supprimer les goulots d’étranglement et construire une culture qualité plus mature.

 

Cette transition implique également un changement de mindset important, l’équipe QA a donc été renommé en QE (Quality Engineering) et s’est attribué une mission découpée en plusieurs activités (Quality Assistance, Exploratory Testing, Test Automation et Observability) tout en mettant la communication au centre du processus.

 

Un travail important a été réalisé pour réorganiser les équipes et les projets, réduire le temps des tâches mais également arriver à un alignement dans la qualité et sa définition entre toutes les équipes.

Résultats

Au bout de 2 ans dans cette transition des résultats ont pu être observés. La réduction de 30% du temps d’un cycle de production, la disparition du goulot d’étranglement, des retours très positifs en interne et une indépendance des équipes au niveau du test.

 

Bien sûr la transition n’est pas terminée, loin de là. Open Classroom a atteint le premier des trois niveaux de maturité et d’autres initiatives sont à venir pour progresser encore dans la transition entre Quality Assurance et Quality Assistance.

Niveaux de maturité
  • Phase 0 : Quality Assurance
  • Phase 1 : Quality Assistance, tâche majoritairement assignée au QE
  • Phase 2 : Quality Assistance, tâche rarement assignée au QE
  • Phase 3 : Monitoring prod, améliorer la qualité
Initiatives futures
  • Passer plus de temps sur la définition de la solution
  • Accompagner les devs sur l’automatisation
  • Expliciter les pratiques
  • Adapter les outils

Pourquoi et comment livrer tous les jours dans un contexte agile ?

Nadia & Antoine, respectivement Quality & Test manager et Head of Architecture & Technology chez La Redoute ont commencé par introduire les différences entre la livraison in-sprint présente et celle journalière envisagée.

Méthodes de livraison

In-sprint
Avantages
  1. Meilleur alignement et organisation des sprint planning
  2. Moins d’effort temporaire sur la gestion des tests manuels
  3. Processus de déploiement plus simple
Inconvénients
  1. Décalage de la date de livraison suite à la découverte de bugs
  2. Débogage plus complexe d’un bug remonté en fin de sprint
  3. Prise en compte du retour client plus tardif
Livraisons journalière
Avantages
  1. Rapidité de livraison
  2. Déploiement plus industrialisé
  3. Process de qualité plus robuste et fiable
Inconvénients
  1. Charge quotidienne et besoin de réactivité
  2. Coût du test manuel important avant automatisation
  3. Gestion plus complexe de livraison

Mise en place

Les équipes de La Redoute ont donc fait le choix d’une livraison journalière pour contraindre le processus à l’excellence et mis en place différents principes pour se tenir au rythme exigeant de cette méthode.

 

Parmi ces principes, quatre se sont dégagés de par leur importance :

  1. Unifier la structure des services
  2. Faire des releases plus petites et rapides
  3. Mettre en place des exigences en amont de la chaîne
  4. Avoir une grande flexibilité en production
 

Ces principes ne suffisent cependant pas à garantir le bon fonctionnement de la livraison journalière, il faut également mettre en place une méthodologie outillé comportant en autres :

  1. Des process de release journalier bien détaillés
  2. Des dashboards de suivis
  3. Une maîtrise du temps d’exécution des campagnes
  4. Une gestion transverse du référentiel de test avec des règles définies
  5. Une communication fluide entre toutes les équipe orchestré par le QA lead

Résultats

Le changement de méthode de livraison et la réorganisation interne chez La Redoute ont permis une livraison rapide des nouvelles features, un focus sur l’expérience client, un feedback plus rapide et une meilleure satisfaction client.

 

En conclusion, livrer tous les jours permet de tester plus rapidement, force au learn de bout en bout, contraint l’IT à supprimer les facteurs limitant et implique une réelle organisation et contention de la dette.

Le « Clean Code » appliqué aux tests automatisés de la QA

Rija William nous explique comment nettoyer son code pour optimiser ses tests automatisés (tests qui s’exécutent sans l’intervention d’un humain, ici avec Cypress). Ils évoluent avec le produit, c’est-à-dire qu’un changement produit implique un changement des tests automatisés. Quand vous utilisez un framework de test automatisé il peut également y avoir des bugs générés par l’outil d’implémentation.

Définition du Clean Code :

  • Le code est propre s’il peut être compris facilement par tous les membres de l’équipe
  • Un code propre peut être lu et amélioré par un développeur autre que son auteur initial
  • Quand un code est compréhensible, il devient lisible, modifiable, extensible et maintenable.

Indicateur de mauvais code :

  • Scalabilité : plus on a de scénarios de tests, plus c’est difficile à gérer
  • Fragilité : un seul changement impacte plusieurs tests
  • Complexité : implémentation incompréhensible
  • Répétition : code de test dupliqué à plusieurs endroits

Recommandations :

  1. Évitez les descriptions trop longues avec des détails inutiles, nommez vos fonctions avec un nom significatif et mettez les arguments dans l’ordre. 
  2. Tracez les erreurs que vous pouvez tracer sans aller dans l’excès et traitez les erreurs que vous avez identifiés en amont.
  3. Évitez les excès de commentaires par ligne de code, non utiles et redondants. (Pour améliorer cela on peut utiliser le jsDoc)
  4. Créez des fonctions customisés pour améliorer la lisibilité et l’utilisabilité de votre code.
  5. Créez des règles de formatage et utilisez des linters pour vérifier qu’elles sont bien appliqués.

Retour sur expérience :

La revue de code est désormais plus rapide et plus fluide. Les tests sont plus stables, plus robustes et fiables. Il y a moins de faux négatifs et faux positifs.

Cela a pris 3-4 mois afin de mettre en place les règles pour uniformiser la façon d’écrire le code. Aujourd’hui si deux développeurs codent deux fonctionnalités différentes l’écriture sera similaire, pareil pour les fonctions grâce aux conventions de nommage et l’utilisation de termes techniques. Cela permet de retrouver très facilement si une fonction est déjà existante et donc la réutiliser pour un autre programme.

En travaillant sur du clean code on se force à améliorer sa méthode de travail et à penser aux autres :  on a moins tendance à se rejeter la faute lorsqu’on a du code mal écrit. Cela renforce l’esprit d’équipe !

Bonus :

Si vous travailler avec Visual Studio Code voici quelques plugins conseillés par Rila William. Ils permettent de résoudre les problèmes précédemment vus.

  1. Code Spell Checker : corrige les problèmes d’écriture, fautes de frappe
  2. ES6 : plugin permettant l’autosuggestion avec indentation par défaut
  3. ESLint et Prettier : combinaison entre les règles et le formatage du code

Examining the link between quality & customer experience

Différences

La Quality Assurance est une combinaison d’outils et méthode utilisée pour prévenir les défauts et s’assurer que le produit remplit les attentes de l’utilisateur.

Elle est basée sur deux principes, l’adaptation aux besoins et l’élimination des erreurs.

 

La Customer Experience quant à elle est basée sur la perception et l’impression qu’a l’utilisateur du produit (forgé par toutes les interactions avec le produit et la marque).

Elle est centrée sur les utilisateurs et le produit.

Lien

Le lien entre Quality Assurance et Customer Experience est très fort, il est important d’identifier pour qui est destiné le produit (à l’aide de segmentations et personas par exemple) pour pouvoir mettre l’utilisateur au centre de la qualité et renforcer la valeur de celui-ci.

L’équipe CE récupère régulièrement des KPI des utilisateurs via les feedbacks qui amènent à une meilleure compréhension de l’utilisateur, de ses envies et besoins.

La collaboration entre les deux équipes permet alors d’améliorer les tests, leur stratégie et par conséquent le produit final.

Elle doit être présente durant toutes les phases du projet, mais également après pour identifier et corriger les frustrations remontées dans les feedbacks.

Se concentrer sur l'utilisateur

Raphael nous explique qu’il faut faire de l’apprentissage constant une habitude, s’intéresser aux sujets en lien avec le produit, se mettre en position d’utilisateur et faire du beta-testing.

 

 

Il rappelle également que l’utilisateur à toujours raison (dans le sens où il n’acceptera pas d’avoir tort) et qu’il faut considérer ses plaintes comme des bugs à fixer et suivre la satisfaction de l’utilisateur.

 

Il partage également une liste de super-pouvoirs à développer que nous vous laissons découvrir ci-dessous.

  • Développer son argumentaire et ses propositions d’idées
  • Devenir un as de la communication et du travail d’équipe
  • Être à l’écoute, empathique
  • Travailler son objectivité et ses capacités d’analyse
  • Prendre les bons et mauvais feedbacks de la même façon

Environnements de tests dynamiques pour le Continuous Testing

Constat

Valentin fait le constat dans cette conférence que sur les projets de tests, les testeurs passent beaucoup de temps à attendre notamment par rapport aux environnements. Peu de temps est réellement consacré à l’action même de tester. Il présente ainsi la gestion des environnements dynamiques via l’intégration continue. 

Piste de résolution

La problématique est de que certains systèmes sont liés et nécessitent d’avoir des composants ou des dépendances externes avec des jeux de données associés. Il est donc nécessaire d’isoler les applications sous tests et retirer les dépendances externes. Ceci permet de générer un contrôle et une stabilité sur notre version en cours. La gestion des données en est ainsi facilitée.

Application

La mise en place d’environnements dynamiques de tests nécessite une orchestration avec Jenkins ou Circle CI par exemple. Premièrement, la mise en place de tests automatisés puis le déploiement de l’application avec une infrastructure as code (IAC) qui va construire le système. Ensuite l’utilisation d’une base de données virtuelle. Enfin, l’installation d’un service de stubbing qui va permettre de remplacer les éléments externes donc de simuler lors des tests des appels des sous-systèmes entre eux.  Tout ceci n’étant valable qu’avec une bonne communication entre les membres de l’équipe.

Hypercroissance et qualité ? C’est possible avec Docker & Gitlab CI !

Nathanael et Matthis de la société Agicap nous montrent ici comment  ils ont essayé d’améliorer leurs tests end to end dans un contexte d’hypercroissance. En effet Agicap (une startup lyonnaise qui a mis au point une plateforme de gestion de trésorerie) a doublé ses effectifs en un seulement un an.

Les différentes problématiques

Tests sur environnement déployé
Problématiques
  1.  Nécessite un environnement déployé
  2. Fige l’environnement le temps des tests
Pistes envisagées
  1. Rendre paramétrable les tests
  2. Possibilité de mettre en état l’environnement
Exécution Selenium
Problématiques
  1. Gérer les différentes versions d’OS et Chrome
  2. Comportement non reproductible entre local et CI
  3. Fiabiliser les sélecteurs
Pistes envisagées
  1. Fixer l’environnement et l’installation de Chrome
  2. Travailler sur des sélecteurs métiers et non techniques
Scénario avec compte utilisateur spécifique
Problématiques
  1. Long… Très long !
  2. Remettre en état entre chaque test
Pistes envisagées
  1. Paralléliser les tests
  2. Isoler les différents tests

Pistes de résolution

Conteneurisation (basée sur Docker) : Conteneuriser l’ensemble des applications pour éviter l’utilisation de différentes versions de Chrome et d’OS

Mise en état : Isoler les servies puis les dépendances. Utilisation de scripts d’utilisation.

Isoler : chaque test dans sa propre coquille grâce Kubernetes

Bilan

Rapidité : anciennement les tests étaient couteux et long à exécuter : (car ils n’étaient pas exécutés en parallèle). De plus il fallait remettre en état l’ensemble de notre backend à la fin de chaque test.

Fiabilité : car chaque test a son environnement dédié : ils ne sont plus embetés par cycle de déploiement ou QA du produit.

Flexibilité : Aujourd’hui il est possible de lancer les tests end to end quand ils veulent. Pour le moment ils sont schedulé à plusieurs moment de la journée pour avoir une boucle de feedback rapide mais à terme ils ne s’empêchent pas de les exécuter sur chaque Nuage Request ou chaque évènements sur leurs repostitorys.

Maitrise des couts : Grâce à Kubernetes ils utilisent des serveurs jetables : si un serveur n’est pas utilisé le schedule va le supprimer du pull. 

Petit plus : Les développeurs utilisent également les vidéos enregistrées en tant que démos pour présenter les features.

Ce qu'il reste à faire

  1. Amélioration de la User Experience pour les développeurs afin d’améliorer la boucle de feedback.
  2. Les sélecteurs sont beaucoup plus orientés métier mais il faut faire cela sur le long court, 100% des tests ne sont pas couverts.
  3. Utilisation future de Selenium grid : framework Selenium qui permet de déployer une germe Selenium avec différents navigateurs et différents OS afin d’exécuter des tests sur différentes version.

Visionner tous les talks

Partager cette publication

Partager sur facebook
Facebook
Partager sur twitter
Twitter
Partager sur linkedin
LinkedIn

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bitoo

Bitoo

error: Ce contenu est protégé !!