Examiner l'architecture du logiciel et ses environnements cibles
Objectif :
|
Mieux comprendre l'architecture du logiciel et ses relations avec les environnements de déploiement
cible.
|
Pour réaliser cette tâche dans le contexte approprié, il est important de bien comprendre le logiciel développé, son
architecture ainsi que les mécanismes et fonctions clés dont il assurera le support. Examinez la documentation
disponible sur l'architecture du logiciel pour vous familiariser avec ce dernier et complétez ces connaissances en
interrogeant l'architecte du logiciel, en cas de besoin. Tenez compte de l'impact que chaque environnement de
déploiement cible peut avoir sur ces informations et notez toutes les données importantes qui vous semblent concerner
l'effort de test.
|
Identifier les mécanismes potentiels applicables aux tests
Objectif :
|
Identifier les mécanismes potentiels requis par l'approche de test.
|
En prenant comme base votre connaissance de l'architecture du logiciel et de ses environnements cible, examinez les
informations fournies par l'approche de test. Etudiez les principaux aspects techniques de l'approche et dressez la
liste des mécanismes potentiels qui seront requis. Voici une liste partielle de mécanismes que vous devez considérer
comme potentiels : persistance, simultanéité, distribution, communication, sécurité, gestion des transactions, reprise,
gestion de la détection des erreurs, synchronisation du contrôle de processus.
Il est à noter que ces mécanismes s'appliquent souvent à la fois aux efforts de test manuels et automatisés, bien que
certains soient plus particulièrement adaptés à l'un ou l'autre de ces modes de test. Notez également que lorsqu'un
même mécanisme est requis à la fois pour les efforts de tests manuels et automatisés, les caractéristiques de la
solution implémentée diffèrent généralement.
|
Dresser l'inventaire des mécanismes de test existants
Objectif :
|
Identifier les opportunités de réutilisation des implémentations existantes pour les mécanismes potentiels
et identifier les autres implémentations à développer.
|
Examinez les outils de test disponibles et les implémentations de test existantes, puis dressez l'inventaire des
mécanismes disposant d'une ou de plusieurs solutions. Cette étape s'adapte tout particulièrement à l'effort de tests
automatisés, mais elle peut également concerner l'effort de tests manuels.
Sous-rubriques :
Commencez par dresser la liste des outils dont vous disposez ou que vous envisagez d'acheter. Souvenez-vous que les
outils d'automatisation se présentent sous un grand nombre de formes différentes et que votre liste inclut généralement
d'autres outils que les outils d'implémentation et d'exécution de tests automatisés. Pour chaque outil, examinez les
mécanismes fournis. Par exemple, l'outil de génération de scripts que vous envisagez d'utiliser contient-il son propre
mécanisme de persistance des données, et si oui est-il adapté à vos besoins (ou au contraire devrez-vous le compléter)
? D'autres questions peuvent se poser : l'outil d'exécution autorise-t-il l'exécution simultanée de scripts de test sur
plusieurs clients hôtes ? L'outil d'exécution autorise-t-il la distribution de scripts à partir d'une machine centrale
vers plusieurs clients hôtes ?
Lorsque des implémentations d'automatisation de tests sont disponibles, des mécanismes supplémentaires viennent
s'ajouter à l'inventaire. Certains aspects de ces implémentations viendront compléter les mécanismes de base fournis
par les outils pour les rendre plus pratiques. D'autres aspects offriront des implémentations pour des mécanismes
autres que ceux fournis dans l'outil de base.
Cela implique de revoir les instructions applicables à l'implémentation et à l'exécution de tests. Vous devez
rechercher les solutions existantes pour les thèmes tels que la simultanéité (partage des données par les testeurs et
tout spécialement des données qui n'ont pas d'incidence mutuelle négative), la répartition (répartition ou non de
l'équipe de test à plusieurs emplacements, solutions de coordination des efforts de test).
|
Définir les mécanismes de test à utiliser
Objectif :
|
Communiquer les décisions prises au sujet des mécanismes de test requis.
|
Maintenant que vous avez déterminé les mécanismes de test requis, vous devez communiquer vos choix à l'équipe de test
et aux autres parties prenantes participant à l'effort de test. Il est recommandé d'expliciter les décisions prises sur
les mécanismes de test requis dans la documentation consacrée à l'architecture de l'automatisation des tests et celles
relatives aux tests manuels dans les recommandations de test.
Vous pouvez également choisir d'enregistrer ces informations sous la forme d'une architecture informelle et de notes de
processus accompagnées de quelques diagrammes explicatifs (éventuellement sur tableau). Pendant l'implémentation et
l'exécution des tests, les testeurs utilisent ces informations pour leurs prises de décisions tactiques.
Une fois que vous avez identifié les exigences potentielles des interfaces de test qui devront être intégrées au
logiciel en cours de développement, vous devez enregistrer ces informations via la création d'une ou de plusieurs
spécifications d'interface de test, et y associer un nom, une brève description ainsi que les 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 éléments de testabilité.
|
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.
|
|