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.
|