Multiplier les types de tests sur la solution

Types de tests

La pyramide de test bien connue fournit la base pour multiplier les types de tests sur la solution avec [Akram 2020] :

• une série de tests au niveau des composants
• moins de tests au niveau de l'intégration
• et quelques tests au niveau du système

La répartition entre ces types de test peut être comprise à partir de chaque étape du cycle de vie du développement logiciel (SDLC) où bugs est généré [Beizer 1994] [Moustier 2019-1] :

Chaque origine de bugs dans le tableau ci-dessus est découverte grâce à des techniques de test différentes. Par conséquent, si une équipe souhaite améliorer la maturité de ses tests, la multiplication des types de tests sur la solution devrait être obligatoire. De ce point de vue, les tests s'apparentent à l'inspection d'un objet : si vous ne faites qu'un examen d'un seul point de vue, vous ne pourrez voir que les problèmes visibles d'un côté de l'objet.

Ce test basé sur le point de vue est en fait une illustration pure du principe de test " Testing is context dependent " [Guru99 2014] où les contextes sont les nombreux types de tests qui sont appliqués sur le produit.

Impact sur la maturité des tests

Les multiples techniques de test qu'une équipe connaît offrent autant d'occasions de changer son point de vue sur le produit. Cependant, vous devez garder à l'esprit que toute technique de test est en fait la suite tactique de paramètres tels que [Bach 2020] :

• l'environnement du projet, 
• les éléments du produit 
• et les critères de qualité attendus 

Par exemple, une application mobile qui est censée être disponible sur plusieurs app stores nécessitera des tests de compatibilité qui peuvent être effectués avec des tests automatisés sur des fermes mobiles telles que Saucelabs ou Browserstack. Par conséquent, la définition de ces paramètres donne quelques indices sur les nombreux contextes dans lesquels des types de tests peuvent être effectués sur la solution. Les exigences non fonctionnelles (NFR) font parties des critères de qualité classiques à prendre en compte.

Pour gérer plusieurs types de tests sur la solution, il existe différentes possibilités. Par exemple, le SDLC peut être vu comme une pile de tranches de fromage suisse avec des trous qui permettent finalement à bugs de passer en production [Reason 2006], chaque tranche étant une opportunité de test avec ses propres défauts [McConnell 2004] [Moustier 2019-1]. Le modèle du fromage suisse peut être utilisé pour gérer la norme de qualité appropriée à appliquer en fonction du contexte :

• les contrôles existants peuvent être renforcés pour réduire les trous dans les tranches de fromage
• des contrôles supplémentaires peuvent être ajoutés s'ils sont plus appropriés ou moins chers (loi de Pareto).
• si le risque sur une caractéristique semble être plus faible que sur une autre, certains contrôles peuvent être abaissés ou des tranches peuvent même être sautées

Illustration tirée de [Moustier 2019-1].

Une autre façon de gérer les multiples types de tests que la culture de test agile a adoptés est le " quadrant de test agile " [Marick 2003][Bach 2014]. Il fournit de nombreux aspects de test qui abordent l'entreprise, la technologie, le développement et le produit. Habituellement, le quadrant est pré-rempli avec certaines questions de test à l'intérieur [Crispin 2011], mais face à une User Story ou à des objectifs de Sprint, l'équipe devrait alors simplement fournir certaines activités de test dans les quatre quadrants [Crispin 2021].

‍

Le point de vue d'Agilitest sur cette pratique

Agilitest contribue essentiellement à remplir les quadrants de test Agile sur la partie orientée métier. Cela signifie que d'autres aspects manquent pour permettre une vision plus complète du produit testé.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