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.
Les quadrants 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 Quadrants 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 constater 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 quadrants.
Conclusion
Les quadrants 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 posent 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.
