Avez-vous déjà eu honte de mettre un produit de mauvaise qualité dans les mains des utilisateurs ?
Avez-vous déjà abandonné un produit défectueux ?
Avez-vous déjà manqué de temps pour construire un produit de qualité ?
Avez-vous déjà manqué de compétences ou de bons outils ?
Quelle frustration !!!
Avec mon ami Benjamin Butel, nous avons exploré des causes possibles aux freins que peuvent rencontrer les développeurs et testeurs dans leur quête de la juste qualité.
Merci à Zoé Thivet pour son illustration avec toujours autant d’humour et sa relecture !
Le développeur, un testeur qui ne s’assume pas !
Contrairement aux idées reçues, le développeur est beaucoup plus engagé dans la qualité et particulièrement en contexte agile.
Quelles sont les contextes qui lui sont défavorables ?
« Je n’ai modifié qu’une ligne de code »
« C’est juste une montée de version mineure d’une librairie qu’on utilise très peu »
Une sur-confiance du développeur dans sa modification peut être lourde de conséquence. Pour se protéger de cela, le développeur devrait s’appuyer sur des tests unitaires et une analyse d’impact pour déterminer un périmètre de tests pertinents qu’il pourra effectuer sur son poste directement. Et c’est avec ces nouvelles informations qu’il pourra transmettre au testeur le risque de sa modification. Et parfois, le risque étant plus élevé que les bénéfices, il sera plus sage de ne pas conserver le changement.
« Je suis dev, pas testeur ! »
C’est une réplique souvent prononcée chez les développeurs. Pourtant la qualité est de la responsabilité de tous les acteurs de l’équipe produit, y compris ce dernier. Le testeur est en partie responsable de ce détachement du développeur envers le test et le fantôme du cycle en V persiste ce qui fait perdurer ce clivage.
« La qualité n’est jamais un accident, c’est toujours le résultat d’un effort intelligent »
John Ruskin
Nous pouvons ajouter « et collectif« . L’intelligence collective au sein d’une équipe est à notre sens primordiale pour atteindre la juste qualité. On retrouve cette vision dans le Modern Testing créé par Alan Page et Brent Jensen (Source en fin d’article). L’approche consiste à mettre le test dans les mains des développeurs avec un coaching de la qualité par le testeur.
« Je ne peux pas tester, je dois livrer »
« J’ai pas le temps de tester »
Le temps est relatif et sa perception est celle que l’on va bien vouloir lui donner. Priorisez la production de valeur, n’hésitez pas à en faire moins et mieux !
Des petits incréments (MVP) vous permettront de livrer souvent, rapidement et de qualité. Le développeur pourra profiter de ce petit périmètre pour mettre en œuvre des approches de clean code, de clean architecture, de TDD, etc. .
L’enjeu est de faire bien du premier coup et de disposer de tests unitaires dès le développement et non a posteriori.
Même avec des efforts significatifs et un bon volume de tests unitaires, la qualité n’est toujours pas au rendez-vous.
Challengez la pertinence de vos TU !
Couvrent-ils les cas d’usage métier ?
Vous protègent-ils des régressions ?
La méthode TDD peut vous aider à créer du code maintenable et des TU efficaces, indépendants les uns des autres et moins couplés aux détails d’implémentation de votre code (usage de double de test: mock, stub, spy, dummy, fake, …).
Le « mutation testing » est une technique pour évaluer l’efficacité de vos TU.
Le principe est de générer des bugs dans le code (les mutants) et de vérifier que vos TU tuent tous les mutants.
Des outils d’analyse de la couverture peuvent aussi aider à critiquer vos TU.
Pour conclure cette première partie, nous pouvons affirmer qu’il faut être dur avec le code et doux avec le développeur !
C’est pourquoi le testeur est un bon allié.
Voyons maintenant les freins que le testeur peut rencontrer dans ce même objectif de la qualité.
Le testeur, ce dernier rempart faillible!
A l’instar du développeur, nous sommes aussi confrontés à la mauvaise qualité.
Comment en sommes-nous arrivés là ?
« Oh, je l’avais pas vue pas celle-là »
Nous avons tous déjà vécu cette situation désagréable suite à la remontée d’une anomalie de production.
Ceci est le résultat du biais cognitif « La compensation du risque » qui consiste à se comporter de manière imprudente lorsqu’on minimise un risque.
Une surconfiance dans vos tests auto et vos tests manuels, une mauvaise analyse d’impacts ou encore des délais courts peuvent vous conduire dans ce biais.
A l’inverse, ce même biais peut nous amener à faire de la surqualité.
La difficulté est de trouver le bon curseur entre l’effort de test et le risque résiduel en sortie du test (Voir courbe de Crosby).
Appuyez-vous sur votre équipe pour réduire cette difficulté.
« Je n’ai pas le temps ni le budget de tout tester !!! »
Lorsqu’il s’agit de timing ou de budget pour tester, les causes sont généralement organisationnelles. S’il manque réellement du temps pour tester au regard des impacts et risques, il faut trouver un moyen pour l’obtenir. Définissez des critères d’acceptation de votre produit. Par exemple, en SCRUM, ces critères font partie de la definition of done de vos US.
Le manque de temps peut provenir d’un périmètre de sprint trop ambitieux. N’hésitez pas à challenger ce dernier en définissant un MVP.
Cela vous garantira de livrer une grande valeur en premier.
Privilégiez des sprints courts et un périmètre adapté! (Voir l’expérience de Jean-Pierre Lambert sur le sprint d’un jour).
L’automatisation de tests souffre aussi de ce sentiment de manque de temps.
Là encore, définissez avec votre équipe la valeur que cette automatisation va vous apporter.
Angie Jones préconise d’ajouter les tests auto au definition of done. Cela vous obligera à déterminer un périmètre d’automatisation réaliste et de le réaliser durant le même sprint que l’US.
C’est aussi les préconisations de John Ferguson Smart dans ses articles sur son blog anglais.
« J’ne sais pas tester ce truc ! »
Votre logiciel est complexe : données de test complexes ou inexistantes en production, conditions d’exécution proches de la production, conditions environnementales particulières comme l’altitude, la température, la pression, combinatoire élevée, etc. .
Dans de telles situations, prenez du recul pour casser cette complexité. Les niveaux unitaire et intégration sont adaptés pour adresser les règles de gestion de votre logiciel. Des reproductions d’environnement de production (plateformes ou simulateurs) peuvent vous aider à réaliser une partie de vos tests en condition quasi-réelle.
Enfin, le crowdtesting ou le beta-testing sont aussi de précieux alliés pour tester en situation réelle.
La méconnaissance métier apporte également son lot de difficultés ! Même si l’auto-documentation est un levier, certains métiers demanderont de se former: mentor, coaching, cours, formation en ligne, etc. .
« j’n’ai pas les bons outils »
Nous sommes bientôt en 2021 et une multitude d’outils existe sur le marché pour nous aider dans notre activité de test: outils pour aider dans les tests unitaires, les tests des API, la simulation de navigateurs, la gestion de test, le reporting, les tests de performance, les tests de sécurité, les tests d’utilisabilité, etc. .
Avant de choisir un outil, identifiez bien votre besoin.
Quelle problématique ce dernier doit-il résoudre ?
Ensuite benchmarkez les outils et sélectionnez-en quelques uns qui semblent répondre à votre problématique.
Evaluez ces outils dans votre contexte concret afin de déterminer celui qui sera le plus approprié.
Puis prenez le temps de définir son intégration : déploiement, formation des personnes qui vont utiliser l’outil, documentation, limitations, adéquation avec la testabilité du produit sous test, etc. .
Un mauvais usage vous fera perdre plus de temps qu’en gagner.
Quelques exemples:
- Un outil d’automatisation des tests IHM nécessitera sûrement de disposer dans l’application sous test d’attributs dédiés sur vos composants graphiques afin d’avoir des sélecteurs maintenables et pérennes. (Voir cet article de HIGHTEST sur l’automatisation des tests de régression)
- Un outil de gestion des tests nécessitera de former les utilisateurs et de définir des pratiques communes d’utilisation.
- Un outil de gestion des données de test nécessitera sûrement de respecter des règles de confidentialité (RGPD).
Le collectif au service de la qualité
Dans cet article, Benjamin et moi-même avons exploré différentes raisons pour lesquelles les activités de test ne sont pas priorisées. Cela ne doit pas pour autant en être des excuses, car c’est la qualité de votre produit qui en fait les frais.
L’objectif n’est pas d’en déterminer un coupable mais de lever les raisons qui aboutissent à cette situation. Celles-ci sont souvent d’ordre
organisationnel et il suffit parfois un léger ajustement pour que la situation s’améliore.
Nous sommes convaincus que le collectif et la collaboration sont des armes pour combattre cette fatalité de la non-qualité !
Il appartient à chacun de nous d’agir et contribuer à réduire ce bordel !
Sources et articles connexes
Test en contexte agile:
- « Le test en mode agile » de Christophe Moustier
Modern testing (en anglais):
- Les 7 principes du Modern testing
- Une présentation détaillée de ces 7 principes par Melissa Eaden
- « Let’s Focus More on Quality and Less on Testing » par Joel Montvelisky
TDD, Clean code, mutation testing, double de test (en anglais pour la plupart):
- Le blog d’Uncle Bob avec divers articles très intéressants
- Le livre de Kent Beck, « TDD by example « .
- Le TDD expliqué en français par Michael Azerhad
- Article sur les tests doubles (Mocks et stub) par Martin Fowler
- Un éclairage sur les différents tests doubles en français de Remi Lesieur
- deux articles de Vladimir Khorikov sur les tests doubles: « When to mock » et « Unit testing dependencies « .
- Une description du mutation testing par Octo
Biais cognitifs
Une belle série d’articles signés Stéphane Colson sur les biais cognitifs: partie 1, 2, 3 et 4.
Test automatisé
La conférence d’Angie Jones, « How to Get Automation Included in Your Definition of Done » (Un compte PRO est requis pour voir cette vidéo sur le site du Ministry of Testing).
MVP, MLP, MMP
Le Scrum Life « C’est quoi un MVP ? Rationaliser le succès de son produit avec le Lean Startup » vous donnera une première vision de ce qu’est un MVP.
Cet article anglais de Ellen Merryweather vous apportera aussi une définition du Minimal Lovable Product.
Des définitions simples de MVP, MLP et MMP proposées par Prisca Denizeau sur LinkedIn:
