[ISTQB ] Quadrant de test Agile

Ma découverte du quadrant

En novembre 2015 je suivais une formation ISTQB Agile dans le but d’obtenir ma certification. J’attendais beaucoup de cette formation, je souhaitais y découvrir:

• De nouvelles manières de penser
• Améliorer mon discours pour appréhender le t’est dans un contexte Agile
• Avoir des outils pour inculquer l’esprit de la qualité à l’ensemble des membres de l’équipe
• Connaître le point de vue d’ l’ISTQB sur cette méthode de travail

J’avoue avoir été assez déçu à l’issue de cette formation. Mon principal reproche à l’époque était que j’avais trouvé que cette formation était très fragmentée avec:

• Une partie de présentation de l’Agile
• Une partie test en Agile très axée sur 1 différence: l’automatisation

A noter: c’est un ressenti de 2015 à un moment où la certification était très récente et l’Agile moins généralisée. Depuis 2015, cela s’est forcément amélioré!

Malgré cette relative réception il y a un point en particulier qui a répondu à mes attentes. Un point particulier qui m’a permis d’appréhender les choses différemment, d’avoir un discours plus structuré ainsi qu’un outil visuel pour le porter. Je pense ici au quadrant des tests Agile:

Bon, je dois l’avouer, ce simple schéma est assez simple à trouver mais aussi assez complexe à lire sans explications derrière. Car, même si je considère ce quadrant comme un outil très puissant qui arrive à regrouper un très grand nombre d’idées de manière très condensée il a la contre partie d’être difficile à bien comprendre. C’est pourquoi je vous propose aujourd’hui ma lecture de ce quadrant.

Comment lire le Quadrant ?

L’intérêt du quadrant c’est qu’il peut se lire de plusieurs manières en fonction du sujet que l’on veut aborder!

De gauche à droite:

• La partie gauche est relative à l’équipe Agile. Ce qui est là pour soutenir l’équipe, lui permettre d’avancer. On y retrouve les tests exécutés généralement par les développeurs (unitaires / niveau composant) et les testeurs (tests système, fonctionnels, liés à un comportement définit).
• La partie droite, quant à elle, est plus spécifique au produit lui même et à une partie « non-fonctionnelle ». Ici on est sur des tests qui sont là pour évaluer le produit d’un point de vu « pratique », qui dépasse le fonctionnel. Il n’est alors pas étonnant de voir des tests à effectuer par le PO (niveau acceptation) ou des tests assez techniques pas toujours faits par l’équipe (sécurité, performance…)

De haut en bas:

Tout comme pour la partie de gauche à droite, il est possible de lire de haut en bas.

• La partie haute est axée sur le métier. C’est à dire le fonctionnel, l’utilisation que l’on veut faire du produit. Bref, répondre à la question: à quoi sert le produit ? Il est donc cohérent de retrouver les niveaux des tests systèmes (spécifications) et tests d’acceptation (lié aux usages concrets des utilisateurs)
• La partie basse est liée aux technologies utilisées, à la technique. On répond ici plus à la question: comment le produit fonctionne-t-il ? Cette réponse est très liée au langage de développements et à l’environnement technique c’est pourquoi il n’est pas surprenant d’y retrouver des tests unitaires ou techniques.

Par « coin »:

On est ici sur l’analyse de chaque quadrant!

• Q1: la partie sur les tests unitaires, les tests niveau composant. Ces tests, généralement faits par les développeurs sont des tests nécessaires à l’équipe (et faits par cette dernière) et très liés à la technologie. Il peut être intéressant de noter qu’il n’est pas impossible d’ajouter dans ce quadrant les tests du niveau intégration. Ces tests sont évidemment automatisés.
• Q2: ces tests sont généralement les tests effectués par les testeurs. On est sur du comportement et du test niveau système (ce qui explique mon point de vue sur la différence entre ATDD et BDD). Ces tests peuvent être manuels mais il est préférable de les automatiser autant que possible.
• Q3: ces tests sont les tests généralement effectués par le PO, le métier ou même des utilisateurs. Il ont pour but de vérifier la conformité au besoin c’est pourquoi ils sont généralement associé au niveau test acceptation (je suis relativement en désaccord avec le niveau système même si, selon le contexte cela peut se comprendre). Ces tests sont principalement manuels même s’il peut être intéressant d’en automatiser quelques uns.
• Q4: Les tests « techniques ». Le quadrant annonce test système ou d’acceptation car ils sont généralement exécutés à ces étapes. Ces tests sont souvent effectués par des spécialistes du sujets qui maîtrisent des outils dédiés.

Mais encore:

La puissance du quadrant n’est pas seulement sa lecture mais bien les associations que l’on peut tirer de cette lecture. On peut par exemple noter:

• que les tests encore manuels sont ceux qui donne le plus libre court à l’interprétation: les tests métiers
• tous les acteurs ont un rôle dans la qualité d’un produit (du développeur à l’utilisateur, en passant par le PO et le testeur sans oublier des spécialistes de certains sujets!
• On est dans l’industrie du logiciel, le contexte, notamment technique, impacte très fortement les tests…

Points d’attention

Le quadrant ne détient pas de vérité absolue. Comme pour toute simplification il y a des raccourcis, des points qui vont dépendre du contexte je pense notamment à:

• Dans les exemples de test en Q4 donnés par l’ISTQB il y a les tests exploratoires. Je ne les ai pas mentionnés par souci de place mais aussi car le tests exploratoire peut/doit être fait dans d’autres quadrants!
• On ne parle pas directement des tests statiques comme les revues
• Le parallèle niveau de test/quadrant a ses limites! On n’a pas de niveau test d’intégration affiché; le partie Q4 peut être, en partie faite en Q1 (ex: pour la sécurité avec des outils comme Sonar ou Fortify…)…

Conclusion

le quadrant est un formidable outil de communication! Il permet de savoir se situer, savoir quels tests faire, qui les faits, quels sont leurs buts….

Il faut néanmoins savoir présenter ce quadrant et ne pas laisser quelqu’un seul devant car il n’est pas simple à appréhender. De même il présente principalement des concepts et des notions qui sont vraies dans la majorité des cas mais pas dans tous. C’est pourquoi il reste nécessaire de bien le comprendre afin de savoir l’utiliser puis nous permettre de le dépasser pour si besoin s’en affranchir… et pourquoi pas se servir de sa structure pour faire passer de nouveaux messages!

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.