Le logiciel est amélioré à travers les itérations du cycle de vie de développement logiciel RUP. Il est avantageux pour
le cycle de vie du test de suivre une approche itérative équivalente dans cet environnement de processus. Dans chaque
itération, l'équipe de développement logiciel produit une ou plusieurs versions, chaque version étant potentiellement
candidate au test.
Le centre d'attention et les objectifs de l'équipe de développement varient d'une itération à l'autre. Ainsi, les
membres de l'équipe de test doivent structurer leur effort de test en conséquence. Nous vous suggérons de limiter au
minimum la quantité de travail de planification et de conception de tests détaillés en amont et, lorsque ces tests sont
nécessaires, de faire en sorte de produire ce travail le plus près possible du moment où il sera utilisé. Nous vous
recommandons également de traiter le développement des tests détaillés en amont pas plus d'une itération à l'avance.
Les additions, améliorations et suppressions sont apportées aux tests qui sont implémentés et exécutés pour chaque
version. Certains de ces tests sont retenus et s'accumulent dans un ensemble de tests; ils sont utilisés pour des tests
de régression des versions suivantes utilisées dans chaque cycle de vie futur. Cette approche retravaille et révise les
tests tout au long du processus, tout comme le logiciel est lui-même révisé. Aucune spécification logicielle n'est
gelée et aucun test n'est gelé. La figure suivante illustre comment les tests évoluent dans le temps.
Cette approche itérative, associée à l'utilisation d'architectures de composants, nécessite que vous envisagiez le test
des régressions dans la qualité du produit dans chaque version suivante. Tous les tests développés dans l'itération X
sont des candidats potentiels aux tests de régression dans l'itération X+1, et dans l'itération X+2, etc. Lorsque le
même test est susceptible d'être répété plusieurs fois, cela vaut la peine d'envisager son automatisation.
L'automatisation des tests fournit une approche aux tests répétés des scénarios d'utilisation et évite au personnel
chargé des tests d'explorer les tests dans de nouveaux domaines fonctionnels.
Regardons le cycle de vie du test sans considérer le reste du projet. La figure suivante décompose en détails le
travail de la discipline de test dans une itération donnée.
Ce cycle de vie s'aligne sur le cycle de l'itération que le reste de l'équipe de développement suit. L'itération
commence par une investigation par l'équipe de test, qui négocie avec le responsable du projet et les autres parties
prenantes le travail de test le plus utile à entreprendre pour l'itération suivante. La plupart des membres de l'équipe
de test jouent un rôle dans cet effort de travail.
Chaque itération contient généralement au moins un cycle de test, comme indiqué dans la figure suivante. Il s'agit
d'une pratique relativement courante pour plusieurs versions à produire pour chaque itération et pour un cycle de test
à aligner avec chaque version. Toutefois, des versions spécifiques ne sont pas testées dans certains cas.
L'effort de test principal en cours, un sous-ensemble de membres de l'équipe peut étudier de nouvelles techniques de
test. Cet effort tente de prouver que les techniques fonctionnent et que l'équipe peut donc leur faire confiance,
notamment dans les itérations suivantes.
Le cycle de vie du test fait partie du cycle de vie du logiciel ; les deux doivent commencer au même moment. Le
processus de conception et de développement des tests peut être aussi complexe et ardu que le processus de
développement du produit logiciel lui-même. Si le début des tests n'est pas aligné avec la production des premiers
logiciels exécutables, l'effort de test retardera la découverte de beaucoup trop de problèmes jusqu'à tard dans le
cycle de développement. Cela oblige souvent à prévoir une longue période de débogage qui vient s'ajouter à la fin du
calendrier de développement, qui fait échouer les objectifs et élimine les avantages du développement itératif.
Bien que des activités de planification du test et de définition des tâches commencées tôt puissent exposer
d'importantes anomalies au début du travail de spécification, nous vous recommandons de choisir attentivement le
travail de test que vous réalisez à l'avance. En plus de l'éventuel besoin de retravailler les tests, que nous avons
déjà mentionné, l'équipe de test doit veiller à conserver son rôle de conseiller qualité impartial, et à ne pas
s'écarter des premières tâches de conception et de définition des exigences en agissant comme une "police qualité". Par
définition, les premières tentatives de l'équipe du projet visant à comprendre les problèmes et les possibilités de
solutions échoueront. En formulant des exigences non raisonnables sur la qualité de ce premier travail, l'équipe de
test risque d'être rejetée du reste du groupe de développement.
Les problèmes trouvés pendant une itération peuvent être résolus dans la même itération ou reportés à la prochaine ;
une décision qui revient finalement au responsable du projet. L'une des principales tâches de l'équipe de test et des
responsables du projet est de mesurer l'état d'achèvement de l'itération en vérifiant que les objectifs de l'itération,
tels que présentés dans le plan d'itération, sont atteints. "L'identification des exigences" est un processus
permanent, d'itération en itération. C'est quelque chose que vous devez savoir et être prêt à gérer.
Votre façon d'exécuter les tests dépend de plusieurs facteurs :
-
le domaine de votre application
-
votre budget
-
la politique de votre entreprise
-
votre tolérance aux risques
-
votre personnel
Le montant investi dans les tests dépend de votre façon d'évaluer la qualité et de votre tolérance aux risques dans
votre propre environnement.
|