Étiquette : tests

Note de lecture : Automatisation des activités de test, par Olivier Denoo, Marc Hage Chahine, Bruno Legeard & Eric Riou du Cosquer edt.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Des contributions assez hétéroclites autour de l’automatisation, mais parfois intéressantes !

Les ouvrages collectifs sont rarement de grandes réussites. Celui-ci n’échappe pas à la règle, avec des contributions assez inégales. Toutefois, je lui reconnaitrais le mérite d’associer à l’agilité la nécessité d’automatiser les tests !

Le format de l’ouvrage dépassera légèrement de votre bibliothèque. Fort de 220 pages imprimé sur papier glacé en couleur, il faut bien dire que le CFTL a bien fait les choses. Le texte tire parti de cette impression en couleur avec de très nombreuses illustrations, le volume s’avale plutôt rapidement. Le texte est divisé en 3 parties pour un total de 22 chapitres, chacun d’entre-eux est donc plutôt court. La première partie « l’automatisation dans le test » et compte 5 chapitres pour 53 pages. C’est un panel des pratiques d’automatisation que nous livre le 1er chapitre : court et bien fait, il ne nous apprend cependant guère de choses utiles.

Le second chapitre aborde le périmètre de ce qui peut automatisé dans les activités de test. On n’y apprend pas grand-chose non plus, mais cela a le mérite d’être écrit du point de vue du testeur, ce qui est original. Ainsi le panel des activités de test est bien décomposé, mais le propos reste assez stratosphérique. Le chapitre 3 sur le test et la démarche devops s’avère être l’un des plus intéressants de l’ouvrage. Ses 2 points forts sont l’accostage des différents types de test avec le pipeline CI/CD et la présentation du « shift left », le concept le plus intéressant et le plus original du livre !

Lire la suite →
Publicité

Note de lecture : Effective methods for Software testing 2nd edition, par William E. Perry

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Une approche des tests très développée et d’une vision très large, mais présentée en cycle « V » classique…

Voilà le seul ouvrage traitant de tests « à l’ancienne » de ma bibliothèque. Cela rend ce volume d’autant plus important qu’il éclaire un pan de la culture test qu’il est nécessaire de comprendre. Dans le monde agile, les tests sont essentiels, et s’ils sont en majeure partie abordés différemment, comprendre cet écosystème reste un élément majeur pour aborder le changement.

Le livre est volumineux, certes, avec 800 pages mais ce n’est pas le plus volumineux publié dans le domaine. Au moins est-il bien rythmé avec 26 chapitres regroupés en 5 parties. A première d’entre-elles ne couvre qu’un seul chapitre sur une trentaine de pages. Son focus est l’évaluation des compétences et capacités de test. On y distingue l’évaluation du processus de test et l’évaluation des testeurs, le tout s’appuyant sur des corpus de connaissance entretenus par des organismes. Bref, on nage en plein dans les grilles d’audit. Cela ne fait guère envie mais au moins, on sait ce qui existe en la matière.

Avec 4 chapitres sur plus de 120 pages, la seconde partie est plus conséquente. Elle évoque la mise en place d’un environnement de test. Nous allons voir en quoi cela consiste. Le chapitre 2 adresse la stratégie de test, mais l’approche proposée, axée sur les phases de développement et les facteurs de risques ne se projette pas sur un cycle de développement agile. Dans la continuité, le chapitre 3 nous propose de construire une méthodologie de test, mais clairement axée sur un modèle en cascade, qui se conclut par un plan de test dont le template est passé en revue « in extenso ». Là non plus, rien de directement exploitable, mais il est riche d’enseignement de voir un véritable plan de test qui est souvent évoqué de manière bien abstraite.

Lire la suite →

Note de lecture : More Agile Testing, par Janet Gregory & Lisa Crispin

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Pléthorique, mais toujours et encore trop verbeux.

Ce nouvel opus, de prime abord semble avoir pas mal de points communs avec le premier tome. Le plus important est la taille : ici encore il s’agit de 500 pages environ. Plutôt qu’une suite du premier volume, le thème serait plutôt « les auteurs n’ont pas tout dit » ! Si le volume précédent était majoritairement guidé par les cadrans de Brian Marrick, ici l’approche est plus thématique.

Le volume nous propose 25 chapitres, regroupés en 8 parties. La première d’entre-elle, sobrement intitulée « introduction » ne compte que 2 chapitres sur 25 pages. Le premier est consacré aux évolutions des pratiques durant les 10 années qui ont séparé les 2 volumes. Une synthèse juste et plutôt bien faite qui évoque par exemple le test d’applications mobiles ou les pratiques de test d’acceptation. Le second chapitre met un coup de zoom sur l’importance de la culture de l’organisation. C’est un aspect qui avait été peu (ou pas) évoqué précédemment.

