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

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.

Le quatrième chapitre qui passe en revue les techniques de test est certainement le plus réutilisable de cette seconde partie. En fait, certaines techniques ne sont même jamais évoquées dans la littérature des tests agiles. Enjoy ! Les outils de test évoqués au chapitre 5 ne sont pas réellement des outils d’automatisation, mais des outils d’analyse et de gestion des tests. Là encore, le catalogue dressé par l’auteur est remarquablement large et ne saurait être boudé.

La 3ème partie, avec 450 pages et 12 chapitres est évidemment la plus importante de l’ouvrage. L’auteur y propose un processus de tests en 11 étapes. Le chapitre 6 qui introduit cette partie survole ces 11 étapes. La première étape est abordée au chapitre 7 : il s’agit de l’évaluation de l’état du projet. Il s’agit avant tout d’une estimation économique, assez inspirée de Capers Jones. C’est assez troublant, je ne sais pas quoi en faire, mais c’est en tout cas très cadré ! Le développement du plan de test au chapitre 8 a une coloration stratégique. L’approche est basée sur les risques avec une classification très fouillée. L’approche elle-même parait inexploitable tellement elle est structurée en tâche et en sous-tâche. J’en recommanderais toutefois la lecture à titre de réflexion voire d’inspiration.

Le chapitre 9 doit attirer notre attention, car il s’agit de tests en « phase d’exigence ». Non que le concept de phase d’exigence me fasse rêver, mais le propos illustre comment on peut adresser la question de la qualité du recueil des besoins. Ici, elle passe par l’identification des facteurs de risque et par 14 « test factors ». Le workflow proposé est lourd, très lourd. Ce sont également des « tests factors » que nous propose l’auteur en phase de conception. Le processus est un peu plus simple, mais les check-list proposées sont particulièrement impressionnantes. Sans doute trop spécifiques. Le chapitre 11 dédié à l’exécution des tests proprement dit est très court : il se résume à des listes de vérifications préalables… pour des tests exécutés manuellement, bien sûr !

L’enregistrement des résultats de test est la suite logique, au chapitre 12. Ce chapitre vaut surtout pour la liste (trop courte à mon avis) de types de tests pouvant être effectués. Le chapitre 13 devait attirer mon attention car il évoque les tests d’acceptation. Ils préfigurent en certains points les tests d’acceptation agile, en évoquant d’abord des critères d’acceptation, puis en déclinant des cas des tests à partir de cas d’utilisation, donc résolument orientés comportements. Au chapitre 14, il est question de reporting, mais d’un reporting projet et non réellement d’un reporting de test. Un chapitre hélas sans beaucoup d’intérêt. L’installation, que nous appellerons plutôt déploiement aujourd’hui est l’objet du chapitre 15. Les pratiques et outils devops en ont rendu une grande partie obsolète. Seule la courte section évoquant le monitoring resterait pertinente, mais elle est bien maigre.

Tester le processus de changement, au chapitre 16, est aussi un sujet dont l’intérêt me semble contestable. Je passe. Cette 3ème partie se conclut par un chapitre ouvrant le sujet de l’efficacité du processus de test. L’approche serait aujourd’hui à revoir, mais les questions soulevées restent d’actualité.

La 4ème partie est constituée de coups de projecteurs sur le test de topologies de projets particuliers. Ce sont 8 chapitres sur 170 pages qui constituent cette partie. On commence au chapitre 18 par les applications client-serveur, sur lequel l’auteur peine à dire quelque chose d’original. L’adaptation au RAD l’oblige par contre à creuser du côté du « spiral testing », avec les mêmes cycles mais plus courts. Le test des systèmes web au chapitre 21 met l’accent sur les tests d’intrusion et la protection des transactions, mais clairement l’appréhension de ces architectures est balbutiante.

C’est du côté de la complétude fonctionnelle et de l’intégration que le regard du testeur se porte concernant les progiciels sur étagère. Des considérations qui restent d’actualité. La sécurité fait l’objet d’un chapitre particulier, mais son traitement est léger, voir naïf. Le dernier chapitre est consacré aux entrepôts de données, avec un focus particulier sur l’intégrité des données et les processus opérationnels (les alimentations, surtout). Mais j’ai trouvé que le traitement manquait quand même de profondeur.

La dernière partie n’est constituée que d’un chapitre portant sur la documentation. En fait, il est précisément dédié à un seul document : le plan de test. Il y est décrit in extenso et vous êtes bien servis si vous en cherchez un !
L’auteur vient de toute évidence des gros systèmes et du cycle en V. Mais ce qui est valable et construit pour le cycle en V peut nourrir des réflexions pour un cycle itératif. Le style de l’auteur ne soit pas plus agréable à lire et qu’il soit vraiment très académique, mais la valeur du contenu (dont les propositions d’artéfacts, plans types, questionnaires, etc.. Directement utilisables tels quels dans les projets) nous invite à considérer positivement le contenu de ces pages.

Référence complète : Effective methods for Software testing, second edition – William E. Perry – John Wiley & sons 1999 – ISBN: 0-471-35418-X

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.