La conception des tests est l’activité qui permet d’identifier et d’extraire à partir d’une base de test, les éléments suivants :

• Les conditions de test : c’est-à-dire les fonctions à vérifier
• Les cas de test qui décrivent comment ces fonctions seront testés
• Et les données à utiliser pour réaliser les tests

Il existe plusieurs techniques qui permettent de concevoir des tests. Dans ce syllabus de l’ISTQB, 3 techniques seront présentées :

1. Les techniques de conception de tests de type « Boite Noire »
2. Les techniques de conception de tests de type « Boite blanche »
3. Et des techniques de conception de tests basées sur l’expérience

Boite noire :

Les techniques de conception Boite Noire sont aussi appelées techniques de conception basées sur les spécifications.

Ces techniques permettent de juger le produit selon ce qu’il est sensé faire, sans s’attarder sur les détails techniques de sa fabrication.

Les tests conçus selon les techniques boites noire sont directement dérivés de la documentation qui décrit le comportement fonctionnel et non fonctionnel attendu de l’application.

• L’application doit permettre de créer des commandes en ligne
• De consulter les commandes en cours
• De modifier les commandes en cours
• De réaliser des transactions en moins de 5 secondes.
• De permettre à un nombre précis d’utilisateurs de se connecter en même temps.
• Etc..

Toutes ces exigences ne dépendent pas ni du langage de programmation, ni de la base de données utilisés.

Les tests boite noire n’utilisent aucune information concernant la structure interne du système à tester.

Boite blanche :

Les techniques boite blanche par contre sont basées sur la structure interne du système.

Pour réaliser des tests de type boite blanche, il faut connaitre les modules qui composent le logiciel et comment ils sont développés.

Ces tests sont donc réalisés par des intervenants qui ont accès à la structure logicielle de l’application.

Ces techniques boite blanches sont aussi appelées les techniques structurelles ou les techniques basées sur les structures.

Techniques basées sur l’expérience :

A côtés de des techniques boite noire et des techniques boite blanche, il existe des techniques issues de l’expérience de celui qui réalise le test pour détecter les faiblesses de l’application.

Ces techniques ne se basent ni sur la documentation ni sur la structure logicielle mais sur l’intuition de celui qui réalise les tests, qu’il soit développeur, testeur ou utilisateur.

Une technique de conception peut faire partie de plusieurs catégories.

Si on utilise la documentation de spécifications pour concevoir les cas de tests alors on utilise une technique de conception de type boite noire.

Si on utilise la structure interne d’un logiciel pour dériver les cas de tests alors on utilise une technique de conception de type boite blanche.

Caractéristiques habituelles des techniques de conception :

Boite noire :

Les spécifications peuvent être purement textuelle ou elle peuvent contenir des modèles et des diagrammes pour représenter le fonctionnement d’une application.

Le fonctionnement d’une application peut être modélisé sous forme d’un diagramme qui représente les utilisations possibles qu’on peut faire d’un système.

Ce modèle ou diagramme peut représenter des chemins fonctionnels possibles selon les actions de l’utilisateurs.

On peut directement dériver des cas de tests à partir de ces modèles.

Boite blanche :

Des cas de tests peuvent être dérivés du code source de l’application ou à partir de la conception de son architecture logicielle.

Le code source d’une application peut aussi être modélisé sous forme d’un graphe.

Ce graphe reprend toutes les instructions du code source et identifie les chemins d’exécution possibles.

Les cas de test peuvent avoir un bon niveau de couverture de l’application logicielle si les cas de tests vérifient tous les chemins possibles du graphe.

Si les cas de tests ne couvrent pas tous les chemins possibles du graphe alors des cas de test complémentaires peuvent être conçus pour améliorer la couverture du logiciel par les tests.

L’expérience :

Ce type de techniques se base sur :

le niveau d’expertise dans les tests logiciels et le domaine métier testé des personnes qui font les tests.

Ce qui est valorisé dans ce type de test est le degré d’expérience que possède celui qui va faire les tests dans ce même type de produit logiciel qui fera l’objet des tests et de son environnement technique.

Parfois les testeurs ont un tel niveau de recul sur le produit fabriqué qu’ils apportent des check-lists déjà prêtes contenants les défauts et les vulnérabilités possibles que les produits du même type (que celui à tester) ont habituellement, cela apporte un gain de temps et d’efficacité des tests appréciables.

Cet article décrit un processus de développement de test hautement formel.

Ce processus de test est généralement moins formel dans la réalité. Mais la compréhension du processus le plus formel permettra de comprendre plus facilement les processus les moins formels.

Le choix du niveau de formalisme à adopter dépendra du contexte du projet et de ses contraintes.

Plus les contraintes du projet sont fortes (contraintes de temps, exigence de sureté de fonctionnement ou exigences réglementaires réglementaire etc..), plus le processus aura besoin en théorie d’un niveau de formalisme élevé.

Plus les moyens dont dispose le projet sont grands (maturité des tests et des processus de développement, niveau d’expertise des personnes impliquées..etc) moins le processus a besoin en théorie d’un niveau de formalise élevé.

Le test est une comparaison entre le comportement réel d’une application, et le comportement attendu d’une application.

Le comportement réel de l’application est issu de la manipulation de l’application en exécution.

Le comportement attendu de l’application est issu quant à lui d’une documentation qu’on appelle Base de test.

Dans un article précédent, nous avions définit le processus fondamental de test qui se compose de 7 étapes

ANALYSE DE TEST

La deuxième étape du processus fondamental de test est l’Analyse de test.

Pendant cette étape le testeur lit la documentation de la base de test pour en extraire les conditions de test.

Les conditions de test sont tous les éléments qui ont besoin d’être vérifiés par des tests.

Les conditions de test est une liste de ce qui est à tester.

Une condition de test peut être :

• une fonction du système comme Trier, Calculer, Envoyer…
• Une transaction : comme le paiement en ligne, réserver une place, faire une demande sur un site.
• Caractéristique qualité : comme la facilité d’utilisation de l’application, la performance, la fiabilité, la robustesse

• Ou un élément structurel ; comme un menu, un logo, un titre, un bouton…

Les spécifications est la documentation qui décrit le comportement attendu de l’application à développer.

Les exigences sont une représentation atomique de ces spécifications. Au lieu d’avoir un document textuel difficile à manipuler on le structure sous forme d’une liste délimitée d’éléments (les exigences).

Les exigences permettent donc de représenter le comportement attendu de l’application sous forme d’une liste d’éléments à fabriquer.

Les conditions de test sont une liste des éléments à tester

Etablir la traçabilité entre les conditions de tests et les exigences, revient à établir des liens entre les éléments à fabriquer et les éléments à tester.

Une exigence peut nécessiter plusieurs vérifications.

Cela peut alors être représenté ainsi :

Analyse d’impact

La traçabilité entre les exigences et les conditions de test permet de réaliser des analyses d’impact.

Une analyse d’impact a pour objectif de mesurer les conséquences d’un changement dans les exigences.

En établissant la traçabilité, il est facile de trouver grâce aux liens, les éléments qui dépendent d’une exigence et qui seront touchée si cette exigence change.

Cette traçabilité permet aussi de détecter rapidement le niveau de couverture des exigences par les tests. Dans cet exemple (ci-dessus) on voit facilement que l’exigence 4 n’a été couverte par aucune condition de test.

« Pendant l‟analyse de conception des tests, les approches détaillées de tests sont implémentées pour sélectionner des techniques de tests basées sur, entre autres considérations, les risques identifiés « 

C’est une phrase longue et compliquée pour dire que :

