9 types de tests logiciels en ingénierie logicielle

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 pleinement fonctionnel. C’est exact : le logiciel peut être débogué avant même d’être proche de son achèvement. Vous voyez en quoi cela peut être utile ? 

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

• 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 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 prennent 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 QA 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.
• Parcours : L’auteur du code parcourt son document, et l’équipe QA soulève ses questions et préoccupations. Les parcours sont généralement très informels et constituent un bon moyen de discuter de sujets avec des personnes extérieures au domaine logiciel. 
• Revue technique : Des experts techniques se réunissent pour examiner les spécifications techniques du code. Effectuer cette revue 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 au cours de la réunion. Tous les bogues trouvé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 constatés et des problèmes prévisibles. Outre l’avantage de faire participer un large éventail de voix à la discussion, cela permet également à tous les membres de l’équipe de se tenir au courant de l’avancement et de la conception du projet. 

Utilisez les tests statiques si votre équipe :

• Se trouve au début du processus de développement.
• Recherche un moyen rentable de détecter 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.

REJOIGNEZ LA COMMUNAUTÉ

Améliorez votre boîte de réception avec plus de conseils en leadership technologique pour livrer de meilleurs logiciels et systèmes.

Create Free Account

Have an account? Log In

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 tels que l’utilisation du processeur. Les tests dynamiques vérifient que le résultat attendu correspond au résultat obtenu dans la vie réelle. L’objectif principal des tests dynamiques est de vérifier que le produit répond aux exigences de conception et aux exigences fonctionnelles définies avant le début du projet.

En général, quatre étapes sont nécessaires lorsque le logiciel système est testé dynamiquement et les analystes QA doivent les connaître :

• Tests unitaires : lors des tests unitaires d’un logiciel, celui-ci est divisé en composants aussi petits que possible, puis testé individuellement. En procédant ainsi, les analystes QA peuvent avoir l’assurance que chaque partie du logiciel fonctionne comme prévu. Et si un bogue est découvert, il sera plus facile à corriger à ce stade du développement, car le code problématique peut être rapidement isolé. En général, lorsque l’équipe QA commence les tests dynamiques (même si cette étape est parfois prise en charge par l’équipe de développement), elle commence par les tests unitaires.
• Tests d’intégration : après avoir décomposé minutieusement le logiciel en composants et l’avoir testé au moyen de tests unitaires, le logiciel est assemblé en groupes, puis testé à nouveau. Si les tests unitaires visent à s’assurer que chaque partie fonctionne correctement, les tests d’intégration vérifient que ces différentes parties communiquent entre elles comme prévu. Prenons l’exemple de 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 !). 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. À ce stade, un logiciel complet et entièrement intégré est testé. L’objectif du test système est de s’assurer que le logiciel répond aux exigences, c’est-à-dire qu’il fait ce pour quoi il a été conçu. 
• Tests d’acceptation : il s’agit de la dernière étape 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é pour 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 destinée à garantir la 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 et tests de validation 

Les tests de vérification présentent toutes les caractéristiques essentielles des tests statiques. L’objectif d’un test de vérification est de vérifier l’ensemble des documents et du 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 présentent toutes les caractéristiques essentielles des tests dynamiques. Un test de validation vise à confirmer que le logiciel est de qualité, ce qui correspond précisément à l’objectif des tests système et des tests d’acceptation.

Maintenant que nous avons abordé certains concepts clés liés aux 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. Tests automatisés 
5. Tests unitaires
6. Tests de régression
7. Tests 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, où Samuel Jackson ouvre la mallette et 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 comme un spectateur : il sait ce que l’élément testé (qu’il s’agisse d’une mallette ou d’un logiciel système) est censé faire, mais pas de quoi il est constitué.

Un testeur chargé de tester en boîte noire un logiciel de suivi du temps ouvrira le programme sans connaître la conception interne du logiciel et essaiera les différentes fonctionnalités et les différents menus pour s’assurer qu’ils fonctionnent comme prévu. L’intérêt des tests en boîte noire est que, sans connaissance approfondie de la conception du logiciel, le testeur l’abordera 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 beaucoup connaître les langages de programmation, car ils utilisent le logiciel du point de vue d’un utilisateur.
• Ils offrent une évaluation impartiale du logiciel, car le test est réalisé 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 l’exécution 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 des tests 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 que contient la mallette. 

3. Tests en boîte grise

Lors des tests en boîte grise, le testeur possède quelques connaissances de la structure et de la conception internes du logiciel (boîte blanche), mais effectue toujours les tests du point de vue de l’utilisateur final (boîte noire). C’est ainsi que sont nés les tests en boîte grise. Dans ce type de test, la conception du test est élaborée en examinant la structure interne du logiciel, tandis que le test lui-même est réalisé à l’aide de l’interface utilisateur.

Encore une fois, si cette situation correspondait à 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 du logiciel dont il veut vérifier le bon fonctionnement. Les tests automatisés prennent en charge ces tâches à la place des testeurs. Voici une courte liste 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é, consultez la liste des meilleurs outils de test automatisé 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, faute de quoi l’équipe de développement subira un important contretemps lorsqu’elle réalisera 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 garantissant qu’une modification du logiciel au point A n’a pas accidentellement causé une défaillance bien plus loin, au point D. 

Pour un analyste QA, deux pas en avant et un pas en arrière ne doivent pas être considérés comme un résultat négatif. En reculant d’un pas de temps en temps, vous vous assurez de ne pas être sur le point de devoir reculer de cinquante pas 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 effectue un test exploratoire, il explore le logiciel sans plan prédéfini à l’aide d’outils spécialisés de tests exploratoires.

L’avantage des tests exploratoires est qu’ils permettent au testeur de s’adapter instantanément à ses constatations, sans avoir besoin de rédiger un autre cas de test. Les tests exploratoires permettent également de collaborer, d’élaborer des théories et de coopérer, le tout au fur et à mesure.

À mesure que la théorie agile du développement est devenue plus présente, les tests exploratoires se sont eux aussi développés. En permettant aux testeurs QA de faire appel à leur intuition, de nombreux bogues intéressants sont détectés alors qu’une exécution de test traditionnelle ne les aurait peut-être pas recherchés. 

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

More Articles

• 5 types de tests de performance + meilleurs outils
• Tendances des tests logiciels : dernières technologies QA, statistiques et données
• Le côté obscur des tests automatisés et pourquoi le manuel reste essentiel

8. Tests fonctionnels

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

Le testeur logiciel vérifie que les données saisies produisent les résultats attendus. Ces tests sont réalisés au cours de l’une des dernières étapes des tests, soit lors des tests système, soit lors des tests d’acceptation, et constituent exclusivement une forme de test en boîte noire, puisqu’ils ne s’intéressent pas au fonctionnement du logiciel, tant que celui-ci fonctionne. 

9. Tests d’utilisabilité

Les testeurs de l’utilisabilité s’assurent que les choix de conception sont à la fois fonctionnels et 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 à un endroit facilement accessible plutôt que de la cacher 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 avéré totalement impossible à parcourir du point de vue de l’utilisateur. Cela peut s’expliquer par un manque de tests d’utilisabilité lors de la phase de tests 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’apprécient pas de l’utiliser.

Vous en voulez plus ?

Le secteur des tests logiciels évolue constamment, et les analystes QA doivent se tenir au courant des tendances actuelles. Les ressources sur les tests logiciels sont innombrables, notamment les podcasts, les livres et bien plus encore.

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