Déterminer le logiciel à implémenter
Objectif :
|
Comprendre les principaux éléments livrables de l'équipe de développement dans le planning suivant.
|
A l'aide du plan d'itération et d'autres sources disponibles, identifiez les éléments logiciels que l'équipe de
développement envisage de générer pour la prochaine itération. Lorsque l'effort de développement est réparti entre
plusieurs équipes situées à des emplacements différents, cela vous impose peut-être de discuter directement des plans
de développement avec chaque équipe. Vérifiez si le développement est sous-traité et utilisez les canaux disponibles
pour rassembler les informations relatives au développement réalisé par les sous-traitants.
Comme pour les nouveaux logiciels, relevez également les modifications apportées à l'infrastructure et aux composants
partagés. Ces modifications peuvent affecter d'autres éléments logiciels dépendants ou associés développés au cours de
cycles antérieurs, ce qui impose de tester l'effet de ces modifications sur ces éléments. Pour des raisons similaires,
vous devez identifier toutes les modifications et tous les ajouts à des composants tiers que l'effort de développement
envisage d'utiliser. Cela inclut les composants partagés, les bibliothèques, les gadgets d'interfaces graphiques, les
utilitaires de persistance, etc. Révisez l'architecture logicielle afin de déterminer le mécanisme en cours
d'utilisation susceptible d'être affecté par les modifications apportées au composant tiers.
|
Identifier les éléments individuels du système à tester
Objectif :
|
Identifier les éléments cible concernés par l'effort de test.
|
Pour chaque motivation de test identifiée, examinez la liste des éléments logiciels à livrer au cours de ce cycle de
développement. Dressez une liste initiale excluant les éléments qui ne peuvent pas être justifiés comme utiles en
termes de satisfaction des motivations de test. Veillez à inclure les logiciels commercialisés disponibles, ainsi que
ceux qui seront développés directement par l'équipe de développement du projet.
Vous devrez également évaluer l'impact des différents environnements de déploiement cible sur les éléments à tester.
Votre liste des éléments système potentiels doit inclure les logiciels développés et les éléments potentiels de
l'environnement cible. Ces éléments comprennent les unités matérielles, les logiciels de pilotes de périphériques, les
systèmes d'exploitation, les logiciels de réseaux et communications, les composants de base de logiciels tiers (clients
de messagerie électronique, navigateurs, par exemple),. Ils comprennent également plusieurs configurations et
paramètres liés aux combinaisons possibles de tous ces éléments.
Une fois que vous avez identifié les environnements de déploiement cible importants, vous devez enregistrer ces
informations via la création ou la mise à jour d'une ou de plusieurs configurations d'environnement de test ; vous
devez attribuer à cette configuration un nom, une description brève, et énumérer ses principales exigences ou
caractéristiques. Evitez d'y passer trop de temps ; la liste des exigences et des caractéristiques sera détaillée
ultérieurement dans Tâche : Définir les configurations des environnements de test.
|
Définir la liste potentielle des éléments cibles
Objectif :
|
Eliminer les cibles inutiles du plan de travail de l'effort de test et y ajouter les éléments
manquants.
|
Une fois un accord obtenu auprès des parties prenantes quant à la mission d'évaluation et à l'étendue de l'effort de
test, examinez la liste des éléments cible et identifiez ceux qui ne permettent pas de réussir la mission d'évaluation
et qui se trouvent manifestement hors du champ de l'effort de test.
Effectuez un nouveau contrôle en examinant de nouveau les éléments et en déterminant si la mission d'évaluation et
l'étendue de l'effort de test pourront réellement être atteints par les éléments cible figurant dans la liste révisée.
Vous devrez peut-être ajouter des éléments supplémentaires à la liste des éléments cible afin de parvenir à une étendue
appropriée et au succès de la mission d'évaluation.
|
Définir la liste des éléments cibles
Objectif :
|
Communiquer les décisions prises au sujet des éléments de test cible en vue du prochain travail.
|
Maintenant que vous avez déterminé les éléments de test cible, vous devez communiquer vos choix à l'équipe de test et
aux autres parties prenantes participant à l'effort de test. Pour cela, le plus simple consiste à documenter les
décisions prises au sujet des éléments cible dans le plan de test de l'itération.
Vous pouvez également enregistrer ces informations dans un tableau ou dans une feuille de calcul, puis les utiliser
pour l'affectation du travail et des responsabilités. Pendant l'implémentation et l'exécution des tests, les testeurs
utilisent ces informations pour prendre des décisions tactiques sur les tests à implémenter et sur les résultats de
tests à enregistrer pour ces éléments cible.
|
Evaluer et vérifier vos résultats
Objectif :
|
Vérifier que la tâche a été correctement réalisée et que les produits en résultant sont acceptables.
|
Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que
vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez évaluer si votre travail est d'une
qualité correcte et qu'il est assez complet pour être utile aux membres de l'équipe qui en feront un usage ultérieur
comme entrée pour leur propre travail. Si possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que
la qualité et l'exhaustivité sont "satisfaisantes".
Faites en sorte que les personnes qui effectuent les tâches en aval, et qui se basent sur votre travail comme entrée,
prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps
disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail
par rapport aux produits d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il
peut être utile que l'auteur du produit d'entrée revoie votre travail sur cette base.
Essayez de vous rappeler que le RUP est un processus de livraison itératif et que dans de nombreux cas, les produits
évoluent au fil du temps. A ce titre, il n'est généralement pas nécessaire - et c'est même souvent contre-productif -
de former complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat.
Ceci parce qu'il y a une grande probabilité pour que la situation qui entoure le produit change - et que les hypothèses
émises lors de la création du produit s'avèrent incorrectes - avant même l'utilisation du produit, occasionnant ainsi
une perte d'efforts et un remaniement coûteux. Evitez également le piège consistant à utiliser trop de cycles pour la
présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une
importance et une valeur économique en tant que résultat d'un projet, vous pouvez envisager d'utiliser une ressource
administrative pour réaliser les tâches de présentation.
|
|