Source image : Technologie photo créée par pressfoto – fr.freepik.com
Rappelons les 7 principes du test mentionnés par l’ISTQB. Lorsqu’on les lit, cela semble évident et de bon sens, mais apportons aussi un peu d’explication.
Besoin d'un accompagnement dans vos développements?
Principe n°1 : Les tests montrent la présence de défauts
Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence. Ils réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun problème n’est découvert, ce n’est pas une preuve d’exactitude.
La réalisation des tests permet de diminuer le risque de bugs et améliore ainsi la qualité du logiciel livré.
Principe n°2 : Les tests exhaustifs sont impossibles
Il est impossible de TOUT tester. En effet, il est difficile d’imaginer tous les scénarii possibles et de les tester. De plus cela prendrait trop de temps et coûterait trop cher.
Tout tester (toutes les combinaisons d’entrées et de préconditions) n’est pas faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons l’analyse des risques et des priorités pour focaliser les efforts de tests.
Principe n°3 : Tester tôt
Ce principe encourage à tester le plus tôt possible dans le cycle du projet, parce que plus tôt un défaut est détecté, plus tôt il sera corrigé et donc moins il aura d’impact sur la suite du projet.
Corriger une erreur de spécifications coûte moins cher que de la corriger après le développement des fonctionnalités. En effet là où, par exemple l’ajout d’une phrase suffit à la rectification de spécifications, pour une correction après le développement, il faut investiguer, corriger puis vérifier les éventuels impacts du correctif sur l’application avec des tests de non-régression.
Une anomalie majeure trouvée en production peut tuer une application.
Principe n°4 : Regroupement des défauts
Il existe une loi universelle qu’on appelle la loi Pareto qui dit qu’environ 80 % des effets sont le produit de 20 % des causes.
Cette loi est aussi vraie dans les tests logiciels où 80% des défauts de qualité proviennent des 20% des modules les plus complexes, les plus instables ou les plus utilisés. La majorité des anomalies vient d’un petit nombre de modules.
L’effort de test devrait être fixé proportionnellement à la densité des défauts constatés dans les différents modules. Un petit nombre de modules contient généralement la majorité des défauts détectés lors des tests de pré-livraison, ou affichent le plus de défaillance en opération.
Principe n°5 : Paradoxe du pesticide
Si les mêmes tests sont répétés de nombreuses fois, il arrivera que le même ensemble de cas de tests ne trouve plus de nouveaux défauts. Pour prévenir ce “paradoxe du pesticide”, les cas de tests doivent être régulièrement revus et révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d’autres chemins dans le logiciel ou le système de façon à permettre la découverte de nouveaux défauts.
Principe n°6 : Les tests dépendent du contexte
Les tests sont effectués différemment dans des contextes différents. Par exemple, les logiciels de sécurité critique seront testés différemment d’un site de commerce électronique.
Tester un site de réservations de voyages et vacances est différent de la démarche de test d’un équipement informatique pour les hôpitaux : un défaut sur ce dernier peut impacter des vies d’êtres humains contrairement au site de voyage.
Les tests sur les systèmes les plus critiques doivent être les plus rigoureux. Et des choix stratégiques doivent être faits : niveaux de tests, tests manuels ou tests automatisés, types de tests, techniques de test, niveau de traçabilité etc.
Principe n°7 : Illusion d’absence de défauts
Trouver et corriger des défauts n’aide pas si le système conçu est inutilisable et ne comble pas les besoins et les attentes des utilisateurs.
Il convient donc de tester le plus tôt possible afin de réduire les risques d’erreurs liées à une mauvaise compréhension des fonctionnalités. Gardez en mémoire que l’on ne peut pas tout tester et que ce n’est pas parce qu’on n’a pas trouvé d’anomalies qu’il n’y aura pas de bugs rencontrés par les utilisateurs finaux.
Vous recherchez des informations complémentaires ? Nos équipes restent à votre écoute, n’hésitez pas à nous contacter dès aujourd’hui.
Article proposé par
Jérôme Migeon
Ingénieur Qualité