L’analyse de risque est une technique pour sélectionner et prioriser les tests à réaliser.

CONCEPTION DES TEST

Pendant la conception des tests, les cas de tests sont créés.

Un cas de test se compose de :

• Un objectif de test : tout test d’avoir avoir un objectif défini à atteindre comme la vérification du fonctionnement d’un élément particulier.
• Une pré-condition d’exécution : qui peut être une liste de pré-requis nécéssaires à l’exécution comme une connexion établie à internet,, être positionné sur la page donnée de l’application pour commencer le test, avoir un compte utilisateur avec des habilitations données etc..
• Le cas de test contient aussi des valeurs d’entrée : comme des actions à accomplir et des données de test à utiliser.
• Des résultats attendus : comme l’affichage d’une nouvelle page ou un message d’erreur etc..
• Des post-conditions : comme être connecté à une machine, un paiement ou une transaction réussie ou en échec…etc

Le standard IEEE 829-1998 décrit les structures des conditions de test et des cas de test.

Il n’est pas nécessaire de lire ces standards mais Il faut retenir leurs noms et les sujets qu’ils traitent car ils peuvent être demandés lors de l’examen de certification ISTQB.

Les résultats attendus sont la référence du testeur qui va exécuter le test pour décider qu’un test est en Succès ou en Echec.

Si le résultat attendu n’est pas défini alors n’importe quel comportement de l’application lors de l’exécution peut être interprété comme un Succès.

Ce qui peut empêcher de détecter un défaut.

Les résultats attendus doivent être extraits de la base de test qu’ils soient des spécifications ou des exigences.

La base de test contient les éléments sur lesquelles se base le concepteur de test pour définir des résultats attendus comme les sorties et messages affichés, les modifications des données stockés la base de données ou des changements d’états à constater comme les états connecté et non connecté.

IMPLEMENTATION ET EXECUTION DES TESTS

L’implémentation des tests est l’étape où les tests sont détaillés.

Les tests ayant été créé lors de l’étape de la conception des tests, ne sont qu’une description générale de ce qui est à vérifier.

L’implémentation des tests définit une procédure de test précise pour chaque cas de test.

La procédure de test est une séquence d’actions concrètes à réaliser lors de l’exécution et des résultats attendus intermédiaires à vérifier suite à chacune de ses actions.

Ces cas de test ainsi implémentés seront priorisés selon la stratégie de test définie par le responsable de test.

Ces cas de test seront donc exécutés selon l’ordre qui a été défini dans cette étape.

Quand le test est manuel la séquence d’actions à exécuter est appelée une procédure de test.

Quand le test est automatique la séquence d’actions à exécuter est appelée Script de test.

Le standard IEEE 829-1998 traite aussi le sujet de spécification de procédure de test.

Le planning d’exécution des tests définit l’ordre d’exécution prévu des tests.

Le planning d’exécution des tests regroupe les procédures de tests manuels et les scripts de tests automatisés.

L’ordre d’exécution est défini sur la base d’une stratégie de test qui prend en compte

• La priorité des exigences à tester : les exigences les plus importantes peuvent être testés en premier
•  Les dépendances entre les tests : Les tests liés l’exigence « annuler une commande » sont à réaliser après les tests de « créer une commande ».
• Les tests de régression : on peut décider dans la stratégie de test de s’assurer que les modifications apportées au logiciel ne l’ont pas détérioré avant de vérifier les nouvelles fonctionnalités.

Comme la revue, L’analyse statique est une technique de test statique.

L’analyse statique est un moyen de trouver les défauts d’un code logiciel avant de l’exécuter.

On dit que l’analyse statique trouve des défauts plutôt que des défaillances parce que les défaillances nécessitent l’exécution du logiciel.

Comme tous les défauts ne produisent pas forcément des défaillances lors de l’exécution, l’analyse statique permet de détecter des défauts difficiles à trouver par les tests dynamiques.

L’analyse statique est généralement réalisée par de développeurs qui utilisent des outils d’analyse statique du code source.

Ces tests sont donc généralement automatisés.

Un outil d’analyse statique permet de parcourir le code source écrit avec un langage de programmation, une page HTML destinée à être lue par un navigateur ou des fichiers de données structurés grâce au langage de balisage XML.

Les outils d’analyse statique peuvent ainsi détecter dans le code source :

• Qu’une variable est mal référencée
• Que les interactions entre des modules ou des composants sont mal définis
• Que des variables sont déclarées mais jamais utilisées dans le code.
• Que des variables sont mal définies dans le code, comme une variable de type entier qu’on manipule comme un tableau.
• Qu’un code ne soit jamais accessible parce qu’il est contenu dans une fonction qui n’est jamais appelée.
• Que des erreurs logiques ont conduit à des boucles infinies, et coince l’exécution du logiciel jusqu’au plantage.
• La complexité dans un code source n’est pas souhaitée, elle augmente le risque de faire des erreurs et donc d’introduire des défauts.
• Les outils d’analyse statiques peuvent être paramétrées pour vérifier le respect des standards de programmation, comme la séparation des couches métier, de vue et de données, le respect des règles de nommage, la déclaration de variables, l’utilisation des commentaires…etc
• L’analyse statique vérifie aussi des règles de sécurités comme les contrôles qui sont faits sur les saisies des champs des formulaires.
• L’outil d’analyse statique aide les développeur grâce à l’auto-complétion lors du codage pour éviter les erreurs de syntaxe et le respect de l’architecture du logiciel.

Cela permet de :

• Détecter des défauts avant l’exécution du code et l’exécution des tests dynamiques.
• Grâce à l’analyse statique l’équipe est informée au plus tôt sur les faiblesses du code ou de sa conception, ce qui peut orienter les tests dynamiques et améliorer leur efficacité.
• Grâce à l’analyse statiques des défauts comme « le code mort » sont détectés alors que c’est impossible de les trouver par des tests dynamiques
• Les dépendances entre les composants du modèle logiciel peuvent introduire des régressions et des comportement indésirables quand ils ne sont pas clairement identifiés. L’analyse statique donne une meilleure visibilité sur les liens et les dépendances entre les différents composants du code.
• Quand le logiciel est bien conçu, la complexité du code est contrôlée et les dépendances entre les différents composants sont maîtrisés, la maintenance du code devient plus facile, et introduire un développement supplémentaire pour faire évoluer le logiciel devient moins risqué pour sa qualité (régressions).
• Les outils d’analyse statiques sont un bon moyen d’accompagner les développeurs pour s’assurer de la bonne qualité des développements.

Les outils d’analyse statique sont aujourd’hui inclus dans les compilateurs comme Eclipse et NetBeans. Le développeur bénéficie alors ces services d’analyse pendant qu’il écrit son code.

L’analyse statique peut aussi être déclenchée par des évènement comme le lancement des tests unitaires, les tests d’intégration ou quand plusieurs développeurs travaillent sur le même logiciel un serveur de gestion de configuration assure la cohérence du code et peut déclencher aussi les traitements de l’analyse statique pendant la mise à jour du code.

Les outils d’analyse statiques sont configurables, le développeur peut choisir les standards de programmations et les règles que le code doit respecter. Sur la base de cette configuration, l’analyse statique génère des messages d’erreurs bloquants qui suscite une correction ou des avertissements qui ne nécessitent pas forcément de correction.

Le choix de la configuration de l’outil d’analyse statique doit être identique pour tous les développeurs qui interviennent sur une même application logicielle.

Il existe plusieurs types de revues.

Quatre variétés vont être présentées un peu plus loin dans cette section.

Une revue peut être plus ou moins formelle selon la rigueur qui est accordée à sa réalisation.

On choisit d’appliquer un type de revue plus ou moins formel selon les contraintes légale ou réglementaire du projet ou la maturité du processus de développement.

Si le projet a des exigences légales ou réglementaires fortes ou que le processus de développement est mature alors les revues seront des revues formelles ou « systématiques ».

Si le projet est nouveau et n’a pas de contraintes légales ou réglementaires alors les revues peuvent être plus informelles.

On choisit le niveau de formalisme aussi selon les objectifs de la revue :

• Trouver des défauts
• Augmenter la compréhension et former les testeurs et les nouveaux membres d’une équipe : parce que la documentation revue est un entrant majeur des tests et le test ne peut pas être efficace si les testeurs n’ont pas compris le besoin initial et comment doit se comporter une application.
• Organiser la discussion et décider par consensus

Une revue formelle doit comporter :

• Les acteurs du projet qui vont réaliser la revue
• Une procédure avec des instructions claire pour les relecteurs sur comment mener la revue
• Les résultats de la revue sont formellement tracés et communiqués.

1. Phases d’une revue formelle (K1)

1. Planification :

 Définir les critères de revues : Définir ce que les caractéristiques auxquelles les relecteurs feront attention lors de la revue

 Choisir le personnel : Choisir les participants qui vont réaliser les revues

 Allouer les rôles : Affecter des rôles précis aux participants : qui sera Manager, qui sera le Modérateur, Qui est l’Auteur, Les réviseurs et le Scribe : tous ces rôles seront détaillés un peu plus loin.

 Définition des critères d’entrée et de sortie pour des types de revues plus formels (p.ex., inspections) :

• Dans un projet, il faut prendre constamment des décisions de quand commencer les tests et quand il faut les clôturer. Pour cela on utilise les critères d’entrée et de sortie.
• Les critères d’entrée sont des éléments objectifs sur lesquels s’appuyer pour décider de commencer les revues
• Les critères de sorties sont des éléments sur lesquels l’équipe se base pour décider objectivement d’arrêter les tests

 Sélectionner la partie des documents à revoir : sélectionner les documents à relire et les chapitres qui seront ciblés en priorité.

 Vérification des critères d’entrée (pour des types de revues plus formels) : Une fois la planification est effectuée il est temps de vérifier si les conditions sont réunies pour commencer les revues.

2. Lancement:

Le lancement est le moment où les participants vont découvrir la documentation à revoir et le mode opératoire de la revue qu’ils vont réaliser. C’est à cette étape que les documents seront distribués aux participants et qu’une présentation leur sera faite sur les objectifs et le déroulement de la revue.

 Distribuer les documents

 Expliquer les objectifs, le processus et les documents aux participants

3. Préparation individuelle :

Pendant cette étape, chaque participant pourra relire le document de son côté avant la réunion de revue et préparer ainsi ses remarques, commentaires et questions.

 Préparer la réunion de revue en revoyant le(s) document(s)

 Ecriture des défauts potentiels, questions et commentaires

4. Examen/évaluation/enregistrement des résultats (réunion de revue):

C’est au cours de cette étape que la revue est réalisée. Les différents participants parcourent collectivement le document en soulevant les points de discussion, en détectant les défauts et en faisant des recommandations sur les corrections potentielles. Cette réunion peut se faire en présentiel ou à distance avec les outils de communication disponibles.

 Discuter ou enregistrer, avec des résultats ou minutes documentés (pour des types de revues plus formels)

 Noter les défauts, faire des recommandations concernant le traitement des défauts, prendre des décisions à propos des défauts

 Examen/évaluation et enregistrement pendant toutes les réunions physiques ou enregistrement de toutes les communications électroniques

5. Re travail :

Cette étape regroupe les travaux de correction des défauts détectés lors de la revue

 Correction des défauts détectés (réalisé généralement par l‟auteur)

 Enregistrer le statut modifié des défauts (dans les revues formelles) : par exemple la production d’une nouvelle version corrigée de la documentation revue.

6. Suivi:

Le Manager pilote les processus de revue, il suit les travaux de correction en vérifiant la prise en compte des défauts détéctés, qu’il n’y a pas de défaut qui a été oublié.

Les participants à la revue fournissent des indicateurs d’avancement sur les documents revues, les défauts détectés et les défauts corrigés.

Ces métriques sont collectés par le Managerpour vérifier (grâce aux critères de sorties définies lors de l’étape de la planification)  si les conditions sont réunies pour clôturer le processus de revue.

 Vérifier que les défauts ont bien été traités

 Récolter les métriques

 Contrôle sur la base des critères de sorties (pour des types de revues plus formels)

2. Rôles et responsabilités (K1)

Il y a 5 rôles principaux que les participants à la revue peuvent endosser :

Le Manager est la personne qui doit prendre des décisions sur quand commencer ou arrêter chaque étape du processus de revue.

Le modérateur est un rôle important dans le processus de revue, le modérateur facilite les interactions entre les participants à la revue, il anime toutes les réunions de l’étape de la planification jusqu’à l’étape de suivi.

L’auteur est celui qui a écrit le document qui sera l’objet de la revue. Si l’auteur n’est pas disponible ce rôle peut être porté par une autre personne qui aura la responsabilité principale sur le document à revoir.

Les réviseurs sont les personnes qui vont concrètement relire les documents pour détecter les défauts. Il est conseillé que les réviseurs aient des profils différents pour multiplier les perspectives. Un document pourrait ainsi être vérifié par un utilisateur qui va vérifier que le document couvre bien un besoin réel, un testeur vérifie que des cas particuliers et des cas limites sont bien pris en compte, un profil technique vérifie bien que ce que décrit le document est techniquement réalisable. Tous les réviseurs émettent des questions et des remarques ou remontent des défauts potentiels. 

Le Scribe garantie la traçabilité, note enregistre tous les points identifiés pendant la réunion.

Des check-lists peuvent être utilisés pour garantir que tous les aspects d’une revue ont été vérifiés, cela permet aussi de rendre les revues plus industrialisées et plus rapide en parcourant les points d’une check-list préétablie.

3. Types de revue

Il existe plusieurs types de revue.

Un document peut faire l’objet de plusieurs types de revue.

Le syllabus définit 4 types de revue de la moins formelle à la plus formelle :

1. La revue informelle
2. La relecture technique
3. La revue technique
4. L’inspection

La revue informelle :

• La revue informelle est la revue la moins contraignante,
• Elle n’obéît pas à un processus préétablie.
• Elle peut se dérouler par la programmation par paires ce qui correspond à deux développeurs qui travaillent ensemble sur une même tâche sur le même poste. Cela diminue fortement le risque d’erreur.
• La revue informelle peut aussi être effectuée simplement quand un profil technique relit seul le document de conception technique ou le code de l’application.
• Les résultats de la revue peuvent être documentées mains ce n’est pas une obligation, les défauts peuvent être corrigés directement au fur et à mesure de leur détection.
• Ce type de revue peut varier d’utilité selon les réviseurs, il n’y a pas de contrainte qui oblige à multiplier les réviseurs et ainsi varier les perspectives : utilisateur, testeur, développeur et opérateur.
• L’objectif principal étant d’améliorer la qualité avec un minimum d’investissement.

La relecture technique :

