La pyramide: une image récurrente dans le test
Il y a dans le test de nombreux concepts qui sont illustrés avec des pyramides. J’ai d’ailleurs moi même utilisé cette illustration dans certains de mes articles.
Cette pyramide est souvent utilisée pour:
- Les niveaux de test (acceptation, intégration, système, acceptation)
- Les tests automatisés (unitaires, service, IHM)
On voit également des « mixtes » de ces pyramides qui intègrent des notions de niveau de test et de manière de les exécuter (ex: tests manuels reprenant la partie test d’acceptation des niveaux de test) ou encore des pyramides proposant un mélange de tests unitaires (souvent composant), API (intégration) avant d’aller sur des types de test (fonctionnels et non fonctionnels)…
Comme vous le voyez la pyramide est une image omniprésente dans le monde du test il semble donc légitime de se demander pourquoi. La réponse qui me semble la plus pertinente est celle qui consiste à faire passer un message lié à une stratégie de test.
La pyramide pour définir une stratégie
La pyramide est connu pour avoir une base large et un sommet fin contrairement à un cône de glace. De même la notion de cylindre ou rectangle n’est pas non plus utilisé. Dans le cas du cylindre tout est aussi large.
Vous l’aurez compris, la pyramide est là pour rappeler un édifice solide, perenne dans le temps grâce à une base solide. Afin d’avoir une base solide il faut mettre plus d’efforts (dans notre cas généralement de tests) dans les parties basse. On parle d’ailleurs souvent d’inverser la pyramide des tests quand la plupart des tests exécutés sont des tests systèmes.
La lecture de la pyramide représentant les niveaux ci dessus revient à rappeler que pour avoir des tests efficaces il est préférable d’avoir plus de tests de composants que de tests d’intégration, eux même plus nombreux que les tests systèmes qui sont également en plus grand nombre que les tests d’acceptation.
Cette force de la suggestion explique des pyramide comme celle-ci:
Si je restais sur un point de vue strictement ISTQB je pourrais dire qu’ici on mélange des torchons et des serviettes. Que les tests unitaires et d’API peuvent également être des tests fonctionnels, de sécurité, de performances… Néanmoins si on se penche sur la signification de cette pyramide on remarque que la stratégie proposée est en fait intéressante car elle propose une vision du test où:
- Les tests unitaires ne doivent pas être oubliés car ils forment la base de la pyramide
- Les tests d’intégrations, faciles à automatiser doivent être plus nombreux que les tests d’IHM et système (le test fonctionnel étant souvent confondu avec le système)
- Les tests non fonctionnels ne doivent pas être oubliés! Car même s’ils ne sont pas forcément les plus nombreux les tests de sécurité et de charge se doivent d’être faits! Avez-vous déjà vu une pyramide sans sommet ?
Cette aspect est très intéressant mais il faut faire attention à ne pas s’enfermer dans cette image car elle n’est pas forcément toujours la plus pertinente!
La pyramide toujours pertinente ?
La pyramide nous enferme dans une certaine logique. Si l’on revient à la pyramide des niveaux de test rien ne dit que selon le contexte:
- les tests d’intégration ne soient pas primordiaux et nécessitant plus d’efforts que les tests composant
- les tests d’intégration soient vraiment important
- que le fonctionnels soient particulièrement important notamment au niveau de l’adaptabilité et qu’au final on ait énormément de test système…
On peut aller jusqu’à imaginer une stratégie ressemblant à une coupe dans un contexte où l’intégration est peut importante mais que l’on veuille faire de nombreux tests sur des terminaux différents et faire une grande campagne de bêta test ou de crowdtesting ce qui donnerait une stratégie ressemblant à cela:
Encore une fois cela ne fonctionnerait probablement que dans ce contexte ou un contexte équivalent. De même, toujours dans ce contexte la pyramide usuelle serait contre productive ou moins efficiente.
Conclusion
L’utilisation des pyramide est un outil très puissant. Néanmoins elle reste là pour proposer des concepts et des idées générales. Il ne faut pas s’interdire de penser différemment et de proposer quelque chose d’adapter à notre contexte. Tout comme l’indépendance des tests qu’il ne faut pas rechercher à tous prix, obtenir une belle pyramide des tests n’est pas forcément un objectif en soi. Cela reste cependant généralement une bonne indication dans de nombreux contexte et il est bon de le garder à l’esprit et, lorsque l’on décide de passer outre, de savoir pourquoi.
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.
2 réponses
Merci beaucoup Mister Suricate pour tout le travail abattu, grâce à vous je réaliser un de mes rêves tout en augmentant ma culture dans le test ! C’est génial, simple et efficace ! Tout ce qu’un apprenant peut souhaiter ! enfin je le crois !
Bonjour,
merci pour ce commentaire mais il y a erreur.
Je ne suis pas Mr Suricate et le blog de la taverne non plus.
Je suis Marc Hage Chahine et écrit mes articles de manière totalement indépendante. Je les publie sur le blog de la taverne du testeur que j’ai créé avec Bruno Legeard et qui est maintenant géré par une association (dont je suis le président) qui gère l’argent généré pour pouvoir payer son hébergement et contribuer à des initiatives dans le test.
Mr Suricate est une entreprise spécialisée dans l’automatisation des tests en no code.
Bonne journée