Tâche: Analyse des échecs de test
Cette tâche aide à localiser, isoler et diagnostiquer les échecs de test et à les documenter de façon efficace.
Objet

L'objectif de cette tâche est de :

  • Examiner les détails du journal de test et analyser les échecs survenus pendant l'implémentation et l'exécution d'un test
  • Corriger les échecs résultant d'erreurs lors de la procédure de test
  • Enregistrer les éléments importants de façon appropriée
Relations
Etapes
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
Objectif :  Présenter votre analyse de la défaillance de façon appropriée à la personne chargée de résoudre la défaillance. 

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.

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.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations