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.