Chaque entreprise offre des services essentiels et critiques via ses applications, ce qui signifie qu'elles ne peuvent souffrir d'aucune interruption dans leur fonctionnement. Le test logiciel est chargé d'optimiser la gestion de ces ressources afin d'anticiper les possibles dysfonctionnements pour les utilisateurs finaux. Ces tests peuvent être réalisés par les développeurs ou par des professionnels spécialisés tels que les spécialistes de l'assurance qualité (QA).

Explorons plus en détail le test logiciel et son rôle dans la réussite d'un produit.

Niveaux de test logiciel

D'après l'International Software Testing Qualifications Board (ISTQB), les niveaux de test représentent des ensembles d'activités de test organisés et gérés conjointement, où chaque niveau équivaut à une étape distincte du processus de test.

Voici les différents niveaux de test :

• Tests unitairesIls évaluent le comportement de la plus petite partie du code d'une application, sans considérer l'interaction avec d'autres parties.
• Tests d'intégrationIls vérifient l'interaction entre les unités, leur collaboration, et testent généralement une fonctionnalité complète, y compris la persistance des données.
• Tests systèmeIls se concentrent sur le comportement et les capacités du système ou du produit. Ils incluent des tests de bout en bout, de l'interaction avec les interfaces utilisateur au traitement des données dans le back-end. Ils couvrent également les aspects non fonctionnels. Les tests d'interface utilisateur peuvent inclure des scénarios positifs et négatifs, avec ou sans interaction avec le back-end.
• Tests d'acceptationIls évaluent le comportement du système dans son ensemble et fournissent des informations pour valider son état lors de sa mise en œuvre et de son utilisation par les utilisateurs finaux. Ils peuvent également vérifier la conformité aux normes légales et réglementaires. Ces tests peuvent être de différents types, tels que les tests d'acceptation utilisateur (UAT), les tests d'acceptation opérationnelle (OAT), et les tests d'acceptation réglementaires et contractuels. Ce type de test est subdivisé en :
  • Test d'acceptation utilisateur (UAT)Une version du système est mise à la disposition de l'utilisateur pour exécuter les processus métier et vérifier qu'il est possible de les exécuter avec un minimum de difficulté, de coût et de risque. 
  • Test d'acceptation opérationnelle (OAT)Cela se fait dans un environnement contrôlé par l'équipe d'administration et couvre les tests de sauvegarde et de récupération, la gestion des utilisateurs, la maintenance des tâches, la vulnérabilité, la sécurité et les performances.
  • Tests d'acceptation réglementaires et contractuelsBasés sur des critères d'acceptation contractuels pour un développement logiciel spécifique.
• Tests alpha et bêtaIls sont similaires aux tests d'acceptation mais ne sont pas planifiés à l'avance.

Les types de tests logiciels

Les types de tests représentent un ensemble d'activités axées sur le test de caractéristiques spécifiques du système, ou d'une partie du système, en fonction de leurs objectifs. Ils se subdivisent en :

• Tests fonctionnelsIls vérifient si le système fait ce qu'il est censé faire (spécifications métier), c'est-à-dire qu'ils testent la fonctionnalité du logiciel. Les exigences peuvent être rédigées sous forme de documents, de user stories, de cas d'utilisation, ou ne pas être documentées du tout dans le pire des cas.
• Tests non fonctionnelsCeux-ci sont plus larges et valables pour tous les systèmes, car ils sont basés sur la norme ISO-25010, qui traite de l'utilisabilité, de la performance, de l'efficacité et de la sécurité.
• Tests en boîte blancheIls se basent sur la structure interne et ont accès au code source. Les tests unitaires sont des tests en boîte blanche.
• Tests en boîte noireIls se basent sur les exigences de base du logiciel et se concentrent sur les actions que ces exigences devraient remplir. Les tests système, d'acceptation, alpha et bêta sont de type boîte noire. Ce type de test vérifie les données de sortie sans se soucier de la manière dont elles sont générées en interne – par exemple : un champ de date de naissance rempli avec des dates futures et des champs obligatoires sans validation.