• La relecture technique est dirigée par l’auteur du document à revoir
• La réalisation de la relecture technique peut être structurée sur la base des scénarios, en traitant le périmètre scénario par scénario, en faisant des répétitions à blanc pour comprendre et assimiler le contenu ou en impliquant des pairs càd des réviseurs qui ont le même profil que l’auteur et qui peuvent apporter un regard critique et enrichir le document revu.
• Il n’y a pas de limite de durée définie pour ce type de revue
• Ce type de revue peut être plus ou moins formel. Il est possible que les réviseurs préparent la revue au préalable mais cela reste facultatif ainsi que la présentation d’un rapport de résultats de revue et la participation d’un scribe.
• Les objectifs de ce type de revue peut-être la relecture pour découvrir et apprendre le contenu du document, la compréhension et l’assimilation du comportement attendu de l’application si c’est un document de spécifications ou tout simplement de trouver des défauts.

La revue technique :

• La revue technique est une revue documentée dont le formalisme varie aussi en pratique de quasiment informelle à très formelle.
• Elle a comme objectifs de regrouper des pairs pour discuter du contenu des documents revus, évaluer les alternatives possibles, recommander des améliorations et décider des corrections.
• La réunion de préparation est incluse.
• Des check-lists peuvent être utilisées.
• Un modérateur formé peut animer la revue
• Un rapport de revue est présenté à la suite de la réunion de revue.

L’inspection :

L’objectif de l’inspection est de trouver des défauts

L’inspection est le type de revue le plus formel de cette liste.

Il inclut toutes les étapes du processus de revu présenté précédemment :

La planification, Les rôles, l’étape de préparation, le rapport de revue, les check-lists, le suivi et les métriques.

4. Facteurs de succès des revues (K2)

Pour qu’une revue soit une réussite :

• Il faut que ses objectifs soient définis à l’avance et assimilés par les participants à la revue.
• Il faut mettre les bonnes personnes aux bons postes
• Plus on teste tôt mieux c’est, les revues interviennent tôt dans le processus de développement, si les testeurs sont impliqués dans les revues, c’est une occasion pour eux d’accéder et d’analyser au plus tôt la documentation de référence (base de test) et ainsi commencer à préparer les tests dès le début du projet.
• Les défauts qu’ils soient détectés lors d’une revue ou lors d’un test classique, doivent être décrits de façon factuelle et neutre pour être acceptés et corrigés par les auteurs ou les développeurs.
• Les interactions avec l’auteur du document revu doivent être respectueux et objectifs. Il ne doit se sentir jugé ou critiqué. Les remarques et commentaires exprimés lors des revues doivent être réalisés avec tact. Les participants doivent alimenter une ambiance de confiance.
• Le choix du type de revue doit prendre en compte les objectif et le contexte du projet.
• Quand le niveau de risque est critique et le niveau de qualité attendu dans un projet est relativement grand, le niveau de formalisme des revues doit s’y adapter. Introduire des check-lists rendra alors les revues plus efficaces ainsi que la définition de rôles précis pour les participants.
• Les participants peuvent suivre des formations ou ils apprendront les responsabilités liées à ces différents rôles, comprendre le processus de revue et apprendre les différentes techniques de revue. Si les revues sont réalisées par un personnel formé, cela ne peut qu’améliorer l’efficacité de détection de défauts.
• Les revues sont des activités à part entière qui doivent être correctement inclus dans le cycle de vie du projet et planifiés par l’encadrement.
• La maturité des activités de revues augmente grâce à l’amélioration continue, les participants à la revue peuvent échanger sur le déroulement des revues précédentes et suggérer des actions pour améliorer l’efficacité des prochaines revues.

Les tests statiques sont les tests qu’on peut effectuer sans avoir à exécuter le logiciel.

Un testeur réalise des tests statiques soit sur le code d’une application, soit sur la documentation du projet.

Il existe deux façons de réaliser les tests statiques :

• Les revues
• Et l’analyse statique

Les revues sont des séances de relecture du code ou d’une documentation qui peuvent être effectués bien avant l’exécution du code de l’application.

Parfois une relecture suffit pour se rendre compte de l’existence d’un défaut dans la documentation ou dans le code.

Le défaut ainsi détecté peut être corrigé en quelques instants par une simple modification dans le document ou le code relus.

Si la revue n’avait pas été faite, le défaut aurait conduit à un incident dont la détection aurait suscité la conception de tests, l’exécution de ces tests, la création de rapports d’incident, la reproduction de l’anomalie par le développeur, la modification du code pour corriger le défaut, la relivraison du logiciel dans l’environnement de test et la réexécution du test pour confirmer la correction du défaut.

Détecter un défaut au plus tôt grâce aux revues fait économiser au projet beaucoup de temps et d’argent.

Les testeurs et les développeurs peuvent réaliser des revues sur tout type de bases de test :

• Spécifications fonctionnelles
• Spécifications techniques
• Cahier d’exigences
• Code source
• Expression de besoin
• Le Plan de test où sont répertoriés les tests à réaliser : si le test n’est pas bon ça peut amener à créer des rapports pour des défauts qui n’en sont pas uns.
• Etc

Relire des documents de spécification avec un œil critique grâce aux revues, permet au testeur d’assimiler le comportement fonctionnel attendu de l’application :

• Détecter les oublis et les omissions,
• Remonter les ambigüités qui résident dans ses documents,
• Et échanger avec les référents métier qui les ont rédigés pour les clarifier et les compléter avant que le développeur se base dessus pour fabriquer la solution logicielle correspondante.

Les revues peuvent être réalisés manuellement mais on peut se servir d’outils de support.

Pour réaliser une revue, le testeur examine un document et au fur et à mesure de la lecture il peut faire des commentaires.

Il peut ainsi souligner un oubli, une ambiguité à clarifier, ou une spécification erronée à corriger.

La revue, l’analyse statique et le test dynamique sont des techniques différentes pour atteindre le même objectif.

Les tests statiques trouvent les défauts et peuvent donc être corrigés directement.

Les tests dynamiques quant à elle trouvent des défaillances, et il faut que le développeur investigue pour trouver les défauts correspondants.

Elles sont complémentaires.

Ces techniques peuvent toutes être utilisés dans un même projet.

Les défauts typiques où les tests statiques sont plus efficaces pour les détester sont :

• Déviations par rapport aux standards
• Défauts d’exigences
• Défauts de conception
• Maintenabilité insuffisante
• Spécifications incorrectes d’interfaces

Vous remarquerez que ce sont des défauts de conception fonctionnelle et technique qui sont introduits avant le codage du logiciel.

La maintenance est l’ensemble des activités effectués sur le logiciel après le déploiement.

Une fois un système logiciel est fabriqué et déployé, il est utilisé pendant des années.

Pour que le logiciel continue à être utilisé au cours des années, il faut que les incidents rencontrés soient corrigés, il faut faire évoluer ses fonctionnalités pour répondre aux nouveaux besoins des utilisateurs, il faut le migrer vers un nouvel environnement pour l’adapter aux nouvelles technologies, ou si nécessaire le supprimer de façon sécurisée en archivant les données importantes.

Toutes ces activités de modification de migration et de suppression sont des activités de maintenance.

Tous les tests associés aux activités de maintenance sont appelés des tests de maintenances.

Les modifications :

Les modifications peuvent être des corrections, des évolutions, ou des changements d’environnement.

Les corrections peuvent se faire à travers des livraisons planifiées à l’avance ou à travers des hot fixes ou des corrections à chaud en cas de détections d’un incident critique dont la correction est urgente.

Les évolutions sont des livraisons généralement planifiées de versions étendues du système logiciel.

Les changements d’environnement sont des mises à jour d’envergure limitée de l’un des éléments qui constituent l’environnement du système logiciel comme le système d’exploitation sur lequel il est basé, la base de données ou il stocke ses données et les logiciels sur étagère COTS dont le système dépend et qui doivent être mis à jour.

