9 Types de tests logiciels en ingénierie logicielle

Les tests logiciels sont un art. Un testeur logiciel, comme un artisan, doit avoir une parfaite connaissance des outils de test logiciel à sa disposition. Nous avons compilé une liste de 9 types différents de tests logiciels, et des outils utilisés pour chacun, afin d’aider les analystes QA et toute personne travaillant dans le domaine du test logiciel à mieux comprendre leur métier.

Pourquoi avons-nous besoin des tests logiciels ?

Parfois, il est important de se rappeler pourquoi ce que nous faisons a de l’importance. Le fait est que chaque logiciel qui a rencontré le succès l’a fait grâce à l’aide des testeurs qui travaillent sans relâche pour garantir que le produit atteigne la plus haute qualité possible. Voici trois raisons pour lesquelles les tests logiciels sont essentiels. 

1. Satisfaction client : Pendant le développement d’un projet, il est facile de se perdre dans les lignes de code et d’oublier que l’utilisateur doit aussi être satisfait du fonctionnement du logiciel. Les analystes QA et autres membres de l’équipe QA se placent justement dans ce rôle. 
2. Qualité du produit : Toute profession où une équipe ou une personne crée quelque chose à partir de zéro nécessite une contrepartie qui corrige les erreurs. Les écrivains ont besoin de relecteurs. Les réalisateurs de film aussi. Les développeurs n’ont pas besoin de correcteurs, mais ils ont besoin d’une équipe QA pour fournir un regard objectif et repérer les erreurs. 
3. Sécurité : Chaque jour, ce point prend de plus en plus d’importance. Les clients veulent avoir l’esprit tranquille en sachant que les informations qu’ils saisissent dans le logiciel et le travail qu’ils effectuent restent privés. Le travail de la QA est d’assurer la confiance des clients à ce niveau. 

Need expert help selecting the right tool?

With one-on-one help, we guide you to your top software options. Narrow down your software search & make a confident choice.

Get free tool advice

Méthodologies de test logiciel

Chaque type de technique de test logiciel mentionné dans cet article appartient à l’une des deux grandes catégories : les tests statiques et les tests dynamiques. Avant d’entrer dans les détails spécifiques des neuf différentes techniques de test, j’expliquerai la différence entre ces deux méthodologies et à quel moment elles interviennent dans le cycle de développement logiciel. 

Test statique

Le test statique est un type de test logiciel qui s’effectue tôt dans le cycle de développement. C’est une manière économique de détecter les bugs avant qu’ils ne posent de gros problèmes à l’équipe de développement. Les tests statiques sont réalisés en début de cycle, car ils peuvent être faits sans que le logiciel soit entièrement fonctionnel. En effet, le logiciel peut être débogué alors qu’il n’est même pas encore terminé. Vous voyez l’intérêt ? 

Les tests statiques sont réalisés de deux façons :

• Examens manuels : Le code est analysé par un analyste QA ou un testeur. 
• Analyse automatique : Un outil de test vérifie automatiquement le document du programme et signale toute erreur.

Le test statique est :

• Effectué sans exécuter de code.
• Économique.
• Utile pour s’assurer que le logiciel respecte les spécifications de vérification.
• Un moyen de déterminer la cause fondamentale des bugs.

La plupart des tests statiques sont effectués sous la forme de revues de documents. Dans ce cas, un document est soit une description écrite du produit (couramment appelée document de conception logicielle), soit le code source du programme. Voici quelques techniques de test statique que tout analyste QA devrait connaître :

• Revue informelle : Il n’y a pas de règles strictes ici. L’équipe parcourt les documents de test et commente ce qu’elle observe. Il n’y a pas de documentation officielle.
• Présentation (Walkthrough) : L’auteur du code présente son document et l’équipe QA pose des questions ou soulève des points. Les walkthroughs sont généralement très informels et constituent une bonne méthode pour discuter avec des personnes extérieures au domaine logiciel. 
• Revue technique : Des experts techniques se rassemblent pour examiner les spécifications techniques du code. Réaliser cette revue en début de développement assure que le produit final respectera bien les exigences.
• Inspection : C’est la revue la plus formelle. Une équipe de modérateurs qualifiés inspecte minutieusement les documents lors d’une réunion. Tout bug repéré est documenté et enregistré pour un futur suivi, afin de vérifier qu’il a bien été traité. 

