Nous pouvons voir les tests comme un Iceberg dont la petite partie visible à la surface de l’eau est l’activité d’exécution.

La partie immergée de l’Iceberg – qui est plus grande – représente les autres activités importantes de test qui sont moins connues mais elles ont un impact direct sur le succès de l’exécution des tests.

Le test et comme le développement, La partie la plus connue du développement logiciel est l’écriture du code,

Mais on ne peut pas sauter directement au codage sans passer par des étapes importantes qui ont lieu avant comme:

La planification du projet, l’expression de besoin, la conception de la solution,

Et aussi après le codage d’autres activités sont à réaliser comme : l’exécution des tests et le déploiement.

Je dis bien l’exécution des tests et pas les tests avec un grand T.

Ce qui fait un processus développement se composant de la suite d’activités suivante :

1. La planification du projet,
2. l’expression des besoins métier,
3. la conception de la solution
4. Le codage de la solution
5. l’exécution des tests
6. et le déploiement.

Le test aussi a son propre processus qui se déroule en parallèle avec le processus de développement.

Le processus de test se déroule en parallèle du processus de développement

Le processus de test est constitué des activités suivantes :

1. Planification des tests
2. Suivi et contrôle des tests
3. Analyse de test
4. Conception des tests
5. Implémentation des tests
6. Exécution des tests
7. Et la Clôture des tests

Les activités de test et les activités de développement se donnent alors rendez vous à l’étape d’exécution des tests pour faire état de l’avancement des travaux du projet.

Les deux processus se croisent alors lors de l’exécution des tests quand :

• les cas de tests sont conçus et prêts pour être exécutés
• et le produit fabriqué et livré et disponible pour être manipulé par l’équipe de test.

Nous allons ici parcourir une par une les activités du processus de test pour découvrir ce que signifie chacune d’elles.

Planification des tests

Le processus de test débute par la planification.

Le responsable des tests commence par déterminer l’objectif des tests qu’il va piloter,

Les objectifs peuvent être de :

• Trouver des défauts
• Acquérir de la confiance dans le produit,
• Acquérir des informations pour prendre une décision
• Ou prévenir des défauts

Quand l’objectif de test est précisé,

une stratégie doit être définie pour atteindre cet objectif

et un planning doit organiser et distribuer l’effort de test dans le temps

Quand cela est fait alors, le responsable des tests a un Plan préparé que son équipe pourra suivre pour réaliser les tests.

Généralement ce plan prend forme d’un document Word appelé Plan de test Maître qui définit par exemple :

• Le périmètre de test
• Les approches de test à adopter selon les niveaux de criticité des exigences
• Les niveaux de test
• Les critères d’entrée et les critères de sortie de chaque niveau de test
• les types de test
• Le planning des tests
• L’organisation du projet avec les rôles, les responsabilités, les réunions, leurs buts et leurs fréquences
• Les environnements de test
• Et les outils de test

On peut faire une séparation entre les activités de test selon qui les réalisent généralement.

L’activité  « planification des tests » et l’activité « Suivi et contrôle des tests »  sont des tâche de gestion de projet, elles sont donc généralement réalisés par un Test Manager.

Alors que les activités :

Analyse de test, Conception de test et Exécution sont des activités réalisés par un profil Analyste de test.

Mais il est bien utile qu’un Analyste de test apprennent comment planifier et suivre un projet puisqu’il n’est pas rare qu’on lui demande d’estimer la durée de ces tests ou ajuster la démarche aux contraintes de son projet.

Suivi et contrôle des tests

L’activité de suivi et contrôle est la tâche qui consiste à s’assurer que le projet progresse bien selon le plan établi.

Grâce à l’activité de suivi et contrôle, le responsable des tests suit la progression des travaux et essaye de détecter tout écart entre le Plan de l’avancement prévu et le déroulement réel du projet.

Si il y a un écart alors le responsable agit en conséquence pour ajuster la trajectoire tout au long de l’avancement du projet.

La planification est réalisée au début du processus.

Le suivi et contrôle se déroule tout au long du processus de test et peut remettre en cause la planification initiale quand c’est nécessaire.

