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.

Tester permet de détecter des défauts et c’est la tâche du testeur,

Déboguer (De-buguer) permet comme son nom l’indique de défaire des bugs, càd de corriger des défauts.

Le débogage est une tâche réalisée par le développeur.

Quand un testeur trouve un incident, il le communique au développeur qui réalise un debugging pour mettre le doigt sur le défaut dans le code qui a causé la défaillance afin de le corriger.

L’histoire ne s’arrête pas là.

Le testeur doit reprendre la main après la correction, en réalisant le test à nouveau sur son environnement de test pour confirmer que le défaut a bien été corrigé, et non seulement sur le poste du développeur. Ces re-test sont appelés : les tests de confirmation.

La différence entre « tests dynamiques » et « tests statiques » est que :

• Les tests dynamiques sont réalisés sur un logiciel en cours d’exécution
• alors que les tests statiques sont effectués sur du code source non exécuté et sur de la documentation.

Qu’ils soient statiques ou dynamiques les tests fournissent des informations sur le produit logiciel. Des informations qui pourrait servir pour améliorer la qualité du produit ou améliorer l’efficacité du processus de sa fabrication.

On avait dit précédemment que ce ne sont pas les tests qui améliorent directement la qualité du logiciel mais bien les activités de développement qui le corrigent.

Faire des tests c’est comme faire un diagnostic médical, le diagnostic donne des informations sur l’état de santé d’une personne.

Pour cela, il est possible d’utiliser des approches statiques comme des radios et des scanners

ou des approches dynamiques en mesurant les capacités physiques du patient en analysant ses performances en mouvement c’est à dire en lui faisant faire des exercices spécifiques et vérifier qu’il y arrive bien ou pas.

Les tests ne corrigent pas les défauts, mais permettent de les détecter méthodiquement pour que les développeurs puissent les appréhender et les corriger.

C’est par ce processus indirect que les tests participent à l’amélioration de la qualité des logiciels.

Les tests ne servent pas seulement à prévenir les comportements non désirés des applications, mais aussi à veiller à leurs conformités vis-à-vis de certaines exigences légales ou contractuelles ou le respects des normes correspondants à certaines industries spécifiques.

Les tests permettent de mesurer la qualité d’un logiciel, et ne permettent pas de directement l’améliorer. Ce sont les développeurs qui corrigent les anomalies et impactent ainsi directement la qualité du logiciel.

Les tests peuvent augmenter le niveau de confiance dans un logiciel si peu ou pas de défauts sont trouvés.

L’assurance qualité est tout le processus dont font partie les tests pour générer la qualité d’une application.

Cela va des activités de revue de la documentation jusqu’aux formations, en passant pas les standards de développement et les tests.

Combien de test est suffisant ?

Il n’y a pas de réponde toute faite à cette question.

C’est aux décideurs de trancher sur la base de paramètres tels que :

• Le niveau de risque, c’est-à-dire la possibilité qu’un problème se produise.
• Ou le respect des contraintes du projet.

Le risque est une notion qui va être abordée en détail dans d’autres articles de testacademy.fr

Ce qu’il faut savoir à ce stade est que le risque qualité est la possibilité qu’un problème logiciel se produise.

Avant les tests, le risque est à son maximum.

Au fur et à mesure que les tests progressent, le risque sur la qualité du logiciel diminue avec le temps.

Dans la réalité des projets logiciels, on dispose rarement de temps et de budget suffisants.

C’est la raison pour laquelle il faut faire des arbitrages pour décider du moment ou arrêter les tests.

Les tests permettent de prendre cette décision en toute connaissance de cause, en sachant le niveau de qualité sur la partie couverte par les tests de l’application et le niveau du risque résiduel (c’est à dire restant) dans la partie non couverte par les tests.

Des critères de sortie basés sur la qualité et le risque peuvent être définis avant même de commencer l’exécution.

Les décideurs comme le chef de projet, le directeur de projet, le client, les sponsors… attendent avec un grand intérêts les résultats des tests pour décider des actions futures à faire.

Les décisions qui peuvent être prises à la lumière des informations résultant des tests peuvent être par exemple :

• Donner le feu vert pour mettre en production une application ( Décision GO MEP) : càd rendre accessible l’application à l’utilisateur final.
• Lancer une nouvelle campagne de correction pour améliorer la qualité : la qualité actuelle étant non encore suffisante pour la mise en production.
• Continuer les tests (pour gagner en visibilité)
• Arrêter les tests pour cause d’une qualité médiocre (moyens insuffisants ou démarche défaillante).

Qui d’entre nous n’a pas eu l’expérience d’un logiciel qui ne fonctionne pas comme prévu :

• Une application sur un smartphone
• Un achat sur une boutique en ligne
• Un écran bleu sur votre ordinateur
• …etc

Les comportements inattendus des logiciels peuvent avoir des conséquences allant de pertes financières ou d’image (comme un bug sur un module de paiement d’un site e-commerce), jusqu’à des pertes humaines (comme les équipements de santé et des moyens de transports).

Plusieurs termes sont utilisés pour désigner un comportement inattendu d’une application : Bug, Erreur, Défaut, anomalies, défaillance…

Parfois ces termes sont utilisés de façon totalement confuse.

L’ISTQB Fondation commence par le vocabulaire pour démarrer sur de bonnes bases.

Les erreurs :

Une erreur est commise par une « Personne » : un être humain

Faire des erreurs est une des caractéristiques de l’homme qui est un être faillible.

Les hommes sont ingénieux, ils sont capables de fabriquer des choses fabuleuses mais ils font aussi des erreurs, des méprises et cela ne réduit en rien leur ingéniosité.

Les méprises sont un synonyme acceptable aux erreurs dans l’ISTQB Fondation.

Les défauts :

Un défaut est lié à un produit comme le code d’une application ou le contenu d’un document.

Une erreur humaine produit un défaut sur un produit logiciel ou un document (produit textuel).

Un développeur peut introduire un défaut dans un produit logiciel, un concepteur peut introduire un défaut dans un document de spécifications.

Le terme défaut a des synonymes tels que : Bug et Anomalie.

Les défaillances :

Quand un défaut qui réside dans le code d’un logiciel est exécuté cela peut générer une défaillance.

Une défaillance est liée à un produit en cours d’exécution :

S’il n’y a pas d’exécution, il n’y a pas de défaillance.

Une défaillance peut être un affichage incorrect sur l’écran jusqu’à un crash total d’une application.

La relation de causalité entre défaut et défaillance n’est pas automatique :

Un défaut peut générer une défaillance ou pas : un défaut dans un code qui n’est jamais parcouru lors de l’exécution ne génère pas de défaillance.

Toutes les défaillances ne sont pas forcément dues à un défaut : parfois des systèmes informatiques sont des comportements inattendus parce qu’ils sont confrontés à un environnement particulier (des pics de températures, des radiations, magnétismes, champs électriques ou la Pollution).

Ce qu’il faut retenir absolument est que :

Une erreur humaine peut générer un défaut dans un produit statique (qui n’est pas en exécution) comme le code d’une application ou une documentation.

Un défaut peut générer une défaillance quand l’application est exécutée.

Les tests permettent de détecter des défauts dans le logiciel avant de l’utiliser dans un environnement opérationnel en production.

Cela permet d’éviter que ces défauts génèrent des défaillances dans l’environnement de production.