Haley travaille dans l’assurance qualité en tant que testeuse de logiciels. Elle est en charge de la gestion des projets de tests ainsi que de la formation des nouveaux testeurs.
Qu’est-ce que le test logiciel ?
Les tests de logiciels sont un domaine en évolution rapide et en pleine croissance. Souvent, il peut y avoir un malentendu entre les testeurs, les développeurs et la direction concernant la terminologie des tests. Pour cette raison, il est important d’avoir des définitions claires et partagées des tests.
Cet article traitera de certains des types courants de tests de logiciels. Il est important de garder à l’esprit qu’en pratique, il peut être facile pour deux types de tests (ou plus) de se chevaucher. Académiquement, ce sont tous des termes très distincts, mais pragmatiquement, ils peuvent commencer à fusionner.
Je ne parlerai pas non plus spécifiquement de l’automatisation en tant que type de test, car la plupart de ces types de tests peuvent être effectués manuellement ou automatiquement avec du code.
Types courants de tests de logiciels
- Test fonctionel
- Tests d’intégration
- Test de la boîte noire
- Essais en boîte blanche
- Les tests de régression
- Test de fumée
- Essais exploratoires
- Test d’acceptation par l’utilisateur
Remarque : Il ne s’agit pas d’une liste complète des types de tests de logiciels.
Qu’est-ce que les tests fonctionnels ?
Les tests fonctionnels sont un sous-groupe d’autres types de tests. Les tests fonctionnels sont tous les tests de boîte noire (pas côté code) qui garantissent que le logiciel remplit les fonctions appropriées. C’est le type de test qui permet de s’assurer que les exigences sont respectées.
Les types de tests fonctionnels comprennent :
- Test de santé mentale
- Test de fumée
- Les tests de régression
- Tests d’intégration
- tests d’utilisation
Qu’est-ce qu’un test d’intégration ?
Les tests d’intégration sont extrêmement importants pour les logiciels qui fonctionnent sur un modèle serveur-client ou en tant que système distribué. Cela signifie des applications qui ne vivent pas uniquement sur l’ordinateur de l’utilisateur et des applications qui peuvent avoir plusieurs serveurs différents sur le back-end.
Un exemple d’architecture pourrait être :
- Le serveur principal qui exécute le tableau de bord d’une application Web.
- Un serveur séparé qui contient uniquement la base de données.
- Un serveur distinct qui exécute des rapports ou des algorithmes pour le système.
- Un logiciel supplémentaire qui permet à cette application de se connecter à une application tierce.
Les tests d’intégration pour le scénario décrit ci-dessus impliqueraient de s’assurer que chaque serveur est capable de parler aux autres serveurs appropriés, que les informations correctes sont transmises d’un service à l’autre, etc.
Les tests d’intégration peuvent également se produire à un niveau plus restreint, une fois que les développeurs ont terminé les microservices ou les petits morceaux de code qui doivent interagir avec d’autres parties.
Faites défiler pour continuer
Test de la boîte noire
Le test de boîte noire est un terme général pour tout test où le code n’est pas examiné.
L’idée est que le produit est comme une boîte noire. L’utilisateur ne se soucie pas de ce qui se passe dans la boîte noire tant qu’il obtient la sortie correcte de son entrée.
La plupart des cas de test manuels fonctionnels sont des tests de boîte noire.
Test de la boîte blanche
Les tests en boîte blanche se concentrent sur les propriétés internes de l’application, plutôt que sur la fonctionnalité d’utilisation du produit. L’un des principaux avantages des tests en boîte blanche est qu’ils détectent les erreurs avant qu’elles n’apparaissent au niveau de l’utilisateur. Ceci est particulièrement utile pour les erreurs cachées qui peuvent ne pas causer de défauts visibles maintenant, mais provoquer des défauts avec d’autres modifications du code.
Les tests unitaires sont le type de test boîte blanche le plus courant.
Les tests de régression
L’objectif des tests de régression est de s’assurer qu’aucune nouvelle fonctionnalité, modification d’architecture ou correction de défaut récente n’a accidentellement créé de nouveaux défauts. Souvent, un changement de code peut avoir un effet en cascade et créer des défauts dans une zone qui peut être manquée lorsque ce correctif est testé.
Les tests de régression sont très utiles si de nombreuses modifications ont été apportées à un produit dans plusieurs domaines. Cela peut cependant être le domaine de test qui prend le plus de temps. Dans le pire des cas, l’ensemble du produit doit être testé pour toutes les exigences.
Une compétence très précieuse est la capacité d’équilibrer la quantité et les types de tests corrects pour un test de régression.
Les tests de régression sont généralement utilisés juste avant la sortie d’un produit.
Test de fumée
Les tests de fumée, également appelés tests de santé mentale, sont une forme de test de haut niveau. Les tests de fumée complètent le test du chemin heureux pour les fonctions les plus importantes du produit tout en recherchant tout défaut critique à ce niveau.
Cela permet de s’assurer qu’un bogue critique évident n’est pas découvert à mi-chemin du test alors qu’un clic rapide l’aurait montré.
Essais exploratoires
Les tests exploratoires consistent à donner à un testeur un domaine ou une fonctionnalité d’un produit à explorer. Ils ne suivent pas les cas de test détaillés, mais peuvent les utiliser à la place comme un script vaguement défini. Les tests exploratoires ont tendance à se concentrer sur de nombreux tests négatifs.
Ce type de test a tendance à se concentrer sur la question « Je me demande ce qui se passerait si je ? » Les testeurs recherchent des choses qui ne sont pas couvertes par les exigences. Comme ajouter un produit et le retirer cinq fois d’un panier en ligne, puis essayer d’acheter autre chose.
Test d’acceptation par l’utilisateur
Le test d’acceptation par l’utilisateur (UAT) est la dernière étape du processus de test. C’est à ce moment que l’utilisateur final d’un produit utilise le produit. Le produit doit être stable et prêt à passer à la production à ce stade.
Une fois que l’utilisateur « accepte » le produit, il est prêt à passer en production.
C’est une pratique plus courante avec les projets qui ont un seul client.
Cet article est exact et fidèle au meilleur de la connaissance de l’auteur. Le contenu est uniquement à des fins d’information ou de divertissement et ne remplace pas un conseil personnel ou un conseil professionnel en matière commerciale, financière, juridique ou technique.
