Tâche: Détermination des résultats du test
Cette tâche décrit comment enregistrer précisément les résultats de test et quel type de suivi est nécessaire.
Objet

L'objet de cette tâche est de :

  • Effectuer des évaluations sommaires continues de la qualité perçue du produit
  • Identifier et enregistrer les résultats détaillés de tests
  • Proposer des actions correctives appropriées afin de résoudre les échecs de qualité
Relations
Etapes
Examen de tous les incidents et échecs de tests
Objet :  Rechercher chaque incident et les informations détaillées correspondantes pour comprendre les problèmes qui en découlent. 

Dans cette tâche, les journaux de test sont analysés afin de déterminer les résultats de test pertinents en ce qui concerne les différences entre les résultats escomptés et les résultats réels de chaque test. Pour cela, vous devez identifier et analyser chaque incident et chaque échec. Pour chacun d'entre eux, consultez toutes les informations possibles.

Recherchez les incidents en double, les symptômes communs et les relations entre les différents incidents. Cela permet souvent de retrouver la cause à l'origine de plusieurs incidents.

Création et maintenance des demandes de changement
Objet :  Entrer des informations de demande de changement dans un outil de suivi à des fins d'évaluation, de gestion et de résolution d'incidents. 

Les différences relevées indiquent des défauts potentiels dans les éléments de test cible et doivent être entrées dans un système de suivi sous la forme d'incidents ou de demandes de changement, avec mention des actions correctives à exécuter.

Sous-rubriques :

Vérification des faits relatifs aux incidents Début de page

Vérifiez que des données précises sont disponibles. Rassemblez ces informations et rattachez-les directement aux demandes de changement ou indiquez où elles peuvent être obtenues.

Chaque fois que vous le pouvez, vérifiez si le problème risque de se reproduire. Les problèmes qui risquent de se reproduire attirent l'attention des développeurs et ont donc plus de chances d'être résolus. En revanche, un problème isolé frustre l'équipe de développement et gaspille de précieuses ressources de programmation dans des recherches stériles. Il est conseillé de consigner ces incidents malgré tout, mais de bien marquer la différence entre les incidents qui risquent de se reproduire et les autres.

Clarification des détails des demandes de changement Début de page

Il est important que les demandes de changement soient claires, et tout particulièrement leur titre. Assurez-vous que le titre est concis et qu'il présente clairement le thème traité. Un titre bref facilite la lecture des listes récapitulatives de défauts et les discussions au cours des réunions sur l'état d'avancement CCB.

Il est également important que la description détaillée de la demande de changement ne comporte aucune ambiguïté et puisse être facilement interprétée. Consignez les demandes de changement dès que possible, mais prenez le temps d'y revenir et d'apporter des améliorations aux descriptions avant que celles-ci ne soient consultées par l'équipe de développement.

Indiquez le plus grand nombre possible de solutions potentielles. Si une ambiguïté figurait encore dans la description, cela permet de l'éclaircir. Cela augmente également la probabilité d'une solution proche de vos indications. Par ailleurs, cela illustre le fait que l'équipe de test n'a pas uniquement pour but de détecter les incidents, mais également d'identifier les solutions appropriées.

Vous pouvez inclure des captures d'écrans, des fichiers de données de test, des scripts de tests automatisés, des résultats d'utilitaires de diagnostic et toute autre information susceptible d'aider les développeurs à isoler et à corriger le problème.

Indication du niveau de gravité relatif de l'impact et la priorité de la résolution Début de page

Fournissez à l'équipe de gestion et à l'équipe de développement une indication du niveau de gravité de l'incident. Dans les très grandes équipes, la priorité de résolution est généralement laissée à l'appréciation de l'équipe de gestion. Toutefois, vous pouvez autoriser d'autres personnes à indiquer la priorité de résolution qu'ils souhaitent et en tenir compte par la suite. En règle générale, il est recommandé d'affecter par défaut aux demandes de changement une priorité de résolution moyenne, puis d'augmenter ou de diminuer cette valeur au cas par cas, selon les besoins.

Il se peut que vous ayez besoin de faire la distinction entre l'impact qu'aura la demande de changement sur l'environnement de production et l'impact qu'elle aura sur l'effort de test si elle n'est prise en compte ; l'équipe de gestion a tout autant besoin de connaître l'impact d'un incident sur l'effort de test que d'avoir conscience de la gravité pour les utilisateurs.

