Note : 4 ; Plutôt déçu.

Le livre m’avait été chaudement recommandé, je m’attendais donc à un texte que allait quelque peu bouleverser mon mode de pensée. De ce côté-là, on est loin du compte. Le texte n’est pas médiocre pour autant. Il compte 235 pages dans sa partie principale auxquelles il faut ajouter les 30 pages d’annexes. Il ne compte que 5 chapitres, ces derniers sont donc chacun très volumineux. J’avoue que cela rend la lecture peu plaisante, surtout que le texte est très dense. Les 3 chapitres du milieu sont organisés selon les rôles de l’organisation Google, une articulation que je trouve fort peu heureuse. Voyons cela.

Le premier chapitre est, avec le dernier, le plus court du livre car il ne compte que 12 pages. Cette introduction nous décrit comment l’organisation fonctionne, avec ses 3 rôles au niveau des tests et la philosophie générale : pas de phase de tests en aval et des testeurs délibérément en sous effectifs.

Le second chapitre se focalise sur les « Software Engineer in Test ». Avec 60 pages, c’est déjà un long chapitre ! Le chapitre est un peu confus, probablement à cause de sa taille (ça empire même plus tard). Parmi les choses que je garde du chapitre : la distinction des différents types de tests (petit, moyen, gros, énorme), le workflow de travail du SET décrit en « live », le focus autour de Protocol Buffer. On y parle aussi de certifications interne Google (sans intérêt) et quelques interviews terminent le chapitre. C’est là une des particularités de l’ouvrage.

Si le troisième chapitre est conséquent avec 60 pages, que dire des 106 pages consacrées au Test Engineer ? Là aussi, c’est la confusion du propos qui domine, qui mélange les tâches liées au rôle avec le ACC matrix (l’un des éléments intéressant du livre), ce qui nous conduit rapidement aux questions d’outillage, avec GTA pour la gestion du risk analysis. Suit un propos également long sur la gestion des test cases dans GTCM (autre outil maison). C’est à ce moment où j’ai perdu courage et fait une pause de quelques mois dans ma lecture !

Pour le quatrième chapitre, il faudra aussi s’armer de courage pour affronter la quarantaine de pages consacrées au Test Engineering Manager. Ce chapitre est presqu’exclusivement consacré à des interviews. Mon « takaway » est la notion d’impact chère à Google et comment elle prend forme dans le management quotidien. Très instructif !

Les quelques pages du dernier chapitre sont dédiées à l’avenir du test chez Google. Les auteurs s’interrogent sur la pertinence des rôles aujourd’hui et sur l’existence même du département, au regard du niveau de maturité acquis.

Au final, ce livre ne m’a pas apporté ce que j’y cherchais. C’est peut-être le défaut ? Il y a beaucoup de longueurs et le propos manque souvent de direction. C’est surtout vrai du chapitre 3 dont la lecture m’a semblé une réelle souffrance. Je discerne très facilement un découpage en 3 de celui-ci, ce qui aurait pu donner un meilleur focus à chacun d’entre eux. Au final, ce n’est certainement pas une expérience mémorable.

Référence complète : How Google Test Software – James Whittaker, Jason Arbon & Jeff Carollo – Addison Wesley 2012 – ISBN : 978 0 321 80302 3