Dans la plupart des cas, les revues de tests statiques sont utiles car toute l’équipe QA analysera le produit et proposera des modifications en fonction des problèmes qu’elle observe et anticipe. Au-delà de l’intérêt de recueillir une grande variété d’avis dans la discussion, cela permet aussi à tous les membres de l’équipe d’être informés de l’avancement du projet et de sa conception. 

Utilisez le test statique si votre équipe :

• En est au début du processus de développement.
• Recherche une façon économique de détecter les bugs.
• Possède un logiciel qui n’est pas prêt à être exécuté.
• Veut repérer les erreurs tôt dans le développement.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Instagram

This field is for validation purposes and should be left unchanged.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Test dynamique

À la différence du test statique, le test dynamique est un type de test logiciel qui nécessite l’exécution du code. Naturellement, cela implique que le développement soit plus avancé dans le cycle de production. L’avantage de tester un code exécutable est que les analystes QA peuvent observer le comportement du logiciel lorsqu’il fonctionne dans une situation réelle. C’est un excellent moyen de vérifier le comportement fonctionnel du logiciel ainsi que d’autres aspects comme l’utilisation du processeur. Le test dynamique vérifie que le résultat attendu correspond bien au résultat réel. L’objectif principal du test dynamique est de s’assurer que le produit répond aux exigences de conception et fonctionnelles définies avant le début du projet.

Généralement, il y a quatre étapes à suivre lorsque le logiciel système est testé dynamiquement, que les analystes QA doivent connaître :

• Test unitaire : Lorsqu’un logiciel est soumis à des tests unitaires, il est divisé en ses plus petits composants, testés individuellement. En procédant ainsi, les analystes QA ont l’assurance que chaque partie du logiciel fonctionne comme prévu. Et si un bug est découvert, il sera plus simple de le corriger à ce stade, où il est facile d’isoler la portion problématique du code. En général, lorsque l’équipe QA commence les tests dynamiques (même si parfois cette étape est assurée par l’équipe de développement), elle débute par des tests unitaires.
• Test d’intégration : Après que le logiciel a été soigneusement divisé en composants et testé individuellement via les tests unitaires, il sera reconstitué par groupes pour être à nouveau testé. Si les tests unitaires permettent de s’assurer du bon fonctionnement de chaque élément, les tests d’intégration veillent cette fois à ce que les éléments communiquent entre eux comme prévu. Imaginez l’assemblage d’une voiture : à chaque étape, les différentes pièces (le moteur, les pédales, le volant) sont testées séparément. Ensuite, la voiture est assemblée et testée dans son ensemble, pour vérifier que, par exemple, la pédale d’accélérateur communique correctement avec le moteur (et les freins aussi !). Vous souhaitez garantir une intégration transparente entre les modules ? Nos outils de test logiciel recommandés peuvent vous y aider.
• Test système : Le test système est le troisième niveau de test logiciel. À cette étape, un logiciel complet et parfaitement intégré est testé. Le but du test système est de s’assurer que le logiciel répond aux exigences, c’est-à-dire qu’il fait bien ce pour quoi il a été conçu. 
• Test d’acceptation : Il s’agit de la dernière étape des tests dynamiques. Le test d’acceptation a pour objectif, encore une fois, de vérifier la conformité avec les exigences et de s’assurer que le logiciel est prêt à répondre à un niveau de qualité acceptable. Cette étape permet de vérifier qu’aucune erreur n’a échappé aux précédents tests. Autrement dit, il s’agit d’une double vérification par souci de sécurité. 

Étapes du test dynamique

1. Test unitaire
2. Test d’intégration
3. Test système
4. Test d’acceptation
   

Astuce rapide : Test de vérification vs test de validation 

Le test de vérification partage toutes les caractéristiques clés du test statique. Le but d’un test de vérification est de vérifier tous les documents et le code, ce qui se fait par les mêmes méthodes que celles utilisées lors du test statique.

