Introduction aux tests logiciels – Les 7 principes généraux des tests

Fonctionnel & Recette


(Extrait du ISTQB Syllabus Niveau Fondation 2011)

Un nombre de principes de test ont été suggérés au cours des 40 dernières années et offrent des indications communes à tous les tests.

Les 7 principes de tests :

  • Les tests montrent la présence de défauts
  • Les tests exhaustifs sont impossibles
  • Tester tôt
  • Regroupement des défauts
  • Paradoxe du pesticide
  • Les tests dépendent du contexte
  • L’illusion de l’absence d’erreurs.

Principe 1 : Les tests montrent la présence de défauts.

D’après le Syllabus : «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.»

Autrement dit, les tests permettent d’améliorer la qualité du logiciel mais cela ne garantit en aucun cas que le logiciel n’ait pas de défauts.

Principe 2 : Les tests exhaustifs sont impossibles.

«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. »

Comme il est impossible d’exécuter tous les tests, il faut définir une méthode qui permet de prioriser les tests en fonction de leur importance. Cela passe par une analyse des risques et des priorités.

Principe 3 : Tester tôt.

« 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. »

Plus un test est effectué tôt, plus vite il peut être corrigé.

Autrement dit, plus un test est effectué tôt, moins il coûte cher à corriger.

Réaliser une revue sur un cahier des charges ou sur des spécifications fonctionnelles par exemple permet de réduire le coût de détection et permet d’éviter l’apparition d’anomalies.

La plupart des défauts sont introduits tôt dans le cycle de développement :

graphique défauts

Source Martin & Leffinel

 

Coût relatif d’une correction :

tableau prix

 

Principe 4 : Regroupement des défauts.

« 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. »

Loi de Pareto : 80% des défauts sont confinés dans 20% du logiciel. Les 20% restants se situent dans les 80% du logiciel restant.

Principe 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 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. »

Ne pas toujours réaliser les mêmes tests sinon cela implique qu’il arrivera un moment où l’impression sera que le logiciel à 0 défauts. Or, comme vu dans le principe 1, les tests montrent la présence de défauts mais ne peuvent garantir l’absence de défauts.

Les objectifs de tests changent selon l’avancement du projet. Les premiers tests vont avoir pour objectif de découvrir un maximum d’anomalies dans le code de l’application.

Puis les tests vont se focaliser sur la conformité aux exigences.

Principe 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. »

Principe 7 : L’illusion de l’absence d’erreurs.

« 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. »

Autrement dit :

Éviter le « coup de la balançoire »

  • Ce que veut le client,
  • Ce qu’il a exprimé,
  • Ce qu’à compris l’équipe d’avant-vente et le chef de projet,
  • Ce qui fut traduit dans les spécifications,
  • Ce qui a été développé,
  • Ce qui a été testé,
  • Ce qui a été documenté,
  • Ce qui fut livré,
  • Ce qu’a réellement souhaité le client.

principe des tests

(Visited 1 632 times, 2 visits today)
Suivez nous sur Twitter
Envoyez nous un mail

Comments

comments

Tags: