Rapport d’état des tests de logiciels
« L’accord selon lequel une certaine information, dans un certain format, sera envoyée par une certaine équipe / personne, à certains intervalles de temps, à certains membres – est comme une poignée de main – une reconnaissance que peu importe le résultat d’une tâche à accomplir, vous seriez tenu informé à ce sujet, plus tôt que tard. »
Ceci est la première section du serment d’un professionnel de l’informatique. Eh bien, je plaisante! Il n’y a pas de serment, mais s’il y en avait un, cela figurerait sûrement en tête de liste. N’est-ce pas?
La responsabilité et la transparence (A & T) sont essentielles à chaque projet informatique à différents niveaux – Niveau du projet, niveau de l’équipe, niveau des tâches et également niveau individuel. Comment pouvons-nous nous assurer que ces attributs sont respectés? La réponse est – communiquer, plus formellement – des rapports d’état!
Au niveau individuel, n’envoyons-nous pas tous des rapports, la plupart du temps, EOD tous les jours pour communiquer l’accomplissement (ou le non-accomplissement) de vos tâches quotidiennes. Cela prouve que vous êtes réellement « conscient » de vos tâches au départ.
Rapport de Situation quotidien
L’information qui doit faire partie du » Rapport de situation quotidien » d’une personne est:
- Qu’as-tu fait aujourd’hui ?
- Que comptez-vous faire demain ?
- Avez-vous rencontré des problèmes pendant votre journée? Si oui, comment les avez-vous résolus ou sont-ils toujours ouverts?
- Avez-vous besoin d’entrées pour demain? Si oui, de qui et de quoi sont-ils ?
Le destinataire de cet e-mail / rapport est généralement le responsable, les membres de l’équipe peuvent également être contactés dans certains cas – cela dépend du protocole de communication suivi par l’équipe.
Rapports de test
Maintenant, il est temps d’être précis et de tout savoir sur les rapports envoyés par les équipes de test / assurance qualité.
Les équipes de test envoient divers rapports à différentes phases du STLC.
- État du plan de test
- État de la Documentation de test
- État de l’exécution du test (État du défaut)
Plan de test : Il suffit de communiquer avec le reste des équipes projet, lorsqu’un plan de test est créé ou lorsqu’un changement majeur y est apporté.
Documentation de test: Informez toutes les équipes quand la conception des tests, la collecte de données et d’autres activités ont commencé et aussi quand elles sont terminées. Ce rapport leur informera non seulement de l’avancement de la tâche, mais signalera également aux équipes qui doivent examiner et approuver les artefacts, qu’elles sont les prochaines.
Exécution du test: L’exécution est la phase d’un projet où l’équipe de test est la principale cible – positivement et négativement – nous sommes à la fois les héros et les méchants.
Une journée type au cours d’un cycle d’essai n’est effectuée que si le Rapport d’état quotidien est envoyé. Dans certaines équipes, ils pourraient s’entendre sur un rapport hebdomadaire, mais le faire envoyer quotidiennement est la norme.
Il n’est pas rare non plus d’avoir une réunion de statut tous les jours (ou toutes les semaines) pour présenter le statut de l’équipe d’assurance qualité aux parties concernées.
Par conséquent, le mode d’un rapport d’état peut être:
- E-mail / document
- Réunion / présentation
- Les deux – e-mail quotidien et réunion hebdomadaire ou plus.
Rapport d’état d’exécution du test
Rapport d’exécution du Test quotidien / hebdomadaire:
Qu’est-ce que c’est? Généralement, il s’agit d’une communication envoyée pour établir la transparence des activités de l’équipe d’assurance qualité du jour pendant le cycle de test – comprend à la fois des informations sur les défauts et des informations sur l’exécution du scénario de test.
À qui devrait-il s’adresser ? – Normalement, l’équipe de développement, l’équipe de soutien à l’environnement, l’Analyste commercial et l’équipe de projet sont les bénéficiaires / participants à la réunion. Le Plan de test est le meilleur endroit pour trouver ces informations.
Que contient un Rapport d’état d’exécution de test ? – 10 points
- Nombre de cas de test prévus ce jour–là
- Nombre de cas de Test exécutés – ce jour–là
- Nombre de cas de Test exécutés globalement
- Nombre de Défauts rencontrés ce jour–là / et leurs états respectifs
- Nombre de Défauts rencontrés jusqu’à présent / et leurs états respectifs
- Nombre de Défauts critiques – toujours ouvert
- Temps d’arrêt de l’environnement – le cas échéant
- Showstoppers – le cas échéant
- Attachement de la feuille d’exécution du test/Lien à l’outil de gestion des tests où les cas de test sont placés
- Attachement au rapport de bogue / lien vers l’outil de défaut / Test / gestion utilisé pour la gestion des incidents
Les 10 points ci-dessus, si vous remarquez de près, sont les données brutes. Signaler les faits est une chose et signaler certains faits « intelligents » en est une autre. Comment affiner ces informations ?
- Affiche l’état général avec un indicateur de couleur. Par exemple, Vert – à l’heure, Orange – Légèrement en retard mais peut absorber le retard, Rouge – Retardé.
- Inclure quelques métriques simples comme le pourcentage de réussite des cas de test jusqu’à présent, la densité des défauts, le % des défauts graves; en faisant cela, vous ne vous contentez pas de donner des chiffres, vous donnez en fait un aperçu de la qualité du produit que vous testez.
- Si une phase significative est terminée, mettez cela en surbrillance.
- S’il y a un défaut critique qui va bloquer tout / une partie de l’exécution future, mettez-le en évidence.
- Si vous utilisez une présentation, assurez-vous d’inclure des graphiques pour avoir un meilleur impact.
Par exemple, le graphique ci-dessous est une représentation du nombre de défauts ouverts, par module:
En dehors de ceux-ci, vous pouvez également inclure en option:
- Quelles sont les activités prévues ensuite ?
- Avez-vous besoin des contributions des autres équipes et si oui, quoi?
Enfin, quelques conseils pour aider le processus:
- Soyez concis en même temps complétez
- Assurez-vous que les résultats que vous rapportez sont exacts
- Utilisez des points à puces pour rendre le rapport très lisible
- Vérifiez à nouveau pour inclure la bonne date, le sujet, la liste et les pièces jointes.
- Si le rapport est trop volumineux et comporte trop de facteurs à signaler: placez-le dans un emplacement commun en tant que fichier et envoyez un lien dans l’e-mail au lieu du fichier lui-même. (Assurez–vous que les destinataires disposent des autorisations d’accès à cet emplacement et au fichier)
- S’il s’agit d’une réunion d’état – Préparez-vous à la présentation, arrivez à l’heure et, surtout, maintenez un ton uniforme (ne soyez pas trop fier des défauts – ce sont en général des « mauvaises nouvelles »).
Rapport d’état de l’échantillon
Rapport d’état des tests d’Assurance qualité:
En suivant ces directives, nous sommes arrivés au rapport de situation ci-dessous.
Pour la commodité de nos lecteurs, nous avons inclus 3 feuilles transmettant différents niveaux d’informations qu’ils peuvent transmettre.
Feuille 1 – est un résumé de l’état général du projet.
Feuille 2 – est plus sur le détail individuel de l’état du cas de test.
Feuille 3 – est un exemple de rapport de bogue.
Téléchargez cet exemple de modèle Xls de Rapport d’état avec les trois feuilles. (Cliquez avec le bouton droit sur le lien et sélectionnez « Enregistrer le lien sous..’à télécharger)
À propos de l’auteur – Il s’agit d’un article de Swati Seela, membre de l’équipe STH. Vous pouvez en savoir plus sur elle sur notre page de cours de test de logiciels.
