9 types de tests logiciels en ingénierie logicielle

Les tests logiciels sont un savoir-faire. Un testeur logiciel, comme un artisan, doit avoir une bonne compréhension des outils de test logiciel à sa disposition. Nous avons compilé une liste de 9 types différents de tests logiciels, ainsi que les outils utilisés pour chacun d’eux, afin d’aider les analystes qualité et toute autre personne travaillant dans le domaine des tests logiciels à mieux comprendre leur savoir-faire.

Pourquoi avons-nous besoin des tests logiciels ?

Parfois, il est important de se rappeler pourquoi ce que l’on fait compte. Le fait est que chaque logiciel développé ayant connu le succès y est parvenu grâce à l’aide de testeurs logiciels travaillant sans relâche pour garantir que le produit respecte les normes les plus élevées possibles. Voici trois raisons pour lesquelles les tests logiciels sont importants. 

1. Satisfaction client : Lors du développement d’un projet, il peut être facile de se perdre dans les méandres du code et d’oublier que l’utilisateur doit également être satisfait du fonctionnement du logiciel. Les analystes qualité et les autres membres de l’équipe qualité remplissent ce rôle. 
2. Qualité du produit : Dans tout métier où une équipe ou une personne crée quelque chose à partir de rien, une autre équipe doit détecter ses erreurs. Les rédacteurs ont besoin de correcteurs. Les réalisateurs de films ont également besoin de monteurs. Les développeurs logiciels n’ont pas besoin de correcteurs, mais ils ont besoin d’une équipe qualité pour fournir un point de vue objectif et détecter les erreurs éventuelles. 
3. Sécurité : Chaque jour qui passe semble rendre ce point de plus en plus important. Les clients veulent avoir l’esprit tranquille en sachant que les informations qu’ils saisissent dans le logiciel et le travail qu’ils y effectuent restent privés. Une partie du rôle de l’équipe qualité consiste à garantir cette confiance aux clients. 

Méthodologies de test logiciel

Chaque technique de test logiciel mentionnée dans cet article appartient à l’une des deux grandes catégories suivantes : les tests statiques et les tests dynamiques. Avant d’examiner les détails spécifiques des neuf techniques de test logiciel, je vais expliquer la différence entre ces deux méthodologies et préciser à quel moment elles interviennent dans le cycle de développement logiciel. 

Tests statiques

Les tests statiques sont un type de test logiciel effectué au début du cycle de développement. Il s’agit d’un moyen économique de détecter les bogues avant qu’ils ne deviennent de véritables problèmes pour l’équipe de développement. Les tests statiques sont exécutés tôt dans le cycle de développement, car ils peuvent être réalisés sans disposer d’un logiciel entièrement fonctionnel. C’est exact : le logiciel peut être débogué alors même qu’il est encore loin d’être terminé. Vous voyez en quoi cela peut être utile ? 

Les tests statiques sont effectués de deux manières :

• Examens manuels : le code est analysé par un analyste qualité ou un testeur. 
• Analyse automatique : un outil de test vérifie automatiquement le document du programme et signale les erreurs éventuelles.

Les tests statiques sont :

• Effectués sans exécuter le code.
• Économiques.
• Utiles pour s’assurer que le logiciel respecte les spécifications de vérification.
• Un moyen de déterminer la cause première des bogues.

La plupart des tests statiques sont réalisés sous la forme d’examens de documents. Dans ce scénario, un document est soit une description écrite d’un produit (appelée document de conception logicielle), soit le code source du programme. Voici quelques techniques de test statique que tout analyste qualité devrait connaître :

• Revue informelle : il n’existe pas de directives strictes pour la revue informelle. L’équipe examine les documents de test et commente ce qu’elle observe. Aucune documentation n’est produite.
• Lecture collective : l’auteur du code présente son document, et l’équipe qualité soulève les questions et les préoccupations éventuelles. Les lectures collectives sont généralement très informelles et constituent un bon moyen de discuter de sujets avec des personnes extérieures au domaine des logiciels. 
• Revue technique : des experts techniques se réunissent pour examiner les spécifications techniques du code. Effectuer cette étape tôt dans le processus de développement garantit que le produit final respectera les spécifications requises.
• Inspections : il s’agit de la plus formelle de toutes les revues. Une équipe de modérateurs formés inspecte minutieusement les documents pendant la réunion. Tous les bogues détectés sont officiellement documentés et consignés pour être examinés. Un suivi est effectué afin de vérifier que les bogues documentés ont été corrigés. 

