Examiner les journaux de test
Objectif :
|
Enregistrer et comprendre le résultat des tests effectués.
|
Commencez par rassembler les sorties de journaux de tests obtenues pendant l'implémentation et l'exécution des tests.
Ces journaux peuvent provenir de nombreuses sources (enregistrements effectués par vos outils d'exécution de test et de
diagnostic, résultats de routines personnalisées développées par votre équipe ou résultats des éléments de test cible
eux-mêmes enregistrés par le testeur). Rassemblez toutes les sources de journaux de tests disponibles et examinez leur
contenu. Vérifiez que tous les tests planifiés ont été totalement exécutés et que tous les tests nécessitant d'être
planifiés l'ont été.
|
Enregistrer les données sur les incidents complexes
Objectif :
|
Enregistrer l'occurrence de tout événement anormal et complexe afin de procéder ultérieurement à une
investigation.
|
Il est important d'enregistrer toute occurrence anormale (même si vous ne pouvez ni la reproduire ni l'expliquer dans
l'immédiat) : en effet, des incidents ultérieurs présentant les mêmes symptômes peuvent apporter suffisamment
d'informations pour permettre d'isoler l'erreur correspondante.
Consignez autant de détails que vous pouvez mais indiquez que l'incident n'a pas pu être résolu.
|
Identifier les erreurs de procédure du test
Objectif :
|
Eliminer du journal des erreurs l'erreur humaine et les autres erreurs de procédure et de processus
survenues lors du déroulement du test.
|
Il arrive fréquemment que certaines erreurs proviennent d'erreurs survenues lors de l'implémentation du test ou lors de
la gestion de l'environnement de test. Identifiez et corrigez ces erreurs.
Si le test s'est terminé de façon anormale, empêchant l'exécution d'autres tests, vous devez peut-être reprendre son
exécution au niveau de l'échec et poursuivre ensuite l'exécution des autres tests.
|
Localiser et isoler les échecs
Objectif :
|
Identifier l'occurrence de l'échec, en éliminant de l'analyse des pannes les éléments de test cible qui ne
représentent pas la source de l'échec.
|
Plus vous effectuez de diagnostics d'échec, plus vous êtes susceptible d'identifier et de comprendre l'erreur.
Tentez d'isoler la défaillance en éliminant les éléments de test cible qui ne sont probablement pas concernés par
l'échec et recherchez les tendances et les caractéristiques figurant dans les autres éléments, dans l'état du système,
etc.
Effectuez une analyse de l'échec en reproduisant ce dernier dans des conditions de contrôle, si la panne ne peut pas
être identifiée efficacement sans être reproduite. Pour cela, utilisez en cas de besoin des outils de diagnostic et de
débogage.
|
Diagnostiquer les symptômes et les caractéristiques d'échec
Objectif :
|
Enregistrer une analyse de l'échec pour faciliter l'identification et la résolution des incidents.
|
Tentez de diagnostiquer l'erreur sous-jacente en vous appuyant sur votre expérience d'incidents similaires.
En cas de besoin, demandez de l'aide aux développeurs s'ils sont disponibles : ils connaissent bien le logiciel et
peuvent faire avancer l'analyse de l'échec.
|
Identifier les solutions possibles
Objectif :
|
Fournir à la personne responsable de la résolution des échecs une meilleure compréhension de la nature et
de l'impact de l'échec et aider le développeur en lui soumettant quelques pistes qu'il pourra
éventuellement suivre.
|
Voir Tâche : Déterminer les résultats de tests - Créer et gérer les demandes
de changement pour plus d'informations sur l'élaboration efficace de rapports d'incidents et de demandes de
changement.
|
Documenter les résultats de façon appropriée
Evaluer et vérifier vos résultats
Objectif :
|
Vérifier que la tâche a été correctement réalisée et que les produits qui en résultent 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 une coûteuse reprise. 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.
|
|