Concept: Niveaux de test
Ces instructions séparent les activités de test en catégories de tests : test développeur, unitaire, d'intégration, test système et test de réception.
Relations
Eléments connexes
Description principale

Les tests s'appliquent à différents types de cibles, à différentes étapes ou à différents niveaux d'effort de travail. Ces niveaux sont généralement définis par les rôles les plus compétents pour concevoir et mener à bien les tests, et là où les techniques sont les plus appropriées pour les tests à chaque niveau. Il est important de trouver un équilibre entre ces différents efforts de travail.

Test développeur

Les tests développeur font référence aux aspects de la conception et de l'implémentation du test auxquels l'équipe de développeurs doit s'intéresser. Ils s'opposent aux tests indépendants. Dans la plupart des cas, l'exécution du test est initialement prise en main par le groupe de test développeur qui a conçu et implémenté le test, mais il est bien que les développeurs créent leurs tests de telle sorte qu'ils soient exécutables par des groupes de test indépendants.

Traditionnellement, les tests développeur sont principalement utilisés pour les tests d'unité. Bien que certains développeurs exécutent également des tests d'intégration à des niveaux variables, cela dépend largement de la culture et d'autres questions de contexte. Nous recommandons que les tests développeur ne se limitent pas uniquement au test d'unités indépendantes isolées.

Test indépendant

Les tests indépendants désignent conception et l'implémentation de tests exécutés de préférence par une personne indépendante de l'équipe de développeurs. Vous pouvez considérer cette distinction comme un sur-ensemble, qui comprend une vérification et une validation indépendantes. Dans la plupart des cas, l'exécution des tests est initialement prise en main par le groupe de test indépendant qui a conçu et implémenté les tests, mais les testeurs indépendants doivent créer leurs tests de façon à ce qu'ils soient exécutables par des groupes de test développeur. Boris Beizer présente les différents objectifs des tests indépendants par rapport à ceux des tests développeur de la manière suivante :

"L'objectif des tests indépendants est de fournir une perspective différente et donc, des tests différents, et de mener en outre ces tests dans un environnement [...] plus riche que celui disponible pour les développeurs." [BEI95]

Test de parties prenantes indépendantes

Les tests indépendants sont des tests basés sur les attentes et les préoccupations des diverses parties prenantes. C'est pourquoi on les appelle tests de parties prenantes. Cette distinction est importante. Elle permet d'inclure un ensemble de préoccupations de parties prenantes plus vaste que ce qui peut habituellement être considéré, élargissant le terme "client" quelque peu générique pour prendre en compte des parties prenantes telles que le personnel d'assistance technique, les formateurs techniques et les commerciaux, en plus des clients et des utilisateurs.

En guise de dernier commentaire, la notion XP de test client fait référence à cette catégorie de tests indépendants dans RUP.

Test d'unité

Les tests d'unité sont axés sur la vérification d'éléments testables du logiciel plus petits. En général, les tests d'unité s'appliquent aux composants représentés dans le modèle d'implémentation pour vérifier que les flux de contrôle et les flux de données sont couverts, et qu'ils fonctionnent comme prévu. L'implémenteur exécute les tests d'unité au fur et à mesure du développement de l'unité. Les tests d'unité sont décrits de façon plus détaillée dans la discipline Implémentation.

Test d'intégration

Les tests d'intégration sont exécutés pour assurer que les composants du modèle d'implémentation fonctionnent correctement lorsqu'ils sont combinés pour exécuter un cas d'utilisation. La cible de test est un package ou un ensemble de packages dans le modèle d'implémentation. Souvent, les packages combinés proviennent d'organisations de développement différentes. Les tests d'intégration mettent en évidence l'état de non achèvement et les erreurs dans les spécifications de l'interface du package.

Dans certains cas, les développeurs supposent que d'autres groupes, tels que les testeurs indépendants, exécuteront ces tests d'intégration. Cette situation présente des risques pour le projet logiciel et en fin de compte pour la qualité du logiciel car :

  • les domaines d'intégration sont souvent un point de défaillance logicielle.
  • les tests d'intégration exécutés par des testeurs indépendants sont généralement fonctionnels et ne concernent que les composants les plus importants du logiciel.

Une meilleure approche est de considérer les tests d'intégration comme la responsabilité tant des développeurs que des testeurs indépendants, mais en faisant en sorte que la stratégie d'effort de test de chaque équipe ne se recoupe pas trop. La nature exacte de ce recoupement est basée sur les besoins du projet individuel. Nous vous recommandons d'encourager un environnement dans lequel les développeurs et les testeurs système indépendants partagent une vision unique de la qualité. Voir Concept : Test développeur pour plus d'informations.

Test système

Traditionnellement, les tests système sont réalisés quand le logiciel fonctionne entièrement. Un cycle de vie itératif permet aux tests système d'intervenir bien plus tôt, dès que des sous-ensembles bien formés de comportement de cas d'utilisation sont implémentés. La cible est généralement les éléments du système fonctionnant de bout en bout.

Test de réception

Les tests de réception utilisateur constituent le dernier test avant le déploiement du logiciel. L'objectif de ces tests est de vérifier que le logiciel est prêt et que les utilisateurs peuvent s'en servir pour effectuer les fonctions et tâches pour lesquelles il a été construit. Voir  Concept : Test de réception pour plus d'informations.

Il existe d'autres notions du test de réception, qui se caractérisent généralement par un transfert d'un groupe ou d'une équipe à une autre. Par exemple, un test de réception de construction est le test effectué pour valider le transfert d'une nouvelle construction logicielle, de l'équipe de développement vers les testeurs indépendants.

Commentaire sur l'ordre et la planification des niveaux des tests

Traditionnellement, on considère que les tests d'unité doivent être implémentés au début de l'itération en tant que première étape du test : toutes les unités devant réussir le test avant de poursuivre les étapes suivantes sont testées. Toutefois, dans un processus de développement itératif, cette approche est inappropriée en règle générale. Une approche plus appropriée consiste à identifier les tests d'unité, les tests d'intégration et les tests système les plus aptes à détecter les erreurs et à les implémenter et les exécuter sur la base d'une combinaison du risque le plus grand et de l'environnement de support.