Fondamentaux du test logiciel

Le test logiciel s’applique à de nombreux domaines et secteurs. Chaque projet présente un nouveau défi. Avant de commencer les tests, vous devez comprendre le point de vue du client et le domaine concerné. Les méthodes de test peuvent aussi varier d’un projet à l’autre. Une bonne maîtrise des fondamentaux est donc le premier pas vers la réussite.

Pourquoi le test logiciel est-il nécessaire ?

Les développeurs peuvent introduire des erreurs, des défauts ou des bogues sans le vouloir. Les logiciels modernes sont complexes. Un malentendu peut donc conduire à une logique incorrecte et à du code erroné.

Les tests permettent de repérer les défauts pour les corriger et améliorer la qualité du logiciel. L’objectif est de développer et de livrer des applications sans bogues. Quand une entreprise s’engage à développer un logiciel pour un client, des exigences légales, contractuelles et sectorielles encadrent le travail. Une entreprise soucieuse de la qualité intègre les tests à ses bonnes pratiques.

Il est difficile de savoir quelle quantité de tests suffit. Une planification rigoureuse et des cas de test bien conçus permettent une livraison de qualité.

Qui réalise les tests logiciels ?

Qui doit tester le logiciel ? Les développeurs vérifient souvent leur code plusieurs fois avant de le transmettre. Pourtant, des défauts peuvent subsister, car il est difficile de repérer ses propres erreurs.

Un testeur adopte un point de vue impartial, celui du client, et se concentre sur les spécifications et les exigences. Il peut ainsi repérer des problèmes que le développeur a négligés. Les tests devraient donc toujours être réalisés par des testeurs indépendants.

Séparer les équipes de développement et de test présente aussi des inconvénients. Des problèmes de communication peuvent apparaître. Les développeurs risquent de négliger la revue du code s’ils considèrent que la qualité relève des testeurs. Cela augmente la charge de l’équipe de test.

Les développeurs testent parfois le travail de leurs collègues. C’est ce qu’on appelle le test entre pairs, ou buddy testing. Chaque équipe de développement devrait disposer de testeurs dédiés. Un projet compte généralement au moins une équipe de test dédiée. Certaines entreprises créent des équipes distinctes pour l’utilisabilité, la performance, la sécurité et d’autres types de tests. D’autres confient le travail à des sociétés spécialisées, à des testeurs indépendants ou à des consultants.

Que faut-il vraiment tester ?

Prenez le temps de comprendre les exigences du projet et le contexte réel d’utilisation du logiciel. Vous pourrez alors décider quoi tester et élaborer une stratégie de test adaptée.

Ouvrir le schéma en taille réelle ↗

Que faut-il vraiment tester ?

Quand teste-t-on le logiciel ?

Commencer les tests tôt aide les développeurs à tenir les délais et économise du temps, de l’argent et des efforts. Les défauts trouvés tard dans le développement peuvent coûter cher à corriger. Découpez le développement en étapes et testez les résultats de chaque étape avant de poursuivre. Cela favorise une livraison dans les délais et de meilleurs résultats. L’intégration devient aussi plus facile si chaque module a déjà été testé séparément par rapport à ses spécifications.

À quelle fréquence faut-il tester ?

Testez en parallèle du développement et recherchez autant de défauts que possible dès les premières étapes. La fréquence des tests dépend du niveau de qualité visé. Les constats précoces permettent de modifier la conception tant que ces changements restent simples et peu coûteux. Plus tard, les changements importants deviennent difficiles et onéreux.

Ouvrir le schéma en taille réelle ↗

À quelle fréquence faut-il tester ?

Que sont les normes de test logiciel ?

Les normes de test comptent à la fois pour les clients et pour les producteurs. Les clients investissent dans un logiciel et veulent être sûrs que sa qualité justifie leur achat.

Les entreprises reconnues encadrent la qualité de leurs produits par des normes publiquement approuvées. Le respect de ces normes donne des garanties sur le produit et sur son comportement attendu. Les clients peuvent ainsi avoir confiance dans le niveau de qualité du logiciel qu’ils achètent.

Pour les producteurs, les normes aident à améliorer le produit final. Une fois qu’une entreprise a choisi ses normes, elle peut réutiliser cette base dans de futurs projets sans repartir de zéro. De nombreuses normes de test aident à évaluer la qualité et à améliorer l’efficacité des tests. Aucune ne couvre cependant tous les aspects du test logiciel.

Les normes qui intègrent les tests dans un ensemble plus large d’exigences et celles qui portent spécifiquement sur les tests peuvent toutes deux orienter votre travail.

Qu’est-ce que la testabilité d’un logiciel ?

La testabilité décrit la facilité avec laquelle on peut tester un système logiciel. Évaluez-la tôt pour estimer les ressources nécessaires aux tests. Les tests révèlent des défauts. La testabilité aide à repérer les zones où des défauts risquent de rester cachés. Une testabilité élevée facilite les tests, tandis qu’une testabilité faible demande plus d’efforts. Tenez compte des facteurs suivants.

1. La contrôlabilité permet de maîtriser le processus de test pour l’optimiser.
2. L’observabilité suppose que le comportement et les facteurs qui influencent le résultat soient visibles et puissent être testés.
3. La disponibilité signifie que vous pouvez accéder au système pour le tester.
4. La simplicité d’une conception cohérente, de fonctions claires et de pratiques de programmation simples réduit la complexité des tests. Un logiciel plus complexe est plus difficile à tester.
5. La stabilité facilite les tests. Des changements fréquents de conception peuvent les perturber.
6. Les informations disponibles sur le logiciel influencent fortement l’efficacité des tests.