Tous ces éléments sont à mettre à jour régulièrement pour entretenir la qualité et le niveau de sécurité du système logiciel.

Les migrations :

Les migrations sont des changements majeurs dans l’environnement.

La taille et les spécificités des changements introduits lors des migration implique de les traiter comme une catégorie de maintenance à part entière.

Si lors d’une migration, la base de données est changée, le schéma de donnée qui est la structure qui organise le stockage et la manipulation de donnée change aussi.

Le changement de schéma de données implique la modification du code du système logiciel pour établir la communication entre l’application et sa nouvelle base de données.

Les tests de maintenance doivent alors vérifier les modifications du logiciel, ses caractéristiques opérationnelles dans sa communication avec la base de données, ainsi que l’intégrité des données récupérées de l’ancienne base et converties vers le format de la nouvelle base de données.

La suppression :

La « mise au rebut » est un terme comptable pour signifier la destruction ou la mise hors service d’un bien.

Une suppression est effectuée quand un système est remplacé par un autre système (et pas seulement sa base de données), ou quand le système est totalement abandonnée et seules ses données sont gardées et stockés grâce à des mécanismes d’archivage.

Les types de tests

Les tests de maintenances incluent donc :

• des tests qui vérifient les parties qui ont été modifiés pour vérifier qu’ils fonctionnent comme prévu,
• et des tests de régressions pour vérifier que les autres parties qui n’ont pas été modifiés n’ont pas été impactés par les changements.

Comme les tests de fabrication d’un nouveau logiciel, les tests de maintenance d’un logiciel existant peuvent être effectués sur plusieurs niveaux et en combinant plusieurs types de tests : fonctionnels, non fonctionnels, structurels, de confirmation et des tests de régressions.

Le périmètre de tests de maintenance est défini selon la criticité des parties modifiés, l’ampleur des des modifications réalisées et la taille du système global.

L’analyse d’impact est une étude qui permet d’identifier les conséquences d’un changement dans un logiciel.

Cette analyse d’impact est utile pour décider de ce qui doit être testé pour prévenir les régressions. Et déterminer les tests de régressions à réaliser.

Les spécifications sont le point de référence pour juger de la conformité d’un logiciel au fonctionnement attendu. 

Négliger de mettre à jour les spécifications complique la réalisation des tests de maintenance parce qu’on ne sait plus ce qui est attendu, et donc normal.

Les testeurs qui ont de l’ancienneté dans le projet peuvent limiter l’impact de l’absence de spécification grâce à la connaissance fonctionnelle qu’il ont du logiciel, mais ces testeurs peuvent ne plus être disponibles s’ils sont en congé ou s’ils quittent le projet.

Il est donc important d’entretenir des spécifications à jour tout au long de la maintenance d’un système logiciel.

Dans le syllabus ISTQB distingue 5 types de test :

1. Les tests fonctionnels 
2. Les tests non-fonctionnels 
3. Les tests structurels
4. Les tests liés aux changements : qui se composent des tests de confirmation et les tests de régression

Le logiciel à tester peut-être modélisé et représenté sous la forme d’un diagramme.

Cette représentation permet aux développeurs de mieux comprendre ce qu’ils doivent fabriquer, et aide les testeurs à concevoir les tests de s’assurer qu’ils couvrent tous les cas de figure importants.

Par exemple :

• Diagramme de transition d’état :
• Diagramme de flux de processus
• Diagramme de contrôle de flux
• La structure de menu
• Modèle de menace de sécurité
• Spécification en langage naturel : en français le moins technique possible

On verra dans le chapitre 4 quelques-unes de ces techniques de modélisation.

1. Tests fonctionnels

Les fonctions sont ce que « fait » le logiciel.

Par exemple pour une application d’une banque :

• Créer un compte bancaire
• Modifier un compte bancaire
• Faire un virement
• Imprimer le RIB
• Commander une carte bancaire
• …etc

Les tests qui vérifient ces fonctionnalités sont appelés « Les tests fonctionnels ».

Le test fonctionnel est de loin le plus populaire parmi les types de test.

Ces tests sont conçus à partir des livrables non techniques qui décrivent le fonctionnement attendu de l’application, comme :

• les spécifications fonctionnelles
• les spécifications d’exigences
• Les cas d’utilisation
• Le fonctionnement attendu de l’application peut ne pas être décrit noir sur blanc dans un document mais il peut être extrait à partir des échanges avec le client ou les utilisateurs.

Les fonctions sont ce que « fait » un composant, un ensemble de composant, un système ou un système de systèmes.

Les tests fonctionnels peuvent donc être réalisé à tous les niveaux de test : test composant, test d’intégration, tests système et tests d’acceptation (ou éventuellement tests d’intégration système).

Les tests fonctionnels exécuté dans chaque niveau se base sur le livrable du niveau de développement correspondant dans le cycle en V.

Comment Dériver des conditions de tests fonctionnelles de ces livrables et les techniques de conception des cas de tests seront couverts dans le chapitre 4 du syllabus.

Les tests fonctionnels vérifient le comportement extérieur d’une entité logicielle, ce comportement est l’ensembles des fonctionnalités que le logiciel fournit indépendamment des choix techniques qui sont fait pour fabriquer ce logiciel.

Ces tests sont donc des tests boite noire car ils ne s’intéressent pas au code et à la structure technique du produit logiciel.

Les tests de sécurité et les tests d’interopérabilité

Les tests de sécurité et les tests d’interopérabilité sont des tests fonctionnels.

 Les tests de sécurité examinent les vulnérabilités du système et les tests d’interopérabilité vérifie la capacité du système à interagir avec d’autres systèmes.

Il y a souvent confusion entre intégration et interopérabilité.

L’intégration s’assure de la communication entre des composants ou des systèmes qui sont fabriqué ensemble. L’intégration est définitive.

L’interopérabilité s’assure de la communication entre des systèmes développés par des éditeurs différents. L’interopérabilité est temporaire et est remise en question à chaque mise à jour d’un des systèmes communicants.

2. Tests non-fonctionnels

Les tests non-fonctionnels n’évaluent ce que « fait » le produit logiciel mais « comment » il le fait.

Est-ce qu’il est rapide ? fiable ? facile d’utilisation ? maintenable ? portable sur des supports différents ? …etc

Des exemples de tests non fonctionnel :

• Test de performances : vérifient que le logiciel est suffisamment rapide en temps d’exécution et en débit.
• Test de charge : déterminent la charge maximale supportée par l’application
• Test de stress : vérifie comment réagit l’application quand elle fait face à sa charge maximale
• Les tests d’utilisabilité : vérifie que l’application est facile d’utilisation et de prise en main.
• Les tests de maintenabilité : vérifient la facilité d’adaptation de l’application à des modification de code ou à des évolutions des environnements extérieurs sans que cela génère des régressions.
• Les tests de fiabilité : vérifient Le degré avec lequel l’application reste disponible malgré les interruptions.
• Les tests de portabilité : vérifient la facilité de transfert de l’application d’un environnement à un autre.

Ces tests non-fonctionnels peuvent être réalisé au niveau des tests composant, au niveau Intégration, au niveau système et par le client au niveau d’acceptation.

Mais la grande différence avec les tests fonctionnels qui sont soit OK soit KO. Les résultats des tests non-fonctionnels sont des valeurs sur une échelle.

Comme le temps de réponse en millisecondes quand on effectue des tests de performance.

Le nombre d’utilisateurs  en connexion simultanés quand on effectue des tests de charge.

L’ISO9126 décrit les caractéristiques qualité qui peuvent faire l’objet des tests non fonctionnels.

