4 Phases de test à respecter

Les phases de test :

Il existe quatre phases (ou niveaux) de test bien distinctes et progressives, qu’il faut respecter. Chaque phase visant un aspect spécifique d’un système ou d’un produit logiciel.

Le découpage des phases de test permet de :

• Éviter de la redondance entre les phases de test (tester en double).
• S’assurer que le produit est adéquat avant de l’intégrer dans une composante supérieure (progression).
• Faciliter la détection de la source d’erreurs.
• Éviter de générer des erreurs dans d’autres systèmes.
• Éviter de faire des tests « big-bang ».

Les quatre phases de tests sont : 

1. Tests unitaires (TU) pour vérifier le fonctionnement d’une pièce de logiciel en isolation.
2. Tests d’intégration (TI) pour vérifier l’interaction entre diverses composantes d’une seule application.
3. Tests de système (TS) pour vérifier le comportement du système dans son ensemble, soit inter-applications.
4. Tests d’acceptation (TA) pour valider si le système satisfait les besoins initiaux du client.

Tests unitaires (TU)

L’équipe de projet doit exécuter ses tests unitaires ou de composants de façon manuelle ou automatisée.

Les tests unitaires sont effectués pour démontrer qu’une unité satisfait ses exigences fonctionnelles et que sa structure d’implémentation est conforme au design de conception.

Ces tests d’un programme, d’une classe, d’un module ou d’un composant isolé, assurent l’absence d’erreurs d’analyse ou de programmation. L’objectif est de veiller à ce que la logique détaillée de la composante soit précise et fiable en fonction des spécifications prédéterminées.

Chaque traitement est validé individuellement et assure que 100% des lignes de codes ont été exécutées au minimum une fois.

Une unité de test est le plus petit élément logiciel testable pouvant être compilé, assemblé, lié, chargé et pouvant être sous gestion de configuration. Une page d’écran, un rapport est une unité pour l’équipe de test. Une unité est généralement l’œuvre d’un seul programmeur et est composée de plusieurs lignes de codes sources. La caractéristique essentielle d’une unité est qu’elle doit être significative pour être traitée comme un tout. Chaque développeur a la responsabilité de vérifier les fonctionnalités devant être satisfaites par ses unités.

Les tests unitaires sont effectués par l’équipe de développement dans l’environnement de développement au fur et à mesure que des unités sont développées.

Les efforts de réalisation (planification, conception et exécution) des essais unitaires sont de l’ordre de 6% des efforts total du projet, d’une phase, d’une release ou d’une itération.

Tests intégration (TI)

Les tests d’intégration sont effectués pour démontrer que même si une composante individuelle est satisfaisante, la combinaison de plusieurs composantes l’est aussi ; qu’elle satisfait ses exigences fonctionnelles et que sa structure d’implémentation est conforme au design de conception et à son architecture.

Les tests d’intégration suivent une progression ordonnée de tests dans laquelle des éléments logiciels et matériels sont assemblés et testés jusqu’à ce que l’ensemble de l’application soit testé.

Les tests d’intégration sont effectués idéalement par une équipe de test indépendante du développement, dans l’environnement de test.

Au fur et à mesure du développement, de nouvelles composantes sont développées et l’équipe de test s’assure de la bonne intégration des composantes jusqu’à ce que l’application exécutable complète soit réalisée.

L’équipe de test doit donc établir une stratégie d’intégration des composantes qui doit être incorporée au plan de test. Les tests d’intégration sont donc composés de modules simulés.

Les efforts de réalisation (planification, conception et exécution) des essais intégrés sont de l’ordre de 14% des efforts total du projet, d’une phase, d’une release ou d’une itération.

Tests de système (TS)

Les tests de système ont pour objectif de tester l’ensemble du système sous toutes ses coutures, incluant ses ramifications avec les autres applications et les systèmes externes. L’intégration avec les systèmes externes est importante à ce stade-ci.

Les tests de système s’occupent de l’aspect fonctionnel global du système.

Ils sont axés davantage sur les tests fonctionnels, ou de type black box, et vérifient la conformité avec l’ensemble des spécifications exprimées par le client.

Les tests de système sont effectués par l’équipe de test dans l’environnement de test.

Les tests de système comprennent également les tests de performance, de volume, de sécurité, de configuration, de stress, de démarrage et de recouvrement.

Les efforts de réalisation (planification, conception et exécution) des essais système sont de l’ordre de 14% des efforts totaux du projet, d’une phase, d’une release ou d’une itération.

Tests d'acceptation (TA)

Les tests d’acceptation sont des tests formels menés par le client. Ils déterminent si le système satisfait les besoins initiaux et si les critères d’acceptation sont respectés.

Les tests sont basés sur les processus d’affaires, ils valident que le système fonctionne comme prévu par l'utilisateur dans le monde réel. Ils sont basés sur des scénarios d’affaires réalistes.

Les tests d’acceptation sont réalisés par les utilisateurs du système ou leurs représentants avec l’aide du fournisseur dans l’environnement du client (pré-production).

Les tests d’acceptation permettent de valider le système dans un environnement semblable à celui de la production. À la suite de ces tests, la mise en production du système peut débuter.

Bonnes pratiques d’exécution

Lors de l’exécution des tests TI, TS et TA, on doit réserver environ 5% des efforts au début de la période d’exécution pour des tests ad-hoc avant d’amorcer les tests réels tels que planifiés.

Les tests ad-hoc sont des tests créatifs et informels non basés sur un plan ou cas de tests. Le testeur improvise et apprend le système durant l’exécution de ces tests. Ce sont des tests aléatoires basés sur la probabilité de trouver une erreur.

On termine la période de test avec environ 10% des efforts pour des tests exploratoires. Les tests exploratoires sont similaires aux tests ad-hoc, à la différence que le testeur connaît le système.

Conclusion

En couvrant toutes les étapes, des tests unitaires aux tests d'acceptation, chaque phase contribue à détecter et à corriger les anomalies, garantissant ainsi que le logiciel ou système répond aux attentes des utilisateurs et aux exigences du marché.

Dans mon prochain article, il sera question des bénéfices qu’apporte ce découpage des tests ainsi que de la nécessité d’élaborer une stratégie et un plan de test basés sur les risques.

Pour aller plus loin :