Dans la plupart des cas, les revues de tests statiques sont utiles, car toute l’équipe d’assurance qualité analysera le produit et proposera des modifications en fonction des problèmes observés et des problèmes prévisibles. En plus de permettre à un large éventail de personnes de participer à la discussion, cela permet également à tous les membres de l’équipe de se mettre à jour sur l’avancement et la conception du projet. 

Utilisez les tests statiques si votre équipe est:

• Au début du processus de développement.
• À la recherche d’un moyen rentable de trouver les bogues.
• Dispose d’un logiciel qui n’est pas prêt à être exécuté.
• Souhaite détecter les erreurs dès le début du développement.

Tests dynamiques

Contrairement aux tests statiques, les tests dynamiques sont un type de test logiciel qui nécessite l’exécution du code. Naturellement, cela exige que le développement soit plus avancé dans le cycle de production. L’avantage de tester du code exécutable est que les analystes QA peuvent observer le comportement du logiciel lorsqu’il fonctionne dans une situation réelle. Il s’agit d’un excellent moyen de vérifier le comportement fonctionnel du logiciel ainsi que d’autres éléments comme l’utilisation du processeur. Les tests dynamiques vérifient que le résultat attendu correspond au résultat réel. L’objectif principal des tests dynamiques est de vérifier que le produit respecte les exigences de conception et les exigences fonctionnelles définies avant le début du projet.

En général, quatre étapes sont nécessaires lors des tests dynamiques d’un logiciel système et les analystes QA doivent les connaître:

• Tests unitaires: Lorsqu’un logiciel est soumis à des tests unitaires, il est divisé en composants aussi petits que possible, puis testé individuellement. En procédant ainsi, les analystes QA peuvent être rassurés, sachant que chaque partie du logiciel fonctionne comme prévu. De plus, si un bogue est découvert, il sera plus facile à corriger à cette étape du développement, car le code problématique peut être rapidement isolé. En général, lorsque l’équipe QA commence les tests dynamiques (bien que cette étape soit parfois prise en charge par l’équipe de développement), elle commence par les tests unitaires.
• Tests d’intégration: Après que le logiciel a été soigneusement décomposé en composants et testé au moyen de tests unitaires, il est assemblé en groupes, puis testé à nouveau. Si les tests unitaires servent à vérifier que chaque partie fonctionne correctement, les tests d’intégration vérifient que ces différentes parties communiquent entre elles comme prévu. Imaginez l’assemblage d’une voiture. À chaque étape de l’assemblage, les pièces de la voiture (le moteur, les pédales, le volant) sont testées individuellement. Ensuite, la voiture est assemblée et testée dans son ensemble afin de vérifier que la pédale d’accélérateur communique correctement avec le moteur (et que les freins fonctionnent également correctement!). Vous cherchez à garantir une intégration fluide entre les modules? Nos outils de test logiciel recommandés peuvent vous aider à y parvenir.
• Tests système: Les tests système constituent le troisième niveau des tests logiciels. À cette étape, un logiciel complet et entièrement intégré est testé. L’objectif du test système est de s’assurer que le logiciel respecte les exigences, c’est-à-dire qu’il fait ce pour quoi il a été conçu. 
• Tests d’acceptation: Il s’agit de l’étape finale des tests dynamiques. Le test d’acceptation consiste à vérifier une nouvelle fois le respect des exigences et à s’assurer que le logiciel est suffisamment abouti pour atteindre un niveau acceptable. Il est effectué afin de vérifier qu’aucune erreur ne s’est glissée lors des autres étapes de test. En substance, il s’agit d’une double vérification par mesure de sécurité. 

Étapes des tests dynamiques

1. Tests unitaires
2. Tests d’intégration
3. Tests système
4. Tests d’acceptation
   

