La taverne du testeur

Correspondance entre niveaux de test et quadrant de test Agile

La transformation Agile transforme le test

Les méthodologies Agiles sont de plus en plus présentes dans l’industrie logicielle. Afin d’être dans le mouvement et de répondre à des impératifs de réactivité de nombreuses sociétés se transforment.

Des DSI avec des dizaines voir des centaines d’acteurs et habituées à travailler en cycle en V se retrouvent à devoir se transformer et faire de l’Agile. Elles se retrouvent alors dans une démarche de transformation ce qui n’est jamais facile.

Un des moyens de facilitation des transformations est de se rattacher à ce que l’on connait et de faire des rapprochements. Il est toujours plus simple de faire de petits changements plutôt que de retourner la table! Ce point est d’ailleurs un des facteurs de succès du framework SAFe. Ce dernier permet en effet de retrouver assez facilement des rôles très courants en cycle en V.

Qui dit transformation Agile dit transformation des tests qui doivent répondre à différents impératifs dans un contexte de développement itératif au sein d’équipes pluridisciplinaires.

Le quadrant des tests Agile pour répondre au test en Agile

Afin de répondre à ces problématiques le test s’est adapté et a proposé une nouvelle manière de segmenter et présenter les tests: le quadrant des tests.

Ce quadrant définit 4 « types » ou « familles » de test avec des rôles différents bien identifiés: les quadrants.

Ces rôles sont définis en fonction de leur principal bénéficiaire (équipe ou produit) et de leur orientation (technologique ou métier). Chaque quadrant est la combinaison du bénéficiaire et de l’orientation. Cette adaptation a le grand avantage de mettre en avant les notions de produits et d’équipe très importantes en Agile ce qui facilite le découpage des responsabilités.

La correspondance niveaux de test et Quadrant Agile

Vous l’avez sûrement noté, le quadrant est efficace pour

  • déterminer le rôle des tests
  • déterminer des « responsabilités »

Cette utilisation est justement assez proche de celle utilisée par les niveaux de test en cycle n V où les tests composants sont généralement l’apanage des développeurs, les tests système celui des testeurs et les tests d’acceptation ceux du « métier ». Les tests d’intégration étant généralement soit l’apanage des testeurs (si technique) soit celui des développeurs.

L’intuition naturelle est donc de vouloir faire correspondre les quadrants à des niveaux! Ce travail est proposé par le syllabus fondation extension Agile (p32) de l’ISTQB où l’on retrouve:

  • Le Quadrant Q1 est de niveau unitaire
  • Le Quadrant Q2 est au niveau système, orienté Métier, et confirme le comportement du produit.
  • Le Quadrant Q3 est au niveau système ou acceptation utilisateur, orienté Métier
  • Le Quadrant Q4 est au niveau système ou acceptation opérationnelle

Ce découpage est « généralement » vrai néanmoins, comme vous pouvez le constater:

  • Le Q1 n’est noté comme niveau « unitaire » et pas « composant » car le niveau composant n’est pas forcément unitaire on n’a donc pas une correspondance formelle
  • Le Q2 est noté « système » mais orienté métier donc aussi un peu niveau test d’acceptation
  • Le Q3 est système ou acceptation utilisateur il est donc plutôt métier
  • Le Q4 est assez flou car peut être système ou acceptation… mais quand on y regarde de plus prêt on peut faire certains de ces tests non-fonctionnels en intégration et en composant également
  • Le niveau intégration est quant à lui dilué

Comme vous pouvez le noté la correspondance est floue ce qui est normal car le système de taxonomie est différent. Il est donc complexe et d’ailleurs je le déconseille d’essayer de faire une correspondance stricte entre niveaux de test et quadrant.

Conclusion

Le quadrant des tests et les niveaux de test sont des manières de découper des tests en fonction de leurs rôles et objectifs. Ils pposent chacun une taxonomie des tests qui peut proposer des utilisations identiques ou proches. Il est alors naturel de vouloir les rapprocher et créer des correspondance. Malheureusement cette correspondance n’est pas aisée ni claire tout simplement car la philosophie de ces 2 modèles est différente. De là à dire que les niveaux de tests sont dépassés et inutile en Agile ? Je ne le pense pas mais ceci sera l’objet d’un autre article!

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Automatisation

Les connaissances à développer en 2023

Un bon testeur est avant tout une personne avec des qualités morales mais aussi quelqu’un qui échange et se forme en continue notamment en faisant de la veille. Il doit également savoir s’adapter et repérer des tendances afin de pouvoir continuer à évoluer et avoir des missions intéressantes car, même

Lire la suite »
recrutement

Questions en entretien

Introduction Je suis régulièrement contacté pour des conseils ou des informations sur les questions en entretien d’embauche (que je préfère appeler entretien de collaboration) et sur ce qu’il faut faire/réviser pour le préparer. Je réponds en général qu’il faut être soi même et bien réviser son vocabulaire ISTQB! Même si

Lire la suite »
Interview

Retour d’Expérience (REX): Cerberus Testing – Yves Richard

Yves Richard, expert QA et automatisation chez Ausy, nous partage son expérience avec Cerberus Testing. Contenu de l’interview Automatiser, oui, mais à quel prix ? Réussir un projet d’automatisation requiert la combinaison de plusieurs facteurs de succès. C’est loin d’être un seul sujet d’outillage réservé à des profils techniques. Une

Lire la suite »