1.3 Les 7 principes généraux des tests
Ces principes sont à garder à l’esprit du professionnel du test lors de l’exercice de son activité.
Ils sont sensés être vrais quelques soit le contexte du projet ou le niveau d’expertise du professionnel.
Le professionnel du test doit suffisamment les assimiler pour les appliquer efficacement et être en capacité d’en transmettre l’essence aux clients ainsi qu’aux acteurs-clés des projets.
Principe 1 : Les tests montrent la présence des défauts
L
es 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.
S
i un client demande 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 test, ce qu’aucun projet ne peut se permettre à cause du temps et des coûts d’une telle entreprise.
Cela reste vrai qu’on opte 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é et moins il impactera les activités suivantes du cycle projet.
Ce principe est important et sera revu plus en détail dans les chapitres suivants.
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 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 les 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’attaque 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érents 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, Tests manuels ou tests automatisés, types de tests, techniques de test, niveau de traçabilité…etc
Celui qui a conçu les tests n’est pas forcément celui qui va les exécuter. Chaque test est détaillé en étapes qui décrivent clairement l’action à faire sur l’application et le résultat attendu.
Prenons encore l’exemple de la calculatrice.
Nous avions identifié les cas de tests dans la phase d’analyse et de conception.
Dans la phase d’implémentation et d’exécution, ces cas de tests seront implémentés et étapes de test.
Par exemple le test : Faire une addition entre 2 entiers positifs
Sera détaillé en des étapes claires comme :
- Action : Allumer la calculatrice => Résultat attendu : la calculatrice est allumée et affiche un 0
- Action : Renseigner la valeur 9 => Résultat attendu : La valeur 9 s’affiche sur l’écran
- Action : Appuyer sur le bouton « + » => Résultat attendu : La valeur 9 s’affiche toujours sur l’écran
- Action : Renseigner la valeur 11 => Résultat attendu : La valeur 11 s’affiche sur l’écran
- Action : Appuyer sur le bouton « = » => Résultat attendu : La valeur 20 s’affiche sur l’écran
Principe 7 : L’illusion d’absence d’erreur
Est-ce que la création d’un logiciel qui fonctionne bien dans le sens ou tous les bugs trouvés ont été corrigés – va satisfaire à coup sûr les clients ?
Ce n’est pas sûr. Un logiciel peut fonctionner correctement sans incident mais sans satisfaire les attentes de l’utilisateur, par exemple le logiciel peut ne pas être intuitif ergonomiquement et donc pas facile d’utilisation, la charte graphique n’est pas au gout des utilisateurs, ou fonctionne bien sur un navigateur X mais pas top sur un autre navigateur Y pourtant le préféré des utilisateurs.