La seconde partie « learning for better testing” va regrouper 4 chapitres sur un peu plus de 60 pages. Le chapitre 3 dédié aux rôles et compétences comprend des sujets tels que les profils généralistes versus spécialistes, donc bien sûr une évocation des profils en « I » et en « T » qui m’a toujours semblée un peu bateau et de la pluridisciplinarité. Donc, pas tant de choses nouvelles ou originales au final. Les « thinking skills » évoquées au chapitre m’ont semblées plus intéressantes : la facilitation, l’écoute, la connaissance du domaine pour n’en citer que quelques-uns sont replacés dans le contexte d’une activité de test. Une prose qui pourra s’avérer utile pour le recrutement de vos prochains testeurs.

Lire la suite →

Note de lecture : Unit Testing : Principles, Practices and Patterns, par Vladimir Khorikov

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ;Des principes et des guidelines très solides pour concevoir les tests unitaires et les tests d’intégration.

Ce n’est pas le premier ouvrage sur les tests unitaires, bien loin s’en faut ! Mais c’est une belle surprise, même si elle bouscule un peu certaines de mes idées établies sur le sujet. Le but de l’auteur est de faire émerger et poser les principes sous-jacents à la pratique des tests unitaires. On pourrait penser que cela peut se contenter d’un mémoire de 50 pages au plus ? Il n’en est rien.

Au niveau du format, le livre rentre dans la moyenne : 270 pages sur 11 chapitres, le tout divisé en 3 parties inégales. . La première d’entre-elle nous dresse le paysage des tests unitaires sur un peu plus de 60 pages incluant 3 chapitres. La finalité des tests unitaires est l’objet des 20 pages du premier chapitre. C’est un début en douceur où est évoqué la question de l’entropie du code, mais où l’auteur s’attaque surtout au mythe de la couverture de code (à juste titre). Dommage que le mutation testing ne soit pas évoqué, ni ici ni plus tard.

Le second chapitre s’attaque à des principes fondamentaux : qu’est-ce qu’un test unitaire ? Une question moins simple qu’il n’y parait. Outre la granularité délimitant le test unitaire des tests d’intégration ou de bout en bout, c’est surtout le choix de l’école de pensée qui est en cause : école de Londres (parfois appelés tests solitaires) ou école classique ou de Chicago (parfois appelés tests sociaux). L’auteur ne fait pas mystère de sa préférence pour l’approcha classique, mais fait un excellent travail pour déterminer comment chaque approcha traite les différents types de dépendances. Le chapitre s’attaque à l’anatomie interne des tests unitaire. Il n’est guère surprenant que l’auteur fasse la promotion du pattern AAA (Arrange, Act, Assert). Il va plus loin en détaillant les bonnes pratiques sur chacun des volets pour améliorer la lisibilité et la maintenabilité des tests, pour ensuite adresser la question de leur paramétrage.

Lire la suite →

Note de lecture : Testing Microservices with Mountebank, par Brandon Byars

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une guide d’utilisation de Mountebank par son créateur. Bien écrit, mais assez basique

Mountebank est un framework de test (encore un) bien adapté au test des microservices, utilisant comme l’auteur nous le développera, le principe de l’imposture ! Malheureusement pour moi, la bête s’utilise avec du code JavaScript (avec du Node.js pour être précis), un obstacle que je n’avais pas anticipé. Cela a certainement impacté la note, dommage car le principe de ce moteur de test qui permet de simuler les services environnant au runtime ouvre nombre de perspectives.

Reprenons au départ : le volume se présente sous forme d’un texte de près de 220 pages découpé en 3 parties totalisant 10 chapitres. La première partie « premières étapes » ne compte que 2 chapitres sur 40 pages. Le premier chapitre « testing microservices » campe le décor. Il positionne clairement cet outil sur le volet « end to end » et introduit les notions de prédicats et d’imposteurs qui seront clé par la suite. Le second chapitre est le « hello world » … mais il s’avère rapidement être plus que cela. Il commence doucement en requêtes curl et en json, mais bascule rapidement sur le JavaScript ! L’auteur brûle un peu les étapes.

La seconde partie compte 6 chapitres et s’étend sur 130 pages. C’est le gros de la troupe et il est d’ailleurs sobrement intitulé « using Mountebank ». Il s’ouvre au chapitre 3 par le concept de réponses préfabriquées (canned responses), ce qui nous amène aussi à évoquer les prédicats. C’est plutôt clair et bien illustré. Les prédicats sont justement le sujet du chapitre 4. On les aborde en commençant par les expressions régulières pour terminer avec le JSonpath en passant par les champs multivalués. Le chapitre est riche et clair la plupart du temps.