Les tests non fonctionnels comme les tests fonctionnels vérifient le comportement du logiciel sans s’intéresser au code. Ce sont donc des tests « boite noire ».

3. Tests structurels

On dit que les tests structurels sont des tests « boite blanche » parce qu’elles se basent sur le code de l’application ou avec des mots plus compliqués : la structure logicielle du système.

Quand le testeur fait des tests boite noire, il ne s’intéresse pas à la structure du code, au langage de programmation, ou aux technologies impliquées. Le testeur conçoit les tests à partir des spécifications et vérifie que le logiciel fournit les services qui ont été prévus dans les spécifications, indépendamment de la technologie utilisée pour le fabriquer.

Quand un testeur fait des tests boite blanche, cela veut dire qu’il peut voir le code et qu’il peut concevoir des tests selon la structure de ce code, pour couvrir et vérifier ses chemins d’exécution possibles.

Comme les autres types de tests, les tests structurels peuvent être réalisés pendant le niveau des tests composants, le niveau d’intégration, ou le niveau des tests système et rarement pendant les tests d’acceptation qui sont généralement effectués par des profils peu techniques comme les utilisateurs.

Le code source d’un logiciel peut être modélisé sous forme d’un graphe composé d’étapes et des transitions qui représentent les instructions du code.

Chaque test déclenche l’exécution d’une partie du code.

Quand les testeurs ont une visibilité sur le code ils peuvent mesurer les chemins et les parties du code couverts par leurs tests. Ce que ne permettent pas les tests boite noire basées sur les spécifications.

Exemple de code :

Lire (Age*) ; * une valeur sur le clavier

Si Age < 18 Alors

Afficher (« Mineur »)

Sinon

Afficher (« Majeur »)

A est une instruction simple.

B est une condition qui crée une bifurcation dans la structure du code. Quand la condition est vrai cela déclenche un traitement c. si la condition est fausse, cela déclenche un traitement d.

Supposant qu’on crée un test 1 avec une valeur à taper sur le clavier de 15.

Test 1 : Age = 15

L’exécution de ce test parcourra le chemin abc. Et l’instruction d ne sera pas exécutée.

Si la campagne de test ne contient que le Test 1 alors la couverture des tests est de 50% parce que le test a couvert la moitié des chemins possibles du code.

Pour augmenter la couverture, on peut concevoir un deuxième test qui va orienter l’exécution vers le chemin qui parcourt l’instruction « d ».

Test 2 : Age = 40

En exécutant la suite de ces deux tests, on a couvert 100% de la structure du code.

Les techniques de couverture sont traitées plus en détail dans le chapitre 4.

Mesurer la couverture du code eut vite devenir un cauchemar si on le fait manuellement, mais heureusement il existe des outils qui le fait à notre place en parcourant les instructions ou les décisions comme les conditions si-alors et les boucles.

Les tests qui se basent sur la structure du code sont surtout les tests sur les premiers niveaux du cycle projet comme le niveau des tests composant et le niveau des tests d’intégration. Ils peuvent être réalisés lors des tests du niveau système et au niveau des tests d’acceptation mais c’est beaucoup moins fréquent

4. Les tests de confirmation et de régression

Les tests de confirmation

Les tests de confirmation sont des tests exécutés une deuxième fois pour confirmer la correction d’une anomalie qui a été détectée lors de la première exécution du test.

C’est compliqué ?

Voici comment cela se produit dans le temps.

Pendant la phase d’exécution. Le testeur exécute des cas de tests.

Lorsque le testeur détecte un incident lors de l’exécution d’un cas de test, le testeur crée un rapport d’incident et l’envoie au développeur.

Le développeur cherche le défaut à l’origine de l’incident grâce au débogage.

Quand le développeur trouve le défaut, il corrige et livre la nouvelle version corrigée du logiciel au testeur.

C’est à ce moment là que le testeur réalise un test de confirmation en vérifiant que l’incident ne se produit plus.

Les tests de régression

Quand on modifie le code d’un logiciel pour ajouter de nouvelles fonctionnalités ou pour réaliser des corrections, on risque de toucher à des parties du logiciel qui fonctionnait correctement, et qui après modification, ne fonctionnent plus comme avant.

C’est ce qu’on appelle des régressions.

Les tests de régression ont pour objectifs de s’assurer que les modifications apportées au logiciel n’apportent pas des régressions dans ce même logiciel ou sa compatibilité avec les autres systèmes avec lesquels il communique.

Plus la modification apportée au logiciel impacte des parties importantes de ses composants, plus le risque de régression est grand, plus le périmètre des tests de régression doit être étendue.

Les tests de confirmation et les tests de régression sont censés être exécutés plusieurs fois, il doit donc être possible de les répéter grâce à des pas de test claires et bien définies.

Tous les types de test vus précédemment peuvent devenir des tests de régression s’ils concernent des caractéristiques ou des parties existantes du logiciel qui ne sont pas censés changer.

Les tests de régression peuvent être réalisés quelques soit le niveau de test.

L’automatisation permet de programmer un test une seule fois et de l’exécuter automatiquement autant de fois qu’on le souhaite de jour ou de nuit.

L’automatisation est un investissement qui a un coût, il faut donc bien choisir les tests à automatiser.

Pour automatiser un test, il est préférable que le test concerne une partie importante du logiciel qu’il faut donc vérifier de façon récurrente, et qui ne subit pas beaucoup d’évolution (pour ne pas avoir à constamment mettre à jour le test).

Les tests de régression étant des tests à exécuter régulièrement, et qui ne changent pas souvent. Ce sont de bons tests à automatiser.

Le syllabus de l’ISTQB définit 4 niveaux de test principaux :

1. Les tests composants
2. Les tests d’intégration
3. Les tests système
4. Les tests d’acceptation

Pour comprendre ces niveaux de test, il faut garder à l’esprit la représentation qui est fait d’un système ainsi que la correspondance qui existe entre les niveaux de développement et les niveaux de test pour fabriquer ce système.

Un système peut être constitué de plusieurs composants ou modules.

Chaque composant interagit avec les autres composants via des interfaces et des protocoles de communication.

Pour qu’un système fonctionne correctement :

• Il faut que chaque composant du système fonctionne bien séparément
• Il faut que chaque composant communique bien avec les composants avec qui il interagie.
• Il faut que toute la chaine de composants fonctionne comme prévu.

Pour fabriquer un système ainsi imaginé, Le cycle en V nous aide à :

1. Concevoir le système du niveau le plus haut au niveau le plus bas.
2. Fabriquer le système et le tester du niveau le plus bas au niveau le plus haut.

À gauche du modèle en V, Chaque niveau de développement (qui est en réalité un niveau de conception sauf le dernier) produit un livrable qui est la base de test et la référence pour le niveau de test qui est à gauche du modèle en V.

• L’expression de besoin produit un livrable qui sera la référence des tests à réaliser au niveau d’acceptation.
• La conception fonctionnelle produit un livrable qui sera la référence aux tests à réaliser au niveau des tests système.
• La conception de l’architecture technique produit un livrable qui sera la référence aux tests à réaliser au niveau des tests d’intégration.
• Les tests composants seront réalisés sur la base de la conception technique et du code de l’application.

Pour comprendre l’utilité de ces niveaux de test et pouvoir les distinguer facilement, le syllabus s’appuie sur les points suivants :

