Ces principes sont à toujours garder à l’esprit.
Ils sont vrais quelques soit le contexte des projets ou le niveau d’expertise des professionnels.
Le testeurs doit les assimiler car il est souvent amené à les expliquer à ces principaux interlocuteurs dans les projets informatiques.
Principe 1 : Les tests montrent la présence des défauts
Les tests ne sont pas une assurance d’absence de défauts
Quelques soit l’importance du nombre de défauts qu’on a trouvé sur l’application, et le temps qu’on a passé dans les tests sans en trouver de nouveaux, ce n’est pas une preuve d’absence de défauts. Cela ne prouve que le risque de défaillance a diminué. Sans jamais pour autant prétendre que le risque est nulle ou que le logiciel contient 0% de défauts. Ce qui est impossible à affirmer.
Principe 2 : Les tests exhaustifs n’existent pas.
Si un client demande aux testeurs de tester toute l’application, c’est qu’il n’a pas compris ce que sont les tests.
Il est impossible de tout tester.
Imaginons qu’on veuille tester une page d’inscription qui contient un formulaire de plus de 10 champs on peut facilement aller vers des milliards de tests, ce que aucun projet ne peut se permettre à cause du temps et des coûts d’une telle entreprise, et cela reste impossible qu’on opte pour pour des tests manuels ou automatiques.
C’est la raison pour laquelle il faut sélectionner les tests importants qui ont un impact sur la qualité de l’application et les séparer des tests qui ont peu de valeur ajoutée.
Principe 3 : Tester tôt
Ce principe encourage à tester le plus tôt possible dans le cycle projet. Parce que plus tôt un défaut est détecté, plus tôt il sera corrigé, moins cher sera le coût de cette correction et moins cela impactera les activités suivantes du cycle de vie du projet. Ce principe est important et serait revu dans d’autres articles.
Principe 4 : Regroupement des défauts
Il existe une loi universelle qu’on appelle la loi Pareto qui dit que 80% des problèmes sont issues de 20% des causes.
Cette loi est aussi vrai 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.
Pour tester efficacement un logiciel il faut toujours commencer par trouver et cibler les modules les plus critiques de ce logiciel.
Principe 5 : Le paradoxe du pesticide
Ce paradoxe nous explique que parfois utiliser un pesticide pour éliminer un bug (insecte en anglais) peut avoir l’effet contraire et faire proliférer ces bugs.
La même chose risque de se produire dans le domaine des tests logiciels quand on lance les même tests sur les mêmes modules en utilisant les mêmes techniques, on trouvera de moins en moins de défauts avec le temps.
Pour tester efficacement dans le temps, il faut varier les angles d’attaques en mettant à jour les tests existants et en ajoutant des tests nouveaux.
Principe 6 : Tester selon le contexte
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.
Des gens ne seraient pas d’accord, et diront que l’annulation d’un voyage de rêve peut être aussi grave mais bon.. je pense que la majorité des gens conviendraient que les équipements des hôpitaux sont plus critiques.
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, outils de tests, profondeurs de test, couverture des tests manuels ou des tests automatisés, types de tests, techniques de test, niveau de traçabilité…etc
Principe 7 : L’illusion d’absence d’erreur
Est-ce que la création d’un logiciel qui fonctionne bien – dans le sens ou le logiciel est conforme aux spécifications fonctionnels et que tous les bugs trouvés ont été corrigés – est ce que ce logiciel va satisfaire les clients ?
Ce n’est pas sûr. Un logiciel peut fonctionner correctement sans incident mais être inutilisable dans la réalité et ne pas satisfaire les attentes des utilisateurs finaux,
Par exemple :
- Un logiciel de gestion des dossiers de demandes d’aide qui est parfaitement conforme aux spécifications fonctionnelles mais ces spécifications telles qu’imaginés théoriquement s’avèrent finalement dans la pratique inutilisables en cas de saisie de grande quantités de dossiers. Une ergonomie compliquée et non intuitive nuit gravement à la facilité d’utilisation d’un logiciel ainsi qu’à la productivité du personnel qui va l’utiliser.
- Un logiciel qui fonctionne bien sur un navigateur mais pas sur le navigateur préféré des utilisateurs, cela est vrai aussi sur les variétés des systèmes d’exploitation et les appareils (Ordinateurs, tablettes, téléphones..)
- Un logiciel avec une charte graphique qui ne correspond aux attentes des utilisateurs
- .. etc
Les tests d’acceptation permettent d’éviter plusieurs désagrément de ce genre puisque contrairement aux tests systèmes qui vérifient la conformité du produit logiciel par rapport aux spécifications fonctionnelles (qui elle même peut être une conception théorique erronée), les tests d’acceptation quant à elles valident le produit logiciel par rapport aux besoins métier réels.