Conseil rapide: tests de vérification ou de validation 

Les tests de vérification partagent toutes les caractéristiques clés des tests statiques. L’objectif d’un test de vérification est de vérifier tous les documents et le code, ce qui est réalisé au moyen des mêmes méthodes que celles utilisées lors des tests statiques.

De même, les tests de validation partagent toutes les caractéristiques clés des tests dynamiques. Un test de vérification vise à confirmer que le logiciel est de haute qualité, ce qui correspond exactement à l’objectif des tests système et des tests d’acceptation.

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

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

1. Boîte noire
2. Boîte blanche
3. Boîte grise 
4. Automatisés 
5. Unitaires
6. De régression
7. Exploratoires
8. Tests fonctionnels
9. Tests d’utilisabilité

1. Tests en boîte noire

Les tests en boîte noire sont une stratégie de test logiciel dans laquelle la conception du système logiciel testé est inconnue du testeur.

Vous souvenez-vous de cette scène à la fin de Pulp Fiction, lorsque Samuel Jackson ouvre la mallette et que son visage s’illumine ? En tant que spectateurs, nous savons ce que la mallette signifie et représente dans le contexte du film, mais nous n’apprenons jamais ce qu’elle contient. Un testeur en boîte noire est comparable au spectateur : il sait ce que la chose testée, qu’il s’agisse d’une mallette ou d’un logiciel système, est censée faire, mais pas de quoi elle est constituée.

Un testeur chargé de tester en boîte noire un logiciel de suivi du temps ouvrira le programme sans connaître sa conception interne et essaiera les différentes fonctionnalités et menus pour s’assurer qu’ils fonctionnent comme prévu. La raison d’être des tests en boîte noire est que, sans connaissance approfondie de la conception du logiciel, le testeur abordera celui-ci avec des attentes similaires à celles de l’utilisateur final. 

Les tests en boîte noire présentent notamment les avantages suivants :

• Les testeurs n’ont pas besoin de connaissances approfondies des langages de programmation, car ils utilisent le logiciel du point de vue d’un utilisateur.
• Ils fournissent une évaluation impartiale du logiciel, car le test est effectué par l’équipe d’assurance qualité plutôt que par les développeurs du logiciel.
• Les testeurs n’ont pas besoin de suivre l’évolution du développement des systèmes logiciels, ce qui signifie que le délai de préparation avant la réalisation des tests est très court.

À lire également : Les 10 meilleurs outils de test en boîte noire

2. Tests en boîte blanche

Lors d’un test en boîte blanche, le membre de l’équipe d’assurance qualité comprend parfaitement la structure interne et la conception du logiciel testé. Il aborde le test comme un inspecteur, en s’assurant que chaque partie du programme fonctionne correctement. Les tests en boîte blanche sont parfois appelés tests en boîte transparente, car le testeur observe les interactions entre les unités lorsqu’il teste le logiciel. Contrairement aux tests en boîte noire, le testeur en boîte blanche se préoccupe beaucoup moins de l’expérience utilisateur. 

Les tests en boîte blanche présentent notamment les avantages suivants :

• Les tests peuvent être exécutés dès les premières étapes du développement. L’interface graphique utilisateur (GUI) n’a pas besoin d’être entièrement fonctionnelle. 
• Les tests sont plus approfondis et plus rigoureux que les tests en boîte noire.

Dans l’exemple de Pulp Fiction, le testeur en boîte blanche est le personnage interprété par Tim Roth, qui regarde directement ce qui se trouve dans la mallette. 

3. Tests en boîte grise

Lors d’un test en boîte grise, le testeur possède certaines connaissances de la structure et de la conception internes du logiciel (boîte blanche), mais il effectue toujours les tests du point de vue de l’utilisateur final (boîte noire). C’est ainsi que les tests en boîte grise sont nés. Lors d’un test en boîte grise, la conception du test est élaborée en examinant la structure interne du logiciel, tandis que le test proprement dit est réalisé à l’aide de l’interface utilisateur.

Encore une fois, s’il s’agissait de cette célèbre scène de Pulp Fiction, le testeur en boîte grise ne serait ni le spectateur ni Tim Roth. Cette fois, le testeur serait Quentin Tarantino lui-même.  