De la même façon, le test de validation partage toutes les caractéristiques du test dynamique. Un test de validation s’attache à confirmer la qualité du logiciel, ce qui correspond exactement à l’objectif des tests système et d’acceptation.

Maintenant que nous avons abordé certains concepts clés concernant les tests logiciels, découvrons les 9 types de tests que tout analyste QA doit connaître.

9 types de tests logiciels que tout analyste QA doit connaître :

1. Boîte noire
2. Boîte blanche
3. Boîte grise 
4. Automatisé 
5. Unitaire
6. Récurrence
7. Exploratoire
8. Test fonctionnel
9. Test d’utilisabilité

1. Test de boîte noire

Le test de boîte noire est une stratégie de test logiciel où la conception du système logiciel testé est inconnue du testeur.

Vous vous souvenez de cette scène à la fin de Pulp Fiction, lorsque Samuel Jackson ouvre la mallette et que son visage s’illumine ? En tant que spectateur, on comprend ce que la mallette signifie et représente dans le contexte du film, mais on ne saura jamais ce qu’elle contient. Un testeur en boîte noire est comme un spectateur : il sait à quoi l’objet (que ce soit une mallette ou un logiciel système) est censé servir, mais pas comment il est conçu.

Un testeur chargé de tester en boîte noire un logiciel de suivi du temps lancera le programme sans connaître sa conception interne et essaiera différentes fonctionnalités et menus pour vérifier qu’ils fonctionnent comme prévu. La raison d’être du test en boîte noire est qu’en l’absence de connaissance approfondie de la conception du logiciel, le testeur aborde le logiciel avec des attentes similaires à celles de l’utilisateur final. 

Quelques avantages du test de boîte noire :

• Les testeurs n’ont pas besoin de connaissances approfondies en langages de programmation car ils utilisent le logiciel comme le ferait un utilisateur.
• Offre un avis impartial sur le logiciel, car le test est réalisé par l’équipe QA et non les développeurs du logiciel.
• Les testeurs n’ont pas besoin de suivre de près le développement du système, ce qui signifie qu’il y a très peu de temps de préparation avant de pouvoir réaliser les tests.

Lecture associée : 10 meilleurs outils de test en boîte noire

2. Test de boîte blanche

Dans le test de boîte blanche, le membre de la QA comprend parfaitement la structure interne et la conception du logiciel testé. Il aborde le test en tant qu’inspecteur, s’assurant que chaque partie du programme fonctionne correctement. Le test de boîte blanche est parfois appelé test de boîte transparente car le testeur observe les interactions entre les unités lors du test du logiciel. Contrairement au test de boîte noire, le testeur de boîte blanche se préoccupe beaucoup moins de l’expérience utilisateur. 

Quelques avantages du test de boîte blanche :

• Les tests peuvent être réalisés dès les premières étapes du développement. L’interface graphique (GUI) n’a pas besoin d’être complètement opérationnelle. 
• Les tests sont plus approfondis et délibérés que les tests de boîte noire.

Dans l’exemple de Pulp Fiction, le testeur de boîte blanche est le personnage de Tim Roth, qui regarde directement ce qu’il y a à l’intérieur de la mallette. 

3. Test de boîte grise

Dans le test de boîte grise, le testeur possède une certaine connaissance de la structure interne et de la conception du logiciel (boîte blanche), mais teste toujours du point de vue d’un utilisateur final (boîte noire). C’est ainsi qu’est né le test de boîte grise. Dans ce type de test, la conception du scénario de test se fait en regardant la structure interne du logiciel, mais le test lui-même est exécuté à travers l’interface utilisateur.

Là encore, s’il s’agissait de cette scène célèbre de Pulp Fiction, le testeur de boîte grise n’est ni le public ni Tim Roth. Cette fois-ci, le testeur est Quentin Tarantino en personne.  

4. Test automatisé

Les tests automatisés utilisent des logiciels pour exécuter des tâches sans intervention manuelle d’un testeur.

