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.

La seconde partie attaque les tests sous l’aspect organisationnel, ce qui change pour le testeur, les attentes du management et surtout la question du test intégré à l’équipe versus l’indépendance des tests par rapport à l’équipe. Complété d’un dernier chapitre sur le processus et les mesures, cette partie longue de 60 pages sur 3 chapitres offre un éclairage intéressant, mais trop verbeux. 20 pages auraient suffit.

La troisième partie aborde la partie « dure » du livre, à savoir le concept majeur des auteurs : l’agile testing quadrant. J’aime bien le concept et il recouvre de manière synthétique ce que l’on cherche à faire, ou plutôt ce que l’on devrait faire ! Il couvre 160 pages sur 7 chapitres : soit 1 chapitre pour chacun des quadrants (sauf le 2 qui en compte 2, une introduction et une conclusion). L’introduction n’est pas si mal, même si aujourd’hui je ne suis plus d’accord avec certains points, comme l’utilisation du verbe « critique ». La chapitre 7 qui est consacré au premier quadrant reste beaucoup dans les généralités tout en se perdant dans des considérations secondaires : IDE, utilisation d’un gestionnaire de versions, etc. Tout cela n’est pas très instructif.

Il y a pas mal d’éléments de réflexion tout à fait valables dans le chapitre 8 qui couvre le second quadrant des tests. Par exemple l’idée d’appeler cela le « requirements quadrant » et de travailler avec des exemple (idée qui a fait beaucoup de chemin depuis). Hélas les auteurs, au long de ces 22 pages échouent encore à donner au texte un sens et une vigueur qui conviennent. Les 34 pages qui suivent tentent de faire le tour de la question de l’outillage : depuis la feuille Excel jusqu’à Sélénium en passant par Fitness, le BDD et autres Flow diagrammes. Là encore, c’est sympa mais cela manque de mordant. Au chapitre 10, on aborde les tests fonctionnels « pour critiquer », à savoir essentiellement les tests exploratoires et les tests d’utilisabilité (curieusement entre l’introduction et ce chapitre, on a laissé tomber les UAT). Le chapitre 11 quadrant 4 dédié aux « illités » ne montre pas caractère utile, juste une vaine tentative de couvrir le terrain.

Bref, accorder 160 pages à cette partie, c’est trop délayer la substance, la moitié aurait été suffisant.

L’automatisation des tests est un point crucial pour leur exécution itérative, sinon continue. On y accorde 75 pages sur 2 chapitres. Peu de guide concrets sur l’automatisation des tests au programme. Le chapitre 13 nous donne une introduction aux raisons d’automatiser, ce qui est fort peu utile à mon avis et couvre quand même 20 pages. Le chapitre 14 évoque la stratégie. On reste sur des considérations très générales et pas franchement nouvelles. Un petit bon point tout de même sur la question de la gestion ou génération des donnes de test.

Le titre de la 5ème partie est de toute évidence inspiré des Beatles. 7 chapitres sur 150 pages couvrent la façon dont se déroulent les itérations du point de vue du tester, depuis le planning meeting jusqu’au déploiement, en passant par le démarrage de l’itération, le développement et la fin d’itération. Beaucoup de confusion pour moi dans le contenu des différents chapitres. Ainsi le chapitre 15 qui traite du release planning (et compte quand même 38 pages) peine à trouver un sujet test pertinent à ce créneau et développe pas mal de sujets qui sont pour moi hors sujet.

Difficile aussi de comprendre le propos du « hit the ground running », c’est à dire le chapitre 16, heureusement assez court. On finit par comprendre que l’on parle de préparation de l’itération. La vingtaine de pages du chapitre 17 consacré au lancement d’itération me plaisent plus : on voit comment le testeur peut collabore avec l’équipe et les utilisateurs pour démarrer l’itération. Il faudrait que tout le livre soit comme cela.

C’est au déroulement même de l’itération qu’est dédié le chapitre 18. Il compte quand même 35 pages que ne justifie pas le contenu. J’y vois assez peu de valeur, encore une fois. Je passe sur le chapitre 19 qui couvre démo et rétrospective. Plus que succinct, il n’apporte rien sur le volet test. Cette partie se referme sur le chapitre 20, la « fin de partie » du produit. Il a l’indéniable intérêt de soulever pas mal de questions oubliées à ce moment là : alpha et beta testing, UAT, environnements de pré-production, formation, conversion de données, etc. On est quand même content d’avoir cette information !

La 6ème partie qui synthétise les leçons à retenir de l’ouvrage propose 7 facteurs clé de succès. A l’évidence, c’est LE chapitre à ne pas rater du livre ! Elle ne comprends d’ailleurs qu’un seul chapitre d’une dizaine de pages. Et oui, sur ce coup les 7 facteurs sont pertinents et couverts de façon très efficiente.

Si il y a de toute évidence de la matière dans ce livre, et même beaucoup, j’ai été déçu par son manque de focalisation et le manque de synthèse. C’est vraiment un livre imposant, mais il ne me paraît pas particulièrement compliqué de ramener cela à moins de 300 pages (voir 200) ce qui serait plus respectueux du temps de l’audience. Son volume exagéré est finalement contre-productif.

Référence complète : Agile Testing, A practical guide for testers and agile teams – Lisa Crispin & Janet Gregory – Addison Wesley / Signature series 2009 – ISBN: 0-321-53446-8 ; EAN: 978 0 321 53446 0