Plus le code est visible, plus la manière dont la fonctionnalité est réalisée est claire. Cela se traduit par des quantités moindres de spécifications et de spécifications métier testées, et une transparence accrue du test, se rapprochant ainsi d'un test en boîte blanche. À l'inverse, moins le code est visible, moins la manière dont la fonctionnalité est réalisée est claire. Cela implique des quantités plus importantes de spécifications et de spécifications métier, et une transparence moindre du code, se rapprochant progressivement d'un test en boîte noire. L'image ci-dessous illustre cette idée.

Les méthodes de test logiciel

Les niveaux et types de tests logiciels mentionnés précédemment peuvent être réalisés de deux manières :

• Tests manuelsCes tests sont effectués manuellement par un humain (spécialiste de l'assurance qualité) pour couvrir des tests exploratoires, des tests d'utilisabilité ou des cas de test spécifiés dans les critères d'acceptation d'une user story, par exemple. Cette approche présente des avantages et des inconvénients :
  • Avantages :
    • Les conditions de test sont similaires à celles rencontrées dans un environnement de production.
    • Ils peuvent détecter des défauts visuels.
    • Coût réduit.
    • Moins de connaissances techniques requises.
  • Inconvénients :
    • Temps d'exécution plus long.
    • Risque accru de ne pas détecter les défauts car les tests ne sont pas automatisés.

• Tests automatisésLes tests sont conçus pour être exécutés automatiquement. Ils requièrent l'utilisation d'outils, de scripts et de logiciels pour leur mise en œuvre et leur exécution.
  • Avantages :
    • Fiabilité accrue.
    • Exécution plus rapide que les tests manuels.
    • Excellents pour les tests de charge et de performance.
  • Inconvénients :
    • Développement chronophage.
    • Nécessité d'outils spécifiques pour chaque phase de test.
    • Peuvent ne pas détecter les problèmes d'utilisabilité.
    • Un investissement supplémentaire dans l'infrastructure peut être requis dans certains cas.

Flux de test logiciel

Le flux de test logiciel est une séquence d'activités organisées et exécutées pour tester un logiciel et garantir sa qualité. Or, Chaque type de test peut être appliqué dans différents environnements, où les applications sont installées, et à différentes phases de développement selon l'infrastructure, les besoins et le budget de chaque projet/application, comme illustré dans l'image ci-dessous.

Exemple test flow

La pyramide des test logiciels

Généralement, le nombre de tests unitaires développés est généralement plus élevé que celui des tests d'intégration (également appelés tests de service) et des tests d'interface utilisateur (compris dans le niveau des tests système), car ils sont moins coûteux, moins spécifiques et plus rapides à mettre en œuvre.

Cette logique est illustrée par la pyramide des tests logiciels.

Pyramide des tests de logiciels : temps x coût x quantité

Conclusion

Parmi les tests logiciels les plus courants développés, on retrouve les tests unitaires, les tests d'intégration, et parfois les tests d'interface utilisateur (UI). Différents niveaux de tests sont mis en place en tenant compte de leurs spécificités :

• Les tests unitaires assurent le bon fonctionnement des plus petites unités du système.
• Les tests d'intégration vérifient le fonctionnement complet d'une fonctionnalité.
• Les tests d'interface utilisateur, étant plus proches de l'expérience de l'utilisateur final, améliorent la fiabilité, la qualité et la stabilité de l'application dans les environnements de production, et réduisent les coûts liés aux défauts pouvant être détectés avant d'atteindre la production.

Pour livrer un produit de haute qualité à moindre coût et dans un délai réduit, il est recommandé d'opter pour une combinaison de tests, qu'ils soient manuels ou automatisés. Cependant, le choix des types de tests et leur nombre dépendent de la scalabilité de l'application, du budget alloué, du calendrier du projet et des besoins du produit.