Les 7 principes fondamentaux du test logiciel à connaître !
- 27 septembre 2024
- Envoyé par : LeanaE
- Catégories: Général, Technologie
L’ISTQB (le Comité international de qualification du test logiciel) a défini 7 principes fondamentaux pour le test logiciel.
Ces lignes directrices sont au cœur du métier de testeur et doivent être appliquées dans l’ensemble des projets.
Dans cet article, nous allons présenter et analyser ces 7 principes en détail.
Principe 1 – Les tests montrent la présence de défauts
Selon l’ISTQB :
Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n’est découvert, ce n’est pas une preuve d’exactitude.
Notre avis :
Les tests permettent de prouver la présence d’erreurs, mais ne peuvent certifier qu’il n’y a aucun bug présent ailleurs dans l’application.
Parfois, des milliers de cas de tests devraient être réalisés pour couvrir tous les chemins possibles de l’application. Une technique de tests par paires permet de combiner des chemins pour réaliser une série de tests plus efficaces. En effet, des tests bien ciblés trouvent des défauts, mais ne peuvent nullement certifier qu’il n’y a aucun bug présent quelque part dans l’application.
Il est donc inévitable qu’une application récemment développée puisse encore contenir des erreurs malgré les tests. En tant que testeurs, notre rôle est de mener une investigation approfondie afin d’identifier le maximum d’anomalies possibles.
Principe 2 – Les tests exhaustifs sont impossibles
Selon l’ISTQB :
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.
Notre avis :
Comme évoqué dans le principe 1, parmi les applications que l’on développe, des dizaines de milliers de chemins sont possibles selon les choix de l’utilisateur ; les tester manuellement est humainement impossible, mais surtout non nécessaire.
En effet, généralement, des contraintes de temps, de budget et de ressources ne permettent pas une vérification exhaustive.
Il est donc judicieux d’élaborer une stratégie de test qui permette de prioriser et de concentrer les efforts de test sur les sections de l’application les plus complexes, celles qui sont susceptibles de renfermer le plus d’erreurs critiques.
Principe 3 – Tester tôt
Selon l’ISTQB :
Pour trouver des défauts tôt, les activités de tests devraient commencer aussi tôt que possible dans le cycle de développement du logiciel ou du système, et devraient être focalisées vers des objectifs définis.
Notre avis :
Tester tôt permet de donner des retours rapidement et de cerner la cause du problème au plus vite.
En revanche, réaliser des tests en fin de cycle peut entraîner des pertes de temps, car il devient plus difficile de déterminer la cause, et plusieurs éléments de l’application peuvent être affectés par des modifications qui contiennent elles aussi des défauts potentiels.
Un problème identifié rapidement entraîne donc un coût de résolution beaucoup plus faible que s’il est détecté ultérieurement.
Par conséquent, il est essentiel de commencer les activités de test dès que possible dans le cycle de développement de l’application.
Principe 4 – Regroupement des défauts
Selon l’ISTQB :
L’effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules. Un petit nombre de modules contiennent généralement la majorité des défauts détectés lors des tests pré-livraison, ou affichent le plus de défaillances en opération.
Notre avis :
Ce principe rejoint 2 principes :
- le principe de Pareto, qui énonce qu’environ 80 % des résultats proviennent de seulement 20 % des causes.
- le principe de l’ISTQB les tests exhaustifs sont impossibles
La cause d’un bug peut avoir de multiples répercussions sur plusieurs endroits où ce code est appelé, généralement dans une partie précise de l’application, notamment celles qui contiennent beaucoup de code ou celles qui ont été changés peu de temps auparavant.
Ainsi, pendant une phase de non-régression, il est indispensable de tester ces endroits en profondeur.
Principe 5 – Paradoxe du pesticide
Selon l’ISTQB :
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 trouvera 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.
Notre avis :
Le paradoxe des pesticides fait référence au phénomène selon lequel, au fil du temps, le même ensemble de cas de test devient moins efficace pour identifier de nouveaux défauts dans le logiciel. Cela se produit parce que le logiciel testé devient « immunisé » contre ces tests, tout comme les insectes développent une résistance aux pesticides lorsqu’ils y sont exposés à plusieurs reprises.
Tester toujours la même chose ne permet donc pas de trouver de nouveaux défauts dans le logiciel. Et l’absence d’anomalie lors des tests peut seulement indiquer que ces derniers se concentrent sur un seul type d’anomalies et ignorent les autres.
Il est donc crucial de diversifier les scénarios de test (données entrées, choix de données…).
Le code nouvellement ajouté doit aussi être testé, d’où l’importance de mettre à jour ses cas de tests.
Principe 6 – Les tests dépendent du contexte
Selon l’ISTQB :
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.
Notre avis :
La stratégie de tests doit être adaptée au contexte et logiciel testé.
Il n’est donc pas possible de définir une seule procédure de test qui convienne à tous les logiciels.
La stratégie dépend également du type de projet, de ses contraintes de temps, de budget, de la criticité du logiciel… Par exemple, un logiciel aéronautique fera l’objet de plus de tests approfondis comparé à un logiciel de gestion de planning.
Les testeurs doivent s’adapter au contexte pour fournir une stratégie efficace.
Principe 7 – Illusion de l’absence d’erreur
Selon l’ISTQB :
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.
Notre avis :
Même en mettant en place une stratégie de test rigoureuse, il n’est pas possible d’assurer qu’un logiciel est sans défaut.
Le risque 0 n’existe pas ; une stratégie efficace permet de s’en approcher au mieux, mais des mauvaises surprises seront toujours possibles. Des tests fonctionnels et non fonctionnels pertinents sont indispensables.
Rédacteur :