Grâce à l’activité de suivi et de contrôle, le Plan de test et revu en permanence et devient un document vivant adapté à la réalité du projet tout au long du processus.

Analyse des tests

Le testeur ne peux pas dès le début du projets commencer à créer des cas de test.

Le testeur n’invente pas les cas de test.

Les cas de test sont issues de la base de test c’est-à-dire toute la documentation mise à disposition du testeur pour créer ces tests :

Comme :

• Les spécifications fonctionnelles,
• les spécifications techniques
• et le code source lui-même.

Mais si vous êtes un testeur fonctionnel, alors ce qui vous intéresserait le plus c’est les spécifications fonctionnelles.

L’analyse des spécifications techniques et la revue de code sont souvent réalisés par les développeurs eux même, quand chacun relie les spécifications technique et le code de son collègue.

Mais en tant que testeur fonctionnel, vos tests devraient être une comparaison entre :

• D’un côté un comportement attendu de l’application décrit dans les spécifications
• Et de l’autre côté le comportement réel observé lors de la manipulation de l’application

Un test = une comparaison entre UN COMPORTEMENT ATTENDU (la référence) et UN COMPORTEMENT OBSERVE

La référence sur laquelle se basent les tests est donc le document des spécifications.

La référence des tests = Les spécifications

Pour que le testeur sache qu’est ce qu’il va écrire comme cas de test, il doit donc lire les spécifications et en extraire ce qu’il faut tester.

Cela rend les tests très dépendants des spécifications.

Si la qualité des spécifications est mauvaise, la qualité des tests qui vont être réalisés seront mauvais aussi.

D’où la nécessité de vérifier la qualité des spécifications en premier lieu avant même de la prendre comme référence pour créer les cas de test.

L’analyse de test est par conséquent l’activité qui permet au testeur de :

1. Lire et comprendre les spécifications
2. Vérifier la qualité des spécifications en détectant les défauts qu’elle contient.
3. Identifier le périmètre de test c’est-à-dire : la liste des éléments à tester ou la liste des conditions de test.

Durant cette phase, les testeurs préparent les tests qu’ils vont exécuter plus tard. Cela permet de construire un patrimoine de test structuré et s’assurer qu’aucun test n’est oublié ou qu’un élément du logiciel est testé deux fois sans raison.

Cette phase du processus démarre de l’objectif définie dans la planification, et s’appuie sur le comportement attendu de l’application décrit dans les spécifications et les autres documents pour sélectionner les conditions de test.

Par exemple :

• Pour application calculatrice.
• L’objectif de test choisi peut être de détecter des défauts.
• Les conditions de test sont : Faire une addition, Faire une soustraction, Faire une multiplication et faire une division
• Les tests pour la condition de test « Faire une addition » peuvent être :
  • Faire la somme de deux entiers positifs
  • Faire une addition entre un entier positif et un entier négatif
  • Faire la somme de deux entiers négatifs
  • Faire la somme de plus de 5 valeurs
  • … etc.

La revue des spécifications

L’analyse des spécification est une occasion pour réaliser une revue des spécifications qui est une activité de test statique qui nous permet de commencer à détecter des défauts à partir des spécifications avant même de recevoir la livraison logicielle et sans avoir à exécuter du code.

Les défauts qu’on détecte à ce stade précoce du projet sont appelés des défauts de spécifications.

Conception des tests

Input : Conditions de test

Output : Cas de test de haut niveau + défauts

Analyse de test = « Quoi tester »

Conception de test = « Comment tester »

Suite à l’analyse de test, le testeur a identifié le périmètre de test, le « quoi tester » ou ce qu’il y a à tester sous forme d’une liste de conditions de test.

Sur cette base, le testeur applique des techniques de conception déterminer comment tester ce périmètre de test et ainsi produire des cas de test haut niveau.

Cas de test de haut niveau = Cas de test – Procédure de test

Les cas de test de haut niveau sont des cas de test qui n’ont pas encore de procédures de test,

Les procédures de test sont une suites d’étapes avec des actions précises et des résultats attendus.

