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 distingués 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.

Tests développeur Haut de la page

Les tests développeur font référence aux aspects de la conception et de l'implémentation du test les plus appropriés pour l'équipe de développeurs à entreprendre. Ils s'opposent aux tests indépendants. Dans la plupart des cas, l'exécution du test intervient initialement avec le groupe de test de développeurs qui a conçu est implémenté le test, mais il est bien que les développeurs créent leurs tests de telle sorte qu'ils soient disponibles pour être exécutés par les groupes de test indépendants.

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

Tests indépendantsHaut de la page

Les tests indépendants signifient la 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 un surensemble, qui comprend une Vérification & une Validation indépendantes. Dans la plupart des cas, l'exécution du test intervient initialement avec le groupe de test indépendant qui a conçu et implémenté le test, mais les testeurs indépendants doivent créer leurs tests de façon à ce qu'ils soient disponibles pour être exécutés par les groupes de test de développeurs. Boris Beizer donne l'explication suivante des différents objectifs qu'ont les tests indépendants par rapport aux tests développeur :

"L'objet des tests indépendants est de fournir un point de vue différent et, par conséquent, des tests différents ; en plus de mener à bien ces tests dans un environnement [...] plus riche que cela n'est possible pour les développeurs." [BEI95]

Tests de parties prenantesindépendantesHaut de la page

Un autre point de vue des tests indépendants est que ce sont des tests basés sur les attentes et les préoccupations de diverses parties prenantes. C'est pourquoi on les appelle tests de parties prenantes. Il s'agit d'une distinction importante : elle permet d'inclure un ensemble plus large de préoccupations de parties prenantes que ce que l'on pourrait traditionnellement prendre en considération, étendant le terme quelque peu générique de "client", aux parties prenantecomme le personnel d'assistance technique, les formateurs techniques, les commerciaux en plus des clients et utilisateurs finaux.

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

Tests unitaires Haut de la page

Les tests unitaires sont axés sur la vérification d'éléments testables du logiciel plus petits. En général, les tests unitaires 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 unitaires au fur et à mesure du développement de l'unité. Les tests unitaires sont décrits de façon plus détaillée dans la discipline Implémentation.

Test d'intégration Haut de la page

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 une série 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 qui se recoupe 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 Concepts : Tests développeur pour des informations complémentaires.

Tests système Haut de la page

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.

Tests de réception Haut de la page

Les tests de réception utilisateur constituent le dernier test avant le déploiement du logiciel. L'objectif du test de réception est de vérifier que le logiciel est prêt, et qu'il peut être utilisé par les utilisateurs finaux pour exécuter les fonctions et tâches pour lesquelles le logiciel a été conçu. Voir Concepts : Tests de réception pour des informations complémentaires.

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 version est le test effectué pour réceptionner le transfert d'une nouvelle version logicielle du développement aux tests indépendants.

Commentaire sur la séquence et le calendrier des niveaux de test Haut de la page

Traditionnellement, on pense que les tests unitaires sont 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. Toutefois, dans un processus de développement itératif, cette approche est inappropriée en règle générale. Une meilleure approche est d'identifier les tests unitaires, d'intégration et système qui présentent un plus grand potentiel de trouver des erreurs, puis de les implémenter et de les exécuter sur la base d'une combinaison du risque le plus grand et de l'environnement de soutien.



RUP (Rational Unified Process)   2003.06.15