Lire la suite →

Note de lecture : Testing Java Microservices, par Alex Soto Bueno, Andy Gumbrecht & Jason Porter

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Très pertinent sur la stratégie et la mise en œuvre des tests, souvent moins sur la clarté des explications.

Voici un livre qui s’est fait attendre plusieurs années. Au début, il s’agissait de produire un texte consacré à Arquilian. Finalement, le contexte s’est élargi aux tests de microservices de manière plus générale, Arquilian continuant à se tailler la part du lion, mais d’autres outils de test complétant le paysage, comme nous le verrons.

L’ouvrage totalise 260 pages réparties en 10 chapitres. Cela donne une moyenne de taille par chapitre relativement raisonnable mais quand même un peu plus élevée que ce que j’apprécie généralement. On démarre fort logiquement par un premier chapitre très court pour introduire les microservices. Il s’agit de présenter l’architecture microservices au niveau conceptuel. Une présentation pas vraiment fameuse, avec une représentation qui ne me parle guère et une architecture s’éloignant un peu de celle de Newman et où j’aurais aimé une pincée d’architecture hexagonale.

Le second chapitre présente l’application de test, ou plutôt l’architecture de test, sur une petite trentaine de pages. En fait, les auteurs ont fait le choix de rassembler des architectures techniques différentes : Spring Boot, TomEE et WildFly Swarm. A l’exception du vidéo service sur Spring Boot, le reste s’adosse à Java EE 7 ! Un choix dépassé depuis longtemps, peut-être justifié par le fait que les auteurs sont employés de JBoss ou parce qu’initialement Arquilian était dédié à JEE ? Quoi qu’il en soit, ce choix aurait dû être abandonné, il y avait déjà fort à faire en se contentant de Spring Boot et cette multiplicité introduit une regrettable complexité et de la confusion.

Lire la suite →

Note de lecture : Writing Great Specifications, par Kamil Nicieja

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Dans la continuité du « specification by example » de Gojko Adzic, mais bien moins brillant.

Cet ouvrage est dédié à l’écriture de cas de test en Gherkin. Mais pas n’importe comment. Il s’inscrit dans la continuité du « specification by example » de Gojko Adzic qui a d’ailleurs préfacé le livre. En fait d’écriture de cas de test, l’auteur préfère évoquer l’écriture de spécifications (le livre a d’ailleurs changé de titre en cours de route), comme son devancier.

Il y a des variantes à la grammaire Gherkin, l’auteur a fait le choix de cibler celle supportée par Cucumber, bien qu’il fasse allusion à d’autres outils de temps à autre. De toute manière, l’outil n’est pas le propos du texte, ni même l’implémentation des scénarios. C’est bien de leur écriture dont il est question. Pour cet objectif, le texte accuse 250 pages structurées en 11 chapitres réparties sur 2 parties. La première d’entre-elle, regroupe les 6 qui suivent l’introduction et occupe 140 pages.
L’introduction justement, est là pour camper le décor. Il s’agit d’un chapitre plutôt dense, puisqu’il accapare à lui seul 30 pages. L’auteur y développe les définitions qui seront utiles par la suite, les anti-patterns de spécification et surtout sa démarche SBE. Mais que tout cela est verbeux ! Malheureusement, il en sera de même pour la suite.

En ouverture de la 1ère partie « Writing executable specifications with examples », le chapitre 2 évoque sur un peu plus de 20 pages l’articulation entre la couche de spécification et la couche d’automatisation. L’objectif du propos n’est pas franchement clair. J’ai l’impression que l’auteur tente de faire une introduction au ralenti. La véritable introduction est au chapitre 3, elle nécessite 25 pages et introduit tout à fait convenablement la syntaxe et les règles d’écriture qu’y surimpose l’auteur. C’est bien, juste trop volubile par rapport à la quantité d’information délivrée.

Lire la suite →

Note de lecture : User Acceptance Testing, par Brian Hambling & Pauline Van Goethem

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 1 ; Une approche des tests à l’ancienne pour un texte récent et une cible complètement ratée.

Tests d’acceptation et User Acceptance Tests n’adressent pas pour moi la même finalité : Le premier est destiné à valider la conformité de ce qui a été réalisé par rapport à la spécification, tandis que le second se doit d’évaluer dans quelle mesure ce qui a été spécifié puis réalisé adresse l’expression de besoin initiale de l’utilisateur. Bref, l’UAT est là pour tester (indirectement) la spécification.