Procédure de test = Liste d’étapes de test

Les tests peuvent être conçus en identifiant les données de tests dont on aura besoin pour les exécuter mais sans préparer ces données de test:

Dans l’exemple d’une calculatrice nous avons identifié le test « Faire une addition entre deux entier positifs »

Nous avons identifié le besoin en données de test : 2 entiers positifs

Mais à ce stade, ces entiers positifs ne sont pas précisés, ça peut être n’importe quels entiers positifs. Ils seront précisés lors de la phase d’implémentation.

Un cas de test est un cas de test même sans avoir une liste d’étapes ni des données de tests préparés à l’avance.

Pendant la conception, le testeur doit structurer ses tests grâce au concept de la traçabilité bidirectionnelle, c’est-à-dire que chaque exigence est liée aux cas de tests qui la vérifient, et que chaque cas de test est lié aux exigences qu’il couvre. Cela permet de vérifier que pendant la phase de conception qu’on a bien conçus des tests pour toutes les exigences. On dit alors que nous avons une bonne couverture de test.

Cette traçabilité bidirectionnelle de l’exigence vers les cas de test et depuis les cas de test vers les exigence permet aussi pendant la phase d’exécution de déterminer à un instant donné quel est le niveau de conformité du logiciel à chacune des exigences.

Pendant la conception, le testeur acquiert une meilleure maîtrise de la base de test et peut donc apercevoir des défauts qu’il n’avait pas pu voir lors de la phase d’analyse.

Implémentation des tests

• Input : Cas de test haut sans procédures de test
• Output : Cas de test avec procédures de test/Scripts de test + Données de test + Environnement de test + Calendrier d’exécution

La phase d’implémentation est la phase tampon entre la conception et l’exécution.

Elle vient compléter ce qui n’a pas encore été fait lors de la phase de conception.

Et préparer le terrain pour la phase d’exécution.

Elle permet de détailler encore plus les cas de test conçus qui étaient jusque là de haut niveau.

En y ajoutant :

• des procédure des tests si les cas de test sont à exécuter manuellement
• des scripts de tests qui correspondent à du code pour des tests automatisés.
• Des données de test, pour que celui qui va exécuter les tests ne perde pas de temps à chercher des données ou parfois à en fabriquer.
• Des environnements de test avec tous les prérequis materiels et logciels pour exécuter les tests
• …

Développer les procédures de test veut dire que les cas de tests qui ont été conçus dans la phase précédente doivent être détaillés et spécifiés dans cette phase en étapes spécifiques et claires que les testeurs exécuteront facilement.

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, ces cas de tests seront implémentés en procédures de test en y ajoutant des étapes de test.

Par exemple le test : Faire une addition entre 2 entiers positifs

Sera détaillé en des étapes claires comme :

Le tableau à afficher dans la vidéo

Les suites de test

Pour préparer la phase d’exécution, il faut organiser les tests dans l’ordre d’exécution souhaité.

Les cas de tests ne peuvent pas être exécutés dans n’importe quel ordre car il y a souvent des préconditions, des dépendances et des logiques entre les cas de test, qui impacte l’ordre d’exécution.

Il faut que le concepteur organise ses tests de manière à en faciliter l’exécution et prendre en compte toutes les contraintes et dépendances entres ces cas de test.

Pour cela les suites de test sont un outil bien utile.

Les suites de test permettent de rassembler plusieurs tests et de les exécuter dans un ordre qui a un sens fonctionnel.

Cela permet de rendre les tests plus efficaces et en rendant par exemple possible que chaque test prépare les prérequis nécessaires pour exécuter le test suivant.

Le testeur peut grâce aux suites de test préparer un calendrier où les tests sont sélectionnés et ordonnés selon la logique d’exécution souhaitée.

Pour faire des tests on peut avoir besoin d’un environnement spécifique, un système d’exploitation, des bouchons de simulation, des applications tierces pour communiquer avec notre produit logiciel ou des outils de comparaison pour vérifier les résultats de nos tests. Tout ces éléments peuvent être prévus dès cette phase pour commencer à les préparer avant la phase d’exécution.

