Par Kevin Kooh: Expert en génie logiciel et cofondateur de Zentelia Cameroun
23 août 2024
Tout au long du cycle de vie d’un logiciel, les tests constituent le meilleur moyen d’en améliorer la qualité et de renforcer la confiance que nous lui portons. Quel que soit le cycle de développement logiciel que vous utilisez, il est conseillé de commencer à tester très tôt dans le processus pour assurer une bonne qualité. Lorsque l’on doit bâtir une stratégie de test pour un projet ou un produit, plusieurs questions reviennent souvent : Comment tester? Quand commencer les tests? Quels tests devons-nous effectuer? Et à quel moment? Bonne nouvelle : la pyramide de tests vient répondre à plusieurs de ces questions.
La pyramide de tests est un outil qui aide l’équipe de développement à déterminer la quantité de tests à implémenter à chaque niveau du cycle de vie du logiciel. C’est un outil universel qui convient à toute organisation et qui s’adapte au cycle de développement logiciel de l’entreprise. Elle doit être intégrée dans la stratégie de test, bien qu’elle puisse varier selon les projets dans certains cas. Avant de rentrer dans le vif du sujet, il est important de présenter les différents niveaux de tests abordés dans la pyramide.
Les niveaux de tests sont des groupes d’activités de tests organisés et gérés ensemble. Quel que soit le cycle de vie du logiciel, pour atteindre une qualité optimale, le produit doit être testé à différents niveaux et à diverses occasions, en tenant compte de perspectives et de raisons variées.
Pour illustrer cela, prenons l’exemple d’un vélo à assembler et à tester. Selon la dernière version du syllabus ISTQB, les différents niveaux de tests sont :
Les tests de composants : souvent appelés tests unitaires, ils sont généralement effectués par les développeurs sur des composants isolés.
Les tests d’intégration de composants : souvent appelés tests d’interfaces, ils testent l’intégration des composants et leur interaction.
Les tests de systèmes : souvent appelés tests de bout en bout, ils vérifient le fonctionnement du système entier en utilisant les exigences et leur traçabilité.
Les tests d’intégration de systèmes : utilisés pour les produits complexes, ils testent des systèmes divisés au niveau du système, puis intégrés ensemble.
Les tests d’acceptation : souvent exécutés dans des environnements proches de la réalité, voire directement par le client. Il s’agit du dernier niveau de test pour valider le produit.
Pyramide tirée du modèle ISTQB®, adaptée et produite par Zentelia, 2024
Le choix de représenter les niveaux de tests sous forme de pyramide n’est pas anodin. Comme on le sait, la pyramide a une base large qui se rétrécit vers le sommet. Pour des tests efficaces, il faut donc maximiser les efforts et la quantité de tests au niveau des composants et les diminuer progressivement aux niveaux suivants. Si des problèmes surviennent au niveau des composants ou de leur intégration, ces problèmes seront amplifiés au niveau du système. Il est donc préférable de bien tester les niveaux inférieurs pour réduire les risques aux niveaux supérieurs de la pyramide.
Reprenons l’exemple d’un vélo à tester avant sa mise sur le marché :
Au niveau des composants : Les tests sont effectués sur chaque composant individuellement, tels que les pédales, les pneus, le guidon, etc. Cela permet d’évaluer la robustesse des pièces et de s’assurer qu’elles fonctionnent correctement.
Au niveau de l’intégration de composants : Les tests sont effectués sur l’intégration des composants entre eux. Par exemple, lier la pédale au pédalier, à la chaîne et à la roue arrière pour vérifier que les composants fonctionnent bien ensemble.
Au niveau du système : Les tests sont effectués sur le vélo entièrement monté. Cela permet de confirmer que le produit répond aux exigences fixées au début du projet.
Au niveau l’acceptation : Les essais sont réalisés avec des utilisateurs réels, comme des cyclistes professionnels, qui testent des échantillons. Si les tests sont concluants, le vélo est prêt à être vendu sur le marché.
Vous remarquerez que dans l’exemple du vélo, j’ai délibérément choisi de ne pas inclure le niveau d’intégration de systèmes. Selon l’organisation, selon le produit logiciel testé et même selon le cycle de vie de ce dernier, la pyramide de tests peut varier. Certains niveaux peuvent être ignorés, fusionnés ou ajoutés. La pyramide de tests est un outil qui nous aide à déterminer ce qu’il est pertinent de faire; elle ne doit pas être utilisée de manière rigide comme une norme absolue.
Supposons que nous devons tester une application bancaire permettant aux utilisateurs de consulter leur compte en banque et d’effectuer diverses transactions :
Au niveau des composants : Tester unitairement le code des différents composants pour s’assurer qu’ils fonctionnent correctement. Par exemple, tester le code du composant qui crée le compte avec les informations du client.
Au niveau de l’intégration des composants : Intégrer le composant de création de comptes avec le composant qui affiche le solde du compte et tester les deux ensemble.
Au niveau du système : Tester tous les composants intégrés pour s’assurer que l’application répond aux exigences définies. Dans notre cas, cela consiste à vérifier la capacité à créer un compte, à afficher le solde, à effectuer des transferts, etc.
Au niveau de l’acceptation : Envoyer des versions tests de l’application à des clients potentiels et leur demander d’effectuer des opérations. Ici, le but n’est pas de trouver des problèmes dans le système lui-même, mais de s’assurer que le produit développé répond bien aux besoins du marché.
Lorsque nous voulons augmenter la qualité et la confiance dans un produit tout en diminuant les efforts manuels, nous nous tournons vers les tests automatisés. Plusieurs questions reviennent souvent : Quels tests doit-on choisir pour l’automatisation? À quel moment faut-il les implémenter? Quels efforts devons-nous mettre? Encore une bonne nouvelle : une pyramide de tests adaptée au contexte d’automatisation peut nous aider à répondre à ces questions.
Pour la petite histoire, la pyramide de tests a été initialement créée pour faciliter l’implémentation des tests automatisés. Elle permet notamment de déterminer quels efforts d’automatisation fournir pour maximiser l’efficacité et minimiser les coûts. Par la suite, elle a été adaptée aux tests en général et aux différents niveaux de tests.
La base de la pyramide représente la quantité de tests, et la hauteur représente le coût de l’implémentation des tests.
La pyramide de tests peut avoir plusieurs significations et utilisations dans l’élaboration d’une stratégie de test pour un produit ou un projet précis. Qu’on l’utilise pour déterminer les différents niveaux de tests à couvrir ou pour déterminer les bons tests candidats à l’automatisation, la pyramide de tests reste un outil à utiliser avec parcimonie, et non une étape obligatoire.
L’une des erreurs communes, lorsqu’on utilise la pyramide de tests, est de confondre les différents niveaux de tests avec les types de tests à effectuer. Par exemple, il est possible d’effectuer des tests fonctionnels au niveau des composants, tout comme des tests en boîte blanche (comme les tests unitaires) au niveau du système. Le diagramme qui suit l’illustre à merveille :
La pyramide de tests est un outil précieux pour définir une stratégie de test efficace et garantir la qualité de vos logiciels à chaque étape du cycle de développement. En maximisant les efforts de test aux niveaux appropriés, vous pouvez trouver et corriger les problèmes précocement, et ainsi réduire les risques et les coûts associés aux erreurs détectées tardivement.
Découvrez comment notre expertise en assurance qualité peut vous aider à bâtir des logiciels plus fiables et performants. Contactez-nous dès aujourd’hui pour commencer à améliorer la qualité de vos produits ou de vos services!
Comments