• Les objectifs de test
• La base de test : ce sont les livrables et la documentation de référence sur lesquels on se base pour extraire les cas de test, comme les exigences, les spécifications et les documents de conception fonctionnelles ou techniques.
  • Un test est une comparaison entre le comportement réel d’une application et une « Référence ».
  • Cette « Référence » décrit le comportement attendu de l’application.
  • C’est cette référence qui permet au testeur de juger que ce qu’il a constaté est une anomalie ou pas.
  • Si le système ne fonctionne pas comme décrit dans la documentation de référence alors il y a une défaillance.
  • L’ISTQB appelle cette référence : la base de test.
• Les objets de test : c’est-à-dire ce qui est habituellement testé par le niveau de test, cela peut être une partie technique du système ou un de ses aspect fonctionnels.
• Les défauts et défaillances typiques à trouver
• Les exigences en harnais de test et en support d’outils : c’est-à-dire de quoi s’équiper pour réaliser les vérifications de chaque niveau de test, comme l’environnement de test, les postes de travail, les outils et logiciels, des bouchons et des simulateurs…etc
• Chaque niveau de test peut avoir des approches et des responsabilités qui lui sont spécifiques.
• Tous ces éléments sont précisés lors de la phase de planification. La première phase du processus de test.

1. Les tests Unitaires/de Composants

Les tests composants sont plus populaires sous le nom de tests unitaires.

Les tests de composants est le niveau dont les tests sont généralement les premiers à être exécutés.

Ces tests sont préparés sur la base de la conception technique et du code de l’application.

Les exigences des composants est la description de ce doit faire chaque composant.

Les noms des livrables sont souvent différents d’une organisation à une autre.

Dans ce niveau on teste habituellement des composants si le système est simple.

Cependant on peut aussi être amenés à tester des programmes entiers si le système à tester est lui-même composé de d’autres systèmes et programmes.

Si le projet est une migration d’un ancien système vers un nouveau système en récupérant les données existantes. Ce niveau de test peut comporter des tests sur des programmes de conversion vers le nouveau schéma de données et la manipulation des modules de bases de données.

Les tests composants vérifient le fonctionnement de chaque composant séparément dès qu’il est développé.

Chaque composant peut être isolé du reste de l’application, cela permet de concentrer l’attention et l’effort de test sur les aspects fonctionnels comme non fonctionnel d’un seul composant.

Si une anomalie est détectée, il n’y a pas d’ambiguïté sur son origine.

Parfois, pour qu’un composant fonctionne, il faut absolument qu’il demande une donnée à un autre composant.

Quand cet autre composant n’est pas encore développé ou pas encore testé donc non fiable. Un bouchon peut être utilisé pour le simuler.

Si par contre quand le composant à tester s’attend à des instructions d’un autre composant qui n’est pas encore prêt, Alors les tests peuvent être réalisés en utilisant un Pilote pour simuler le composant indisponible.

Types de test :

 Lest tests composants peuvent être fonctionnels càd ce que le logiciel fait ou non fonctionnels càd comment il le fait.

Les tests non fonctionnels peuvent être des tests de robustesse.

Les tests de robustesse sont des tests qui vérifient le comportement de l’application dans des circonstances exceptionnelles comme le débranchement d’un câble ou une panne de réseau. Un système robuste a une réaction prévisible lors des conditions dégradées.

Les tests structurels sont des tests qui vise à couvrir les chemins d’exécution possibles du code de l’application, en passant par les boucles et les conditions (if-else possibles).

En pratique :

Généralement les tests unitaires sont un code qui teste le code du système. Les tests de ce niveau sont réalisés par le développeur qui a programmé le composant. Dans ce cas les tests sont automatiques puisque c’est du code, et ils sont conçus et exécutés grâce au même environnement de développement et des outils de débogage qui ont servi à développer l’application.

Un framework est une bibliothèque logicielle qui donne un cadre structuré et un squelette à une application.

Des frameworks de tests unitaires existent pour permettre de mieux structurer et de facilement gérer les tests unitaires.

Tester d’abord :

Il est de plus en plus populaire et à juste titre de concevoir les tests avant de développer le code qu’ils vérifient.

C’est une pratique introduite par les approches de développement itératifs qui se servent des tests pour clarifier la conception et de vérifier que les développeurs ont bien compris l’attendu avant même de commencer à coder.

Le code des tests composants est écrit dans un langage de programmation. Il est donc par définition automatisé.

Ces tests échouent bien évidemment au début car les bouts de code qu’elles vérifient n’existent pas encore.

Quand le code de l’application est développé, les tests sont exécutés et les échecs montrent l’existence des défauts à corriger.

L’application est corrigée et les tests sont lancées automatiquement après pendant plusieurs itérations jusqu’à ce que les tests ne trouvent plus de défaut et sont tous au « Vert ».

Cette pratique est appelée « Test First » ou TDD pour Test Driven Development.

2. Les tests d’intégration

Les bases de tes de ce niveau sont tous les livrables du niveau de développement correspondant « Conception technique » comme :

• La conception du système
• L’architecture technique
• Les workflows ou les flux de données et les protocoles de communication
• Les cas d’utilisation qui décrivent les interactions entre les composants.

Les objets tests sont souvent :

• Les sous-systèmes du Système principale.
• Les bases de données
• L’infrastructure comme les postes de travail, les serveurs, les systèmes d’exploitation, les navigateurs web…
• Les interfaces entre les composants
• La configuration système et les données de configuration.

Le niveau de test d’intégration concentre les efforts de test sur les interfaces entre les composants.

Il vise à vérifier les échanges entre les différentes parties d’un système en testant les interactions et leur respect des protocoles de communication établis au préalable.

Tests d’intégration composant vs Test d’intégration système

Si on teste un système simple alors les tests d’intégration seront réalisés sur les interfaces des composants du système.

Si le système est une chaine applicative, elle-même constituée de d’autres système alors l’intégration de ce super-système suscitera des tests sur les interfaces entre les systèmes qui le composent. On appellera alors ce niveau Tests d’intégration Système, car il intègre plusieurs systèmes entre eux.

La portée de l’intégration.

Si on rencontre un dysfonctionnement en réalisant des tests d’intégration entre 2 composants, le défaut d’origine ne peut venir d’un des deux composants.

Par contre, si un dysfonctionnement est détecté pendant des tests d’intégration entre 9 composants.

Trouver le défaut d’origine devient une tâche à part entière qui nécessite un temps d’investigation qui prend du temps avant même d’envisager une correction.

Pour limiter l’impact de ce phénomène, une approche méthodique est nécessaire.

Il existe des stratégies pour bien gérer l’intégration des composants.

Ces stratégies se basent sur la structure logicielle de l’application sous forme d’arborescence selon les dépendances entre composants avec un sommet (top) et des feuilles (bottom).

Quand on commence par intégrer les composants au sommet puis un à un les composants qui en dépendent, la stratégie est appelée Top-Down.

Si on commence par intégrer les composants en commençant par le bas, la stratégie est Bottom-Up.

Si on n’a pas de stratégie et on teste tout en même temps (on connecte tout et on branche le cable d’alimentation) : cela s’appelle Big Bang.

Les tests d’intégration peuvent inclure des tests fonctionnels comme des tests non fonctionnels comme les temps de réponse des interactions.

Les tests sont sensés se focaliser sur les interactions entre les composants pendants les tests d’intégration, des tests de ce que fait chaque composant a dû être couvert pendant le niveau précédent : les tests composants.

Dans l’idéal, les professionnels qui réalisent les tests d’intégration devraient connaitre la structure logicielle de l’application.

Cette connaissance de l’architecture logicielle et du code est utile non seulement pour concevoir efficacement les tests mais aussi pour planifier leur fabrication dans un ordre qui va tenir compte des dépendances entre les composants.