Il est parfois difficile de comprendre à l'avance pour quelles raisons vous avez besoin de ces deux informations. Il peut arriver qu'un incident soit réellement grave (comme dans le cas d'une panne système par exemple), mais que les actions à entreprendre soient peu susceptibles de se reproduire. Dans ce cas, l'équipe peut indiquer un niveau de gravité élevé tout en affectant une priorité de résolution très faible.

Consigne séparée des autres demandes de changement

Les incidents sont souvent l'occasion de mentionner le vieil adage selon lequel "Il n'y a pas de fumée sans feu" : lorsque vous identifiez et consignez une demande de changement, il arrive souvent que d'autres questions se présentent. Ne cédez pas à la tentation d'ajouter tout simplement ces dernières à la demande de changement en cours : si elles sont directement liées et facilitent la résolution de l'incident en cours de traitement, cela ne posera pas de problème, mais si elles ne sont pas liées, le fait de les mentionner dans une demande de changement existante risque de poser certains problèmes (non déclenchement de leur traitement, absence d'affectation de la priorité requise, voire impact sur la vitesse de traitement d'autres incidents).

Analyse et évaluation du statut
Objet :  Calculer et distribuer les mesures clés et les indicateurs de test. 

Sous-rubriques :

Distribution des incidents

Analysez les incidents sur la base de leur emplacement de distribution (domaine fonctionnel, risque qualité, testeur et développeur affectés).

Recherchez les types de distribution (comme par exemple les domaines fonctionnels comptabilisant plus d'incidents que la moyenne). Recherchez également les développeurs et les testeurs dont la charge de travail est trop élevée et dont la qualité du travail risque de diminuer

Taux de couverture d'exécution des tests

Pour évaluer le taux de couverture d'exécution des tests, vous devez examiner les journaux de test et déterminer les éléments suivants :

  • La différence entre le nombre de tests (scripts ou cas de test) ayant été exécutés au cours de ce cycle de tests et le nombre total de tests effectués pour tous les éléments de test cible.
  • Le pourcentage de cas de test exécutés avec succès.

L'objectif consiste à vérifier qu'un nombre suffisant de tests de ce cycle de tests a été exécuté avec succès. Si cela n'est pas possible (ou si vous souhaitez augmenter les données d'exécution), vous pouvez identifier d'autres critères de couverture de test sur la base suivante :

  • Risque qualité ou priorité
  • Taux de couverture en fonction des exigences
  • Besoin métier ou priorité
  • Taux de couverture en fonction du code

Voir Concept : Mesures clés de test et taux de couverture de test en fonction des exigences.

Enregistrez et présentez les résultats de test dans un rapport d'évaluation de test pour ce cycle de tests.

Statistiques relatives aux demandes de changement

Pour analyser les incidents, vous devez revoir et analyser les mesures choisies dans le cadre de votre stratégie d'analyse d'incidents. Les mesures les plus utilisées sont les suivantes (elles sont souvent présentées sous la forme d'un graphique) :

  • Densité d'incident - le nombre d'incidents est représenté sous la forme d'une fonction à un ou deux attributs d'incidents (telle que la distribution sur la zone fonctionnelle ou le risque de qualité en comparaison avec le statut ou la gravité).
  • Tendance d'incidents - le nombre d'incidents est représenté sous la forme d'une fonction sur une période donnée.
  • Présentation chronologique des incidents - rapport spécifique de densité des incidents, dans lequel le nombre d'incidents est représenté sous forme de fonction illustrant la période au cours de laquelle un incident a conservé un état spécifique (ouvert, nouveau, en attente de vérification, etc.)

Comparez les mesures applicables à ce cycle de tests aux totaux de l'itération en cours et à celles issues de l'analyse des itérations précédentes, afin de mieux comprendre les tendances qui se font progressivement jour.

Il est recommandé de présenter les résultats sous forme de diagramme.

Evaluation de l'expérience de la qualité actuelle
Objet :  Fournir des appréciations en retour sur la qualité actuelle (perçue ou résultant de tests) du produit logiciel. 

Elaborez une synthèse sur la qualité en soulignant les bons et les mauvais aspects de la qualité des produits logiciels.

Evaluation des risques de qualité notables
Objet :  Fournir des appréciations en retour sur les zones à risque qui, potentiellement, exposent le plus le projet. 

Identifiez et présentez ces zones qui n'ont pas été traitées en termes de risque qualité et indiquez le niveau d'impact et d'exposition pour l'équipe.

Indiquez la priorité de chaque risque qualité et utilisez cette priorité pour mentionner l'ordre dans lequel ces questions doivent être traitées.

Evaluation du taux de couverture de test
Objet :  Elaborer une synthèse de l'évaluation de l'analyse du taux de couverture. 

En vous basant sur les tâches de l'étape décrivant le taux de couverture de l'exécution, élaborez une synthèse rappelant brièvement le statut et les informations que les données représentent.

Ebauche de la synthèse de l'évaluation de test
Objet :  Communiquer les résultats des tests aux parties prenantes et évaluer objectivement la qualité et l'état des tests. 

Présentez les résultats des tests pour ce cycle sous forme de synthèse d'évaluation de test. Cette étape a pour but de développer l'ébauche initiale de la synthèse. Pour cela, rassemblez les informations recueillies précédemment en un rapport récapitulatif. En fonction des parties prenantes et du contexte du projet, le format et le contenu de cette synthèse peuvent varier.

Il est conseillé de distribuer l'ébauche initiale à quelques personnes afin d'obtenir leur appréciation, ce qui vous permettra d'affiner la synthèse avant de la distribuer à un public plus large.

Indication des principaux résultats aux parties prenantes
Objet :  Promouvoir et publier la synthèse d'évaluation. 

Publiez ces informations de la manière la plus appropriée. Il est recommandé de publier la synthèse sur un site centralisé ou de la présenter lors de réunions sur l'état d'avancement, afin de recueillir les appréciations et de déterminer les actions à entreprendre.

Gardez présent à l'esprit que la publication de synthèses d'évaluation n'est politiquement pas neutre. Négociez avec le responsable du développement afin de présenter les résultats de telle sorte qu'ils reflètent une approche honnête et précise des informations recueillies, tout en respectant le travail des développeurs.

Evaluation et vérification de vos résultats
Objet :  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 déterminer si votre travail est d'une qualité correcte et s'il est suffisamment complet pour que les membres de l'équipe puissent l'utiliser comme entrée pour leur propre travail. A chaque fois que cela est possible, utilisez les listes de contrôle fournies dans le processus RUP pour vérifier que la qualité et l'achèvement sont "suffisamment bons".

Faites en sorte que les personnes qui effectuent des tâches en aval qui se basent sur votre travail en tant qu'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 processus RUP est un processus itératif de livraison et que, dans la plupart des cas, les produits évoluent avec le temps. A ce titre, il n'est pas habituellement nécessaire, et c'est même souvent contre-productif, de concevoir complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Cela vient du fait 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 une perte d'efforts et un retravail 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 livrable de projet, vous pouvez envisager d'utiliser une ressource d'administration 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