Nouvelle année rime avec bonnes résolutions !!!
Je vous propose d’en prendre une et d’améliorer vos connaissances sur les concepts de développement. En alliant compétence testing et développement, vous formerez une équipe de choc.
J’aborde dans cet article quelques compétences et méthodes clefs que tous développeurs et testeurs doivent connaitre pour produire des logiciels de qualité !!!
La complémentarité des deux métiers se situe sur la capacité du développeur à tester et la capacité du testeur à comprendre les concepts de développement.
Quelle est la place du développeur dans le test ?
Le dernier article de CloudNetCare de 2019 a abordé ce sujet au travers de son implication sur la qualité [CLOUDNETCARE] et rappelle l’indépendance du test telle que définie par l’ISTQB [ISTQB]. La phrase clef de l’article, « On ne part pas en développement si on ne sait pas comment on va tester », est du bon sens et fait partie des bonnes pratiques, mais leur conclusion est maladroite. En effet, le message de fin laisse penser que le développeur ne saura pas prendre de recul sur le code qu’il a écrit. Ce raccourci n’a pas échappé aux réseaux sociaux.
Quel dommage !!!!
Pourtant, le développeur dispose d’outils pour prendre ce recul et l’équipe agile, dans sa globalité, sera un moyen d’assurer l’indépendance du test.
Le TDD est sûrement le premier outil à maîtriser par un développeur pour produire un code de qualité du premier coup (Voir la notion de clean code [MARTIN]).
Dans ces vidéos et podcats, Michaël Azerhad en est convaincu [AZERHAD] . Il s’impose une rigueur extrême dans sa façon de coder en utilisant le TDD.
Il explique et démontre que le TDD n’est pas une méthode pour produire des tests unitaires, comme beaucoup le pensent, mais une approche pour concevoir le logiciel. La conséquence : un logiciel propre. Imaginez écrire du premier coup un code avec le strict nécessaire, sans code mort et cerise sur le gâteau, accompagné de bons tests unitaires.
Le TDD, un outil puissant au service des développeurs !!!
Christophe Moustier attribue l’origine du TDD à Kent Beck [MOUSTIER]. Vous trouvez plus de détail dans le livre de Kent Beck « Test-Driven Development by Example ».
Christophe nous apporte un peu de contexte et parle de software craftsmanship (et son manifeste) comme un ensemble de bonnes pratiques pour faire du clean code et des architectures SOLID.
Le TDD fait partie des bonnes pratiques du software craftsmanship.
Super, des TU en même temps que le code écrit !!!
Mais ils font quoi ces TU, qu’est-ce qu’ils testent au juste ?
Michaël Azerhad assimile le TU à un test d’acceptation !!!
Aïe aïe aïe, mes oreilles !!!
Associer test unitaire et test d’acceptation est-il si inaudible que ça ?
Ian Cooper, lors de son intervention aux NDC conférences 2013 [COOPER], fait tout un exposé sur le TDD et ce que doit être un test unitaire. Il nous rappelle la définition proposée par Kent Beck.
Un test unitaire est un test exécuté de manière isolée, rien de plus, rien de moins. Pas de système de fichier, pas de base de données, rien qui puisse rendre dépendants les tests les uns des autres.
Kent Beck
Ian Cooper précise que le TU ne doit surtout pas tester une méthode seule. Je cite « write unit tests that focus on behaviors and thus can be used for acceptance » (Traduction: « Ecrivez des tests unitaires qui décrivent les comportements du logiciel et vous pourrez les utiliser pour l’acceptation »).
Mais ne dit-il pas la même que chose que Michaël ?
Le terme « acceptance » ne doit pas être compris comme le niveau acceptation au sens ISTQB. Il faut plutôt le voir comme les critères d’acceptation d’une US.
Ian Cooper propose l’approche suivante.
- La raison d’être d’un test est un nouveau comportement. Pas une fonction ou une classe
- Ecrivez du code dégueulasse pour que le test soit passant puis remaniez le code
- Pas de nouveau test pour satisfaire le retravail du code interne ou privé
- Ajoutez des tests système pour la confiance de bout-en-bout
Robert C. Martin (alias Uncle Bob), a aussi abordé ce sujet sur son blog en 2017, First-Class Tests. Il partage sa définition des tests unitaires et préconise que le TU soit la première classe écrite du logiciel. Une autre manière d’introduire le TDD. Il est intéressant de voir que sa vision n’a pas changée :
Kent Beck, dans son article Test Desiderata, parle des propriétés qualité des tests unitaires. Sa proposition se rapproche beaucoup de celles rappelées par Christophe Moustier [MOUSTIER]:
– approche FIRST : Fulgurants, Isolés, Répétables, Suffisant, Temps
– approche A TRIP (acronyme proposé par Hunt pour faire référence au voyage): Automatique, Très détaillé, Répétable, Indépendant, Professionnel.
Je vous invite à aller consulter son livre qui liste des pattern et anti-patterns sur les TU. Judicaël Paquet a aussi fourni sa vision de la méthode FIRST dans son article « F.I.R.S.T avec nos tests unitaires ».
Pour conclure sur cette première partie, les développeurs ont les moyens et outils pour produire un code de qualité du premier coup, avec des tests unitaires. On gagne, de facto, en indépendance lorsque le développeur utilise cette expertise.
J’aime beaucoup la conclusion d’Oncle Bob sur son article, « TDD Harms Architecture » : « You see, it is not TDD that creates bad designs. It is not TDD that creates good designs. It’s you. TDD is a discipline. It’s a way to organize your work. It’s a way to ensure test coverage. It is a way to ensure appropriate generality in response to specificity. TDD is important. TDD works. TDD is a professional discipline that all programmers should learn and practice. But it is not TDD that causes good or bad designs. You do that. ».
Le mot de la fin sur la partie développement revient à Ian Cooper: « If in doubt just ask Q&A » (« En cas de doute, demande au QA »).
Phrase célèbre et il est vrai qu’un testeur a tendance à douter du code qu’on lui livre. Ce sentiment vient surtout du fait que, pendant des années, le logiciel livré arrivait d’un bloc avec des incompréhensions sur les attendus, des bugs, etc …
Aujourd’hui, l’agilité a fait évoluer notre métier et des outils sont à la disposition des testeurs pour rester dans les bonnes pratiques telles que préconisées par l’ISTQB, tout en étant pragmatique et évitant la surqualité.
Le premier outil est le manifeste du testeur.
Ce dernier met en avant des valeurs pertinentes. Evaluez votre contexte par rapport à ces valeurs et identifiez les axes d’amélioration à mettre en oeuvre pour tendre vers ces valeurs si vous avez des écarts.
Je vous invite aussi à consulter la version proposée par Marc Hage Chahine, dans son article « Mon manifeste du testeur », et qui complète le manifeste précédant.
Vous pouvez constater que ces valeurs vont dans le même sens que les valeurs de l’agilité et du software craftsmanship.
Un autre outil connu depuis très longtemps et parfois controversé est la pyramide de test. Christophe Moustier nous rappelle la genèse de cette pyramide souvent attribuée à Mike Cohn mais pouvant aussi être attribuée à Lisa Crispin (d’après Martin Fowler) ou encore à Jason Huggins [MOUSTIER].
La pyramide de test n’est pas un objectif à atteindre pour la simple raison que le test dépend du contexte (Un des 7 principes du test ISTQB).Utilisez la comme un outil d’amélioration continue:
1 – Représentez votre processus actuel avec cette pyramide
2 – Identifiez les points de souffrance et positionnez les sur votre pyramide
3 – déduisez-en votre pyramide cible (sans les points de souffrance)
4 – Mettez les actions correctives en mode pas-à-pas
Une fois votre cible atteinte, arrêtez-vous jusqu’à la définition d’une nouvelle cible.
Ne tombez pas dans une vision théorique de la pyramide qui vous conduira à faire du surtest.
Un contre exemple est la pyramide inversée ou cornet de glace qui, dans certains contextes peut être pertinente. Ma préférence reste celles proposées ci-dessus, et comme le rappel Christophe Moustier, les précédentes agissent de manière préventive alors que la suivante est en mode réactif.
Autre outil très utile : le quadrant du test. Je le trouve très efficace pour construire rapidement une stratégie de test.
Lorsque vous avez à construire une vision qualité sur un produit suite à des modifications, vous pouvez prendre le quadrant du test comme point de départ puis positionner les parties à tester au regard des impacts et risques produits.
Le quadrant est votre stratégie de test. Rien ne vous empêche de l’adapter et l’enrichir selon votre contexte. Je vous invite à lire le livre de Janet Gregory et Lisa Crispin sur ce sujet [GREGORY JANET][CRISPIN 03].
La pyramide et le quadrant sont des outils visuels et faciles à partager en équipe.
La communication, clef de voûte de votre équipe !!!
Le développeur apporte son expertise et code juste du premier coup.
Le testeur apporte son expertise et expérimente le produit.
Une équipe agile n’est pas juste une réunion de personnes.
Une bonne équipe agile est une équipe qui communique !!!
Je suis convaincu que l’on peut juger rapidement la qualité d’un logiciel en observant la communication entre les développeurs et testeurs. Une équipe dont les membres communiquent énormément, co-construisent et résolvent les problèmes ensemble aura très probablement un logiciel de meilleure facture qu’un logiciel construit avec des développeurs et des testeurs qui ne se parlent jamais.
Pas étonnant que des approches comme BDD, réunion des 3 amigos, exemple mapping, pair testing, pair programing soient de plus en plus présentes dans les bonnes pratiques agiles.
Le BDD n’est pas Gherking/Cucumber !!!
Le BDD est un échange entre le représentant produit, le testeur, le développeur et les ops afin d’illustrer, par des exemples concrets, un nouveau cas d’usage du produit !!!
Cela peut rester purement oral ou prendre la forme de phrases écrites, de croquis, de dessins, …
Ces exemples serviront de base à l’équipe pour proposer un découpage du problème à résoudre. Pour chaque découpage, l’équipe proposera des critères d’acceptation dérivés des exemples et partagés avec le représentant produit. Ces critères d’acceptations pourront être rédigés en Gherkin/Cucumber et deviendront des tests automatisés. On pourra parler d’ATDD et in fine, le développeur exploitera tout ça pour l’aider dans sa mise en oeuvre du TDD.
Avec l’ATDD et le TDD, le développeur construit le bon produit et le produit est bon (en anglais, right product right).
Le testeur, quant à lui, utilisera les exemples issus du BDD dans ses sessions de tests exploratoires et mettra en avant des chemins utilisateurs non identifiés lors des échanges précédents de l’équipe.
C’est le leitmotiv de James Bach et Mickael Bolton qui distinguent le « checking », la partie connue du logiciel, souvent automatisée, du « true testing », la partie expérimentale. Grâce au BDD, ATDD, TDD, on aura cette partie checking automatisée, et grâce au BDD et test exploratoire, on aura la seconde partie basée sur l’expérimentation.
Le testeur n’est pas le seul à faire du test exploratoire. Toute l’équipe, développeurs inclus, aura une plus-value au travers de sessions de test exploratoire.
Lisa Crispin et Janet Gregory parlent de pair testing ou encore mob testing. En français, on pourrait traduire par « test en groupe ». Pour en savoir plus, je vous invite à consulter leur livre mais aussi les publications de Maaret Pyhajarvi et Elisabeth Hocke (voir les sources ci-dessous).
Développeurs + testeurs + bonne communication = produit qualité
Mon équation de la qualité
Pour conclure cet article, l’alchimie entre développeurs et testeurs permettra de produire des logiciels de qualité et ce quelque soit l’historique du logiciel !!! Chacun apportera son expertise et fera grandir l’équipe. Et entre nous, quoi de plus épanouissant que d’évoluer dans un tel contexte.
Sources
[CLOUDNETCARE] « Aujourd’hui, quel niveau d’implication doit avoir un développeur sur les phases de tests ? » de CloudNetCare
[COOPER] « Where did it all go wrong » de Ian Cooper => la version slides
[PIERRAIN] « Virez-moi cette pyramide de tests ! » deThomas Pierrain
[AZERHAD 01] « BDD et son lien avec TDD, ce n’est clairement pas ce que tu crois ! » de Michael Azerhad
[AZERHAD 02] ‘ « On fait du TDD chez nous » => On vous ment, attention !!’ de Michael Azerhad
[AZERHAD 03] « Démonstration de BDD (ATDD) et TDD en live! de Michael Azerhad
[AZERHAD 04] « BDD, DDD, ATDD et TDD expliqués ! » de Michael Azerhad
[AZERHAD 05] Démonstration complète de BDD/TDD (Java): partie 1, partie 2 et partie 3 de Michael Azerhad
[PIGEON 01] Architecture de test de Xavier Pigeon
[PIGEON 02] « Diviser pour régner » de Xavier Pigeon
[PIGEON 03] Typologie des tests de Xavier Pigeon
[PIGEON 04] Pyramide de test revisitée de Xavier Pigeon
[PIGEON 05] Tempo du test de Xavier Pigeon
[GREGORY 01] « Testing is a team problem » de Janet Gregory
[GREGORY JANET] « Agile testing condensed, a brief introduction » de Lisa Crispin et Janet Gregory
[CRISPIN 01] « Pairing With Developers: A Guide For Testers » de Lisa Crispin
[CRISPIN 02] « What skills should we learn & teach to build quality in? » de Lisa Crispin
[CRISPIN 03] « Using the Agile Testing Quadrants » de Lisa Crispin
[CRISPIN 04] « An Overview of Agile Testing » de Lisa Crispin
[MOUSTIER] « Le test en mode agile » de Christophe Moustier
[HOCKE 01] Testing tour par Elisabeth Hocke : un portfolio des pratiques de pair testing
[HOCKE 02] « Thoughts about Testing in a Mob » de Elisabeth Hocke
[PYHAJARVI] « Styles of Pair Testing » de Maaret Pyhäjärvi. La version vidéo : https://www.youtube.com/watch?v=ctRD2KBUYSI
[ZUILL et MEADOWS] « Mob Programming » de Woody Zuill et Kevin Meadows
[VOCKE] « The Practical Test Pyramid » de Ham Vocke
[FOWLER] « TestPyramid » de Martin Fowler
[LAMBERT 01] « Pas d’Agilité sans focus sur les tests » de Jean-Pierre Lambert
[LAMBERT 02] « Le bon développeur, plus qu’un codeur » de Jean-Pierre Lambert
[ISTQB] les différents syllabus de l’ISTQB
[HAMMAR] « TDD C’EST CLEAN CODE ? » deWallid hammar
[COHN] « The Forgotten Layer of the Test Automation Pyramid » de Mike Cohn
[ROSE] « The Testing Iceberg » de Seb Rose
[MARTIN] « Clean Code: A Handbook of Agile Software Craftsmanship » de Robert C. Martin (alias Oncle Bob)
[MESZAROS] « xUnit Test Patterns: Refactoring Test Code » de Gerard Meszaros
Traductions
« You see, it is not TDD that creates bad designs. It is not TDD that creates good designs. It’s you. TDD is a discipline. It’s a way to organize your work. It’s a way to ensure test coverage. It is a way to ensure appropriate generality in response to specificity. TDD is important. TDD works. TDD is a professional discipline that all programmers should learn and practice. But it is not TDD that causes good or bad designs. You do that. »
« Vous voyez, ce n’est pas TDD qui créé de mauvaises conceptions. Ce n’est pas TDD qui créé de bonnes conceptions. C’est vous. TDD est une discipline. C’est un moyen d’organiser votre travail. C’est un moyen d’assurer une couverture de test. C’est un moyen pour assurer une généralité appropriée en réponse à la spécificité. TDD est important. TDD fonctionne. TDD est une discipline professionnelle que tous les développeurs devraient apprendre et expérimenter. Mais TDD n’est pas ce qui fait de bonnes ou mauvaises conceptions. Vous le faites. »