Dans les tests manuels, le testeur écrit le code qu’il veut exécuter ou planifie le chemin logiciel qu’il souhaite vérifier. Les tests automatisés prennent en charge ces aspects pour le testeur. Voici une liste rapide de logiciels et outils de QA automatisés que les analystes QA devraient connaître :

• Selenium 
• Cucumber
• Katalon Studio

Pour un examen plus approfondi des outils de tests automatisés, consultez la liste des meilleurs outils de tests automatisés à utiliser.

5. Test unitaire

Les outils de test unitaire permettent de s’assurer que chaque partie individuelle du logiciel fonctionne correctement. Il est extrêmement important de bien effectuer les tests unitaires, sinon l’équipe de développement pourrait subir un revers important lorsqu’elle découvrira qu’une partie clé du logiciel ne fonctionne pas. 

6. Tests de régression

Les outils de tests de régression exécuteront d’anciens tests sur les nouvelles versions afin de s’assurer que le logiciel fonctionne toujours comme prévu. L’exécution de tests de régression protège les développeurs contre les effets secondaires latents en s’assurant qu’une modification du logiciel à un point A n’a pas accidentellement causé une panne à un point D éloigné. 

Pour un analyste QA, avancer de deux pas puis reculer d’un ne doit pas être vu comme négatif. En revenant de temps en temps en arrière, vous vous assurez de ne pas devoir faire cinquante pas en arrière plus tard. 

7. Tests exploratoires

Les tests exploratoires sont faits pour les personnes qui n’aiment pas planifier. Dans la plupart des autres cas, le scénario de test sera soigneusement planifié avant d’être exécuté. Ce n’est pas le cas ici. Lorsqu’un testeur effectue un test exploratoire, il explore le logiciel sans plan prédéfini à l’aide d’outils spécialisés de test exploratoire.

L’avantage du test exploratoire est qu'il permet au testeur de s’adapter à ce qu'il découvre sur le moment, sans avoir à rédiger un autre scénario de test. Le test exploratoire favorise également la collaboration, la création de théories et l’échange d’idées en temps réel.

À mesure que la théorie agile du développement prend de l’importance, les tests exploratoires gagnent en popularité. En permettant aux testeurs QA de faire appel à leur intuition, de nombreux bugs intéressants sont détectés, que l’exécution de tests traditionnels n’aurait pas cherchés. 

Attention : le test exploratoire peut exiger beaucoup de créativité. 

8. Tests fonctionnels

Les tests fonctionnels sont réalisés afin de s’assurer que le logiciel répond bien aux exigences définies avant le début du projet.

Le testeur vérifiera que ses entrées correspondent à la sortie attendue. Cela s’effectue lors des dernières étapes du test, soit lors du test système ou d’acceptation, et il s’agit exclusivement d’un test « boîte noire », car le mode de fonctionnement interne du logiciel importe peu tant qu’il fonctionne. 

9. Tests d’utilisabilité

Les testeurs d’utilisabilité s’assurent que les choix de conception sont à la fois fonctionnels et intuitifs.

Si vous pensez que de nombreux utilisateurs souhaiteront sauvegarder leurs documents toutes les demi-heures, il vaut mieux que la fonction de sauvegarde soit facile d’accès plutôt que cachée derrière quatre sous-menus. 

Bien souvent, un logiciel parfaitement conçu et répondant à un besoin essentiel du marché s’avère difficile, voire impossible à utiliser du point de vue de l’utilisateur. Cela s’explique par un manque de tests d’utilisabilité lors de la phase de test logiciel.

Au final, peu importe la qualité technique du logiciel, il sera difficile de trouver un marché si les utilisateurs ne prennent pas de plaisir à l’utiliser.

Envie d’en savoir plus ?

Le secteur des tests logiciels est en constante évolution, et les analystes QA doivent rester informés des tendances actuelles. Il existe une multitude de ressources sur les tests logiciels, notamment des podcasts, des livres et bien plus encore. 

Abonnez-vous à la newsletter The CTO Club pour recevoir des mises à jour sur les produits, des avis d’outils et d’autres sélections de ressources.