Gardez à l’esprit les liens suivants entre testabilité et défauts.

1. Une meilleure testabilité favorise des tests de meilleure qualité et réduit le nombre de défauts.
2. Une testabilité plus faible peut réduire la qualité des tests et laisser davantage de défauts dans le système.

Vérification et validation du logiciel

La vérification et la validation correspondent à deux types d’analyse. La validation demande si vous construisez le bon système. Répond-il aux exigences du client ?

La vérification demande si vous construisez correctement le système. Elle porte sur la qualité technique et le respect des normes requises.

La validation s’assure que les spécifications répondent aux besoins du client. La vérification contrôle que le développement suit les normes de qualité logicielle et les pratiques d’ingénierie de l’organisation.

Ouvrir le schéma en taille réelle ↗

Vérification et validation du logiciel

Certaines approches prévoient une vérification à chaque étape du développement, mais concentrent la validation au début et à la fin, pendant l’analyse des exigences et les tests d’acceptation. Cette démarche est difficile à appliquer. Il est difficile de recueillir toutes les exigences du client au départ, et elles changent souvent après le lancement du développement. Les équipes de développement peuvent elles-mêmes demander des changements. Menez donc la vérification et la validation tout au long du développement.

Les testeurs utilisent la vérification et la validation, ou V&V, pour examiner différents aspects de la qualité du logiciel.

Test logiciel et débogage

Les tests et le débogage ont des objectifs différents. Les tests révèlent les défauts. Le débogage intervient après leur découverte et élimine leur cause.

Une fois qu’un testeur signale un défaut, les développeurs recherchent sa cause première. Ils examinent les modules concernés, repèrent le problème dans le code et le corrigent. Le débogage identifie et traite la cause étape par étape.

Comprenez les causes possibles d’un défaut avant d’essayer de le corriger. Déboguer sans assez d’informations peut introduire un autre défaut dans un module lié. Évitez les essais sans méthode. Après la correction, remettez le module au testeur pour qu’il le teste en profondeur.

1. Les tests révèlent les défauts. Le débogage localise et corrige leurs causes.
2. Les tests jouent un rôle important dans le développement. Le débogage traite les défauts qu’ils mettent au jour.
3. Les tests commencent tôt dans le développement. Le débogage commence lorsque des défauts sont signalés.
4. Les tests comprennent la vérification et la validation (V&V). Le débogage recherche et corrige la cause d’un défaut.

Qu’est-ce qu’un défaut ?

Un défaut est un écart par rapport aux spécifications des exigences logicielles. Il peut apparaître dans le code ou la conception et produire des résultats incorrects quand le programme s’exécute.

1. Un code qui contient de nombreux défauts est souvent qualifié de code bogué.
2. Un rapport de bogue décrit la nature d’un défaut.
3. Les outils de suivi des bogues permettent de suivre les défauts dans un système.
4. Une technique de test consiste à introduire délibérément des défauts dans le code. On observe ensuite le résultat pour vérifier que le système réagit à ces problèmes comme prévu.

Ouvrir le schéma en taille réelle ↗

Qu’est-ce qu’un défaut ?

Que sont la sévérité et la priorité ?

La sévérité décrit l’impact d’un défaut sur le système. Les catégories suivantes permettent de classer cet impact.

1. Un défaut critique empêche l’application de fonctionner correctement en raison d’une panne du système ou d’une corruption des données. L’utilisateur ne peut pas continuer.
2. Avec un défaut majeur, le système peut tomber en panne, mais l’utilisateur peut obtenir le résultat autrement sans formation supplémentaire. Ces défauts sont moins graves que les défauts critiques.
3. Avec un défaut modéré, le système continue de fonctionner, mais produit des résultats incorrects ou contradictoires.
4. Un défaut mineur n’entraîne ni panne ni problème d’utilisabilité et peut être facilement corrigé.
5. Un défaut cosmétique affecte l’apparence du système.

Un rapport de défaut indique sa priorité et sa sévérité. La priorité indique aux développeurs dans quel ordre corriger les défauts.

1. Un défaut de priorité faible se corrige après ceux de priorité supérieure. Il ne nécessite pas d’intervention immédiate.
2. Un défaut de priorité moyenne se corrige rapidement après ceux de priorité supérieure.
3. Un défaut de priorité élevée doit être pris en charge immédiatement et corrigé dès que possible.

Tenez compte à la fois de la sévérité et de la priorité indiquées pour décider du degré d’urgence.

Ouvrir le schéma en taille réelle ↗

Que sont la sévérité et la priorité ?

1. Un défaut de priorité élevée et de sévérité élevée touche une fonction de base et empêche l’utilisateur de se servir du système. Corrigez-le immédiatement.
2. Avec une priorité élevée et une sévérité faible, une faute dans le nom de l’entreprise ou un problème de logo a peu d’effet sur le fonctionnement, mais doit être corrigé immédiatement.
3. Avec une sévérité élevée et une priorité faible, un défaut majeur touche un module dont l’utilisateur n’a pas besoin tout de suite. La correction peut donc attendre.
4. Les défauts de priorité et de sévérité faibles, comme des problèmes d’apparence sans effet sur le fonctionnement, sont généralement corrigés en dernier.