3. Les tests système

Les tests système vérifie le fonctionnement du système dans sa globalité.

Le périmètre de test est la liste de tout ce qui doit être couvert par les tests.

Le périmètre de test doit être précisé dans des documents qu’on appelle Plan de test maître ou Plan de test du niveau système.

La documentation de test va être détaillée dans les prochains chapitres.

Les tests système sont souvent le dernier niveau de test du fournisseur de service qui fabrique et délivre le produit.

Il doit s’assurer que le produit qu’il a fabriqué se comporte conformément aux spécifications présentées au client.

L’environnement de test de ce niveau doit ressembler le plus possible à l’environnement de production dans lequel les utilisateurs finaux vont manipuler l’application.

Cela aide à éviter que l’application fonctionne bien pendant les tests système mais des défaillances apparaissent soudainement dans l’environnement des utilisateurs, parce que cet environnement est différent.

Les tests système sont conçus sur la base des livrables du niveau de conception fonctionnelle comme :

• Les spécifications fonctionnelles
• Les exigences
• Les cas d’utilisation
• Les processus commerciaux
• …

Les noms de ces livrables peuvent être différent d’un projet à un autre et’ d’une organisation à une autre mais elles sont en générale des conceptions de haut niveau du comportement de l’application.

Le niveau des tests systèmes vérifient :

• les exigences fonctionnelles : càd ce que l’application permet faire en terme de fonctionnalités
• Les exigences non fonctionnelles : càd comment elle le fait, est ce qu’elle est performante, est ce qu’elle gère bien des nombres importants d’utilisateurs, et comment se comporte-elle dans des cas exceptionnels comme les pannes de courant et de réseau
• La qualité des données doit aussi être vérifiée

Ces exigences peuvent être explicitement décrites dans les documents de conception, mais elles peuvent aussi être sous-entendues et implicites.

Le testeur doit pouvoir relever ce type d’exigences et aider à les expliciter pendant les échanges avec les rédacteurs des documents de conception.

Ce niveau de test est le premier niveau ou les techniques de conception de test boite noire peuvent être utilisées.

Il est aussi le dernier niveau ou les techniques boite blanche peuvent être utilisées (après les tests composant et les tests d’intégration)

Boite blanche veut dire que le testeur conçoit ses tests en se basant sur la structure technique du produit logiciel : càd le code

Boite noire correspond aux tests qui ne s’intéresse pas à l’architecture technique du logiciel mais à ce que le logiciel permet de faire indépendamment de son implémentation (code, langage de programmation, architecture : etc

Donc :

• Boite blanche : on voit le code (on voit à travers la boite)
• Boite noire : on ne voit pas le code (puisque c’est sombre)

Le niveau Tests système permet d’utiliser les techniques de conception boite noire et boite blanche mais la priorité est aux tests boite noire car elle correspond bien au caractère « haut niveau » des tests système.

Les techniques de conception Boite blanche et boite noire seront détaillées dans les chapitres suivants.

• Tests d’acceptation

Les tests d’acceptation sont réalisés par ceux qui ont exprimé le besoin.

Ce niveau de test relève donc de la responsabilité du Client qui a commandé le produit logiciel ou les utilisateurs qui vont le manipuler.

L’objectif principal des tests d’acceptation n’est pas de trouver des défauts comme le sont les tests système.

L’objectif des tests d’acceptation est d’acquérir de la confiance dans le système en validant qu’il est utilisable et qu’il correspond bien au besoin initial et aux attentes fonctionnelles et non fonctionnelles exprimées.

Si le système fonctionne seul, Les tests d’acceptation sont le dernier niveau de test avant le déploiement dans l’environnement des utilisateurs finaux.

Si le système n’est qu’une brique d’une série d’application interconnectées, Les tests d’acceptation peuvent être suivis de tests d’intégration système pour vérifier qu’il interagit bien avec les autres applications avec lesquels il est sensé communiquer.

4. Les tests d’acceptation

Un client peut valider le produit à plusieurs niveaux de test.

• Il peut faire des tests d’acceptation pour un composant sur étagère « acheté clé en main » quand il est installé ou intégré à un système existant.
• Les tests composants qui sont d’habitude de la responsabilité des développeurs peuvent inviter les utilisateurs pour confirmer que le fonctionnement spécifié du composant est facilement utilisable comme prévu. Impliquer le client ou les utilisateurs aussi tôt permet de s’assurer que la conception satisfait bien ce client et ces utilisateurs au fur et à mesure de l’avancement des développements, et de rectifier tout problème au plus tôt.
• Les tests d’acceptation d’une évolution importante peuvent être tests avant les tests système.

Tests d’acceptation utilisateur

Ces tests valident l’utilisabilité du système càd son ergonomie et sa facilité d’utilisation comme par exemple si la navigation dans l’application est intuitive.

Les tests d’acceptation opérationnels

• Les test de backups et restauration : ce sont des tests qui visent la capacité du système à sauvegarder les données et les restaurer
• La reprise après sinistre : ce sont des tests qui vérifient que l’application réagit bien après un évènement exceptionnel comme une coupure de courant, une panne de réseau etc..
• La gestion des utilisateurs : Les utilisateurs peuvent avoir des rôles différents et des habilitations plus ou moins importantes
• Tâches de maintenance : le logiciel peut être plus ou moins facile à maintenir, selon la conception du logiciel introduire une évolution peut avoir des repercutions. Si le système est complexe et mal conçu, introduire une évolution peut avoir des impacts indésirables sur des parties qui fonctionnaient bien jusque-là. Ce manque de maintenabilité peut mener vers des régressions dans système.
• Chargement des données et tâches de migration : dans les projets de migration, un système A peut être remplacé par un système B ce qui fait hériter le système B des données contenus dans le système A. Des tests sont nécessaires pour valider que les données sont bien récupérées sans omission, altération et sans doublons en respectant le schéma de données du nouveau système.
• Les tests de sécurité sont des tests qui deviennent de plus en plus importants et ils peuvent être périodiquement réalisés dans le niveau d’acceptation opérationnelle.

Tests d’acceptation contractuelle et réglementaire

Les tests d’acceptation contractuelles sont liés à un contrat qui gère les modalités de fabrication d’un logiciel sur mesure. Pendant ces tests d’acceptation, on vérifie que les caractéristiques définis dans le contrat ont été respectés.

Les tests d’acceptation réglementaires sont réalisés pour vérifier la conformité à des exigences réglementaires liées à un pays, au secteur d’activité, ou d’autres obligations légales.

Tests alpha et beta

Les éditeurs d’outils logiciels souhaitent souvent tester leurs applications à une échelle qui s’approche le plus possible des conditions réelles d’utilisation avant de les commercialiser.

Les tests Alpha sont réalisés par des gens qui n’ont pas developpé l’application mais qui sont dans la même entreprise que les développeurs

Les tests Béta sont réalisés par des personnes externe à l’entreprise comme des clients et des utilisateurs.

Les tests qui sont fait sur le site du fabriquant peuvent être appelé :

• des test d’acceptation usine
• ou des tests d’acceptation sur site.

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

Etape	Action	Résultat Attendu
1	Allumer la calculatrice	La calculatrice est allumée et affiche la valeur 0
2	Renseigner la valeur 9	La valeur 9 s’affiche sur l’écran
3	Appuyer sur le bouton « + »	La valeur 9 s’affiche toujours sur l’écran
4	Renseigner la valeur 11	La valeur 11 s’affiche sur l’écran
5	Appuyer sur le bouton « = »	La valeur 20 s’affiche sur l’écran

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.