Comprendre les niveaux de test

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

Les tests composants
Les tests d’intégration
Les tests système
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 à :

Concevoir le système du niveau le plus haut au niveau le plus bas.
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é :