Il y a vraiment très peu de livres consacrés aux UATs. Celui-ci est en fait pratiquement le seul que j’ai pu identifier à ce seul thème. J’avais deux craintes avant même d’avoir ouvert ce livre : avais-je la même vu sur les UATs que les auteurs ? Et , étant donné l’origine très « corporate » du texte, n’allais-je pas rencontrer une approche très processus à l’ancienne ? Comme nous allons le voir, la réponse est hélas « oui » aux deux questions.

L’ouvrage n’est guère long, moins de 180 pages si l’on ne compte pas les inénarrables check-lists ou templates. Le tout est découpé en 10 chapitres pour reprendre son souffle. Moins de 20 pages en moyenne par chapitre, il n’en faudrait pas plus, car le style d’écriture n’est pas pensé pour être une partie de plaisir. Le premier chapitre n’a que peu à offrir, mais je m’arrête quand même sur deux points : d’abord le contexte considéré est bel et bien du cycle en V. Ensuite la définition du rôle de l’UAT semble correspondre à la mienne. Le second chapitre « the importance of UAT » en rajoute une couche sans apporter grand chose : toujours plus de processus, la contribution des différents rôles… tout cela est un peu creux. On revient sur la définition des UATs et cela deviens moins clair, entre la validation des spécifications et la satisfaction du besoin utilisateur. A ce stade, je doute que la distinction soit même claire pour les auteurs.

Lire la suite →

Note de lecture : Agile Testing, par Lisa Crispin & Janet Gregory

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Un complément indispensable aux projets agiles, mais bien lourd à digérer !

Les ouvrages traitant des projets en mode agile évoquent le plus souvent les tests d’acceptation d’une manière un peu globale en évoquant d’une part qu’il faut les faire et d’autre part qu’il est pertinent de commencer par les écrire afin de travailler en mode « ATDD ». C’est bien mais un peu succinct.

Ce livre prend une toute autre optique : prenez un testeur, un vrai, avec beaucoup d’expérience dans des contextes classiques. Plongez-le (ou « la » en l’occurrence ici, ici) au sein d’une équipe agile, avec pour mission d’adapter ses pratiques à l’esprit et à la façon de travailler de cette équipe. Tirer de ce travail de nouvelles pratiques et de nouveaux savoir-faire est l’objet de cet ouvrage !

Si l’idée est bonne, avec un texte ciblé vers le testeur, j’y trouve beaucoup de redondances avec ce que l’on connaît ou est déjà écrit ailleurs dans la littérature agile. Toute la première partie est consacrée à ces généralités. Bref, mauvaise pioche pour les 35 premières pages.

Lire la suite →

Note de lecture : Executable Specifications with Scrum, par Mario Cardinal

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Du Scrum de base sans surprise, à part celle de décevoir sur son titre !

Bien entendu, c’est l’aspect « spécifications exécutables » qui m’a conduit vers ce livre ! Le fait qu’il soit plutôt bref, avec ses 150 pages était un bonus. Au final, c’est une déception, la note est peut-être sévère à cet égard mais c’est ainsi, car il s’agit plutôt d’un nième « Scrum Shū ». L’ouvrage manque dans ses grandes largeurs d’originalité et le peu qu’il y en a ne m’a guère convaincu. Heureusement, il faut avouer qu’il est bien écrit. Voyons donc ce que nous réservent ses 9 chapitres.

Le premier d’entre eux couvre une douzaine de pages au sein desquelles on retrouve les poncifs habituels sur la justification des projets en agile : incertitude, complexité etc. En fait, j’ai même l’impression de relire l’introduction du premier bouquin sur Scrum, celui du début des années 2000. Le second chapitre, lui aussi fort d’une douzaine de pages, est un peu moins bateau. Il évoque les prérequis au démarrage de projet. Rien de neuf sous le soleil si ce n’est une bonne vue synthétique et l’usage de l’euristique de nommage de Gause et Weinberg.

Le chapitre 3 ne compte que 10 pages et sert principalement d’introduction à l’un des concepts originaux de l’auteur, celui de « desirement », contraction de « desire » et « requirements ». L’aspect « desire » étant inspiré de nouveau par Gerald Weinberg (are you ligh on ?). Disons le tout net : c’est très peu convainquant. Le tarif est d’une dizaine de pages également pour le chapitre 4 « expressing desirements through user stories ». On nous ressasse une nouvelle fois le template de Mike Cohn et le INVEST. La partie sur les rôles et bénéfices parvient à être intéressante, tandis que l’introduction au backlog reprenant la prose de Mike Cohn est parfaitement insipide.

Lire la suite →