Exécution des tests

C’est pendant cette phase d’exécution que les cas de test sont déroulés en manipulant le logiciel sous test

Les tests sont alors exécutés en suivant l’ordre prévu soit en utilisant des logiciels bureautique ou en utilisant un outil dédié à la gestion des tests comme HP ALM, SQUASH, TESTLINK, XSTUDIO et autres…

Quand les tests sont exécutés il faut enregistrer les résultats et vérifier s’il y a un écart entre le résultat attendu et le résultat réel constaté lors du test.

Si le testeur constate bien un écart alors il doit créer un rapport de défaut qui est une fiche pour décrire au développeur le défaut trouvé en veillant à détailler les conditions dans lesquelles les tests ont été déroulés pour que le développeur puisse avoir une vision la plus complète possible de l’origine des défauts et lui permettre de le reproduire dans son environnement et le corriger plus facilement.

Il ne faut pas oublier de réaliser 2 types de test :Les tests de confirmation et les tests de régression.

Quand un défaut est détecté celui-ci est signalée par le testeur au développeur à l’aide d’un rapport de défaut. Le développeur reçoit le rapport et corrige le défaut. Une fois corrigée le testeur refait un test pour vérifier et confirmer que la correction a été bonne. C’est le test de confirmation.

Et ce n’est pas fini,

Pour corriger l’anomalie, le développeur a du modifier le code de l’application, ce qui peut impacter des endroits de l’application qui fonctionnait bien avant, et qui ne fonctionne plus maintenant à cause de la modification.

C’est ce que l’on appelle des régressions.

Les testeurs sont alors amenés à refaire des tests sur des fonctionnalités déjà vérifiés : c’est ce que l’on appelle des tests de régression.

Clôture des tests

Cette activité est une phase de prise de recul ou on rassemble tous ce qui a été produit lors de la campagne qui vient de se terminer pour le réutiliser dans les prochaines campagnes et revenir sur l’expérience acquise pour mieux faire la prochaine fois.

L’équipe vérifie que tout ce qui devait être livré par l’équipe de test a bien été livré.

Les rapports de défaut qui ont été rapportés et corrigés doivent être archivés.

Et quant aux défaut résiduels c’est-à-dire les défauts qui n’ont pas été corrigés et qui sont toujours dans le produit logiciel, on peut convertir ces rapports de défauts en demandes d’évolution pour les transformer en spécifications pour le prochain cycle de développement.

Cette phase permet de tracer les résultats des tests dans un compte rendu.

Et archiver tous les cas de test conçus, les données de test, les outils de comparaisons, les écrans.. etc pour les réutiliser à nouveau si besoin.

Si une autre équipe prend en charge les travaux sur la qualité du produit, cette phase de clôture peut servir pour que l’équipe sortante leur fournisse tout ce qui a été produit durant les tests. Et ainsi leur permettre de monter en compétence plus rapidement.

L’équipe peut se réunir pour reparler à tête reposée de ce qui s’est passé durant ce projet.

Ils essayent d’identifier ce qui s’est bien passé et ce qui marche pour pouvoir le reproduire

Et identifier ce qui ne marche pas pour ne plus le reproduire et faire mieux la prochaine fois.

Les tests fournissent des informations sur la qualité du produit testé mais pas que,

les tests peuvent aussi donner une idée sur l’efficacité du processus de développement.

Si beaucoup de défauts sont dues à des mauvaises interprétations de la base de test, c’est qu’il y a un problème dans les spécifications ou dans la communication entre les référents fonctionnels qui écrivent les spécifications et les développeurs qui fabriquent ce qui est spécifié.

Si beaucoup de défauts sont des erreurs de codage alors il faut renforcer les tests statiques comme les revues de code et augmenter le nombre des tests unitaires par exemple.

C’est ainsi qu’une équipe peut améliorer la maturité de ses pratiques grâce à la prise de recul sur l’expérience passée.

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.

Or, would you prefer a straightforward response that covers key points and makes sense of abstract concepts? Though clarity is key, Google also places a high value on being thorough. This means marketers need to be careful…