4. Tests automatisés

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

Lors des tests manuels, le testeur écrit le code qu’il souhaite exécuter ou planifie le parcours logiciel dont il veut vérifier le bon fonctionnement. Les tests automatisés s’occupent de ces tâches à la place des testeurs. Voici une liste rapide de logiciels et d’outils d’assurance qualité automatisés que les analystes QA devraient connaître :

• Selenium 
• Cucumber
• Katalon Studio

Pour une analyse plus approfondie des outils de test automatisés, consultez la liste des meilleurs outils de test automatisés que vous devriez utiliser.

5. Tests unitaires

Les outils de tests unitaires s’assurent que chaque partie individuelle du logiciel fonctionne correctement. Il est extrêmement important de veiller à ce que les tests unitaires soient réalisés correctement, sans quoi l’équipe de développement subira un sérieux contretemps lorsqu’elle découvrira plus tard qu’une partie essentielle de son logiciel ne fonctionne pas. 

6. Tests de régression

Les outils de tests de régression exécutent d’anciens tests sur de 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 latents en s’assurant qu’une modification apportée au logiciel au point A n’a pas accidentellement causé une défaillance bien plus loin, au point D. 

Pour un analyste QA, faire deux pas en avant et un pas en arrière ne doit pas être considéré comme négatif. En faisant un pas en arrière de temps en temps, vous vous assurez de ne pas être sur le point d’en faire cinquante en arrière plus tard.

7. Tests exploratoires

Les tests exploratoires s’adressent aux personnes qui n’aiment pas planifier. Dans la plupart des autres situations, le cas de test est minutieusement planifié avant son exécution. Ce n’est pas le cas ici. Lorsqu’un testeur réalise un test exploratoire, il explore le logiciel sans plan prédéfini, à l’aide d’outils de tests exploratoires spécialisés.

L’avantage des tests exploratoires est qu’ils permettent au testeur de s’adapter instantanément à ses découvertes, sans avoir besoin de rédiger un autre cas de test. Les tests exploratoires permettent également de collaborer et d’élaborer des théories en temps réel.

À mesure que la théorie agile du développement s’est imposée, les tests exploratoires ont eux aussi gagné en importance. En permettant aux testeurs QA de faire appel à leur intuition, ils permettent de détecter de nombreux bogues intéressants qu’une exécution de tests traditionnelle n’aurait peut-être pas recherchés. 

Attention : les tests exploratoires peuvent nécessiter une grande créativité. 

8. Tests fonctionnels

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

Le testeur logiciel vérifie que ses entrées correspondent aux résultats attendus. Ils sont réalisés lors de l’une des dernières étapes des tests, soit dans le cadre des tests système, soit dans celui des tests d’acceptation, et constituent exclusivement une forme de test en boîte noire, car ils ne s’intéressent pas au fonctionnement du logiciel tant que celui-ci fonctionne. 

9. Tests d’utilisabilité

Les testeurs d’utilisabilité s’assurent que les choix de conception sont fonctionnels tout en restant intuitifs.

Si vous prévoyez que de nombreux utilisateurs de votre logiciel voudront sauvegarder leurs documents toutes les demi-heures, il est préférable de placer la fonction de sauvegarde dans un endroit facilement accessible plutôt que de la dissimuler derrière quatre sous-menus. 

À de nombreuses reprises, un logiciel parfaitement fonctionnel et répondant à un besoin important du marché a été développé, mais il s’est révélé totalement impossible à utiliser du point de vue de l’utilisateur. Cela peut s’expliquer par un manque de tests d’utilisabilité pendant la phase de test du logiciel.

En fin de compte, quelle que soit la qualité technique d’un logiciel, il sera difficile de trouver un marché si les utilisateurs n’aiment pas s’en servir.

Vous en voulez plus ?

Le secteur des tests logiciels est en constante évolution, et les analystes QA doivent se tenir au courant des tendances actuelles. Les ressources consacrées aux tests logiciels sont innombrables, notamment les podcasts, les livres, les bulletins d’information et bien plus encore.

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