Les bilans: la vitrine des tests!

Voici un article qui me semble important à écrire et qui est dans la continuité de mes articles sur la conception, l’écriture, l’exécution seule et l’analyse des tests.

Les bilans sont un livrable de test particulièrement important car les bilans c’est :

·        Le résumé d’une campagne de test

·        Le livrable le plus visible

·        Le livrable le plus lu

·        Le livrable le plus attendu

Autant dire qu’un mauvais bilan (ou bilan mal présenté) peut rendre une campagne parfaitement maîtrisée et pensée (en terme de couvertures, de stratégies, de qualités des tests et des environnements) totalement vain car inutilisable (ou inutilisé).

Pour être lu compris et utilisé un bilan doit :

·        Avoir une hiérarchie de l’information : de la plus importante à la moins importante

·        Contenir toutes les informations souhaitées par les personnes participant au projet (Chef de projet, testeur, développeur, AMOA, experts fonctionnel…)

·        Être clair : au premier coup d’œil on doit connaitre le résultat de la campagne

·        Être accessible : un bilan est fait pour être vu, n’importe quel membre du projet donc doit y avoir accès facilement (lieu de stockage, mail…)

Il n’y a donc pas de bilan magique qui fonctionne partout.

Par contre il est possible d’avoir un « squelette » adaptable. Voici le mien (ce type de bilan peut également être utilisé en dehors des tests) :

==============================================================

Bilan Campagne [Produit] [type de campagne] [date]

______________________________________________________________________

[GO – NO GO]

______________________________________________________________________

Principaux résultats – Résumé

0

Fonctionnalités en échec : [liste des fonctionnalités avec au moins 1 bug]

Principaux bugs : [Liste bug critiques et majeurs : ID et titre]

______________________________________________________________________

Résultats complets

[Résultats par fonctionnalité]

[Ensemble des bugs]

==============================================================

Pour finir:

Il ne faut jamais oublier que le but des tests c’est d’apporter de la visibilité sur la qualité de l’application. Le bilan est la vitrine de ces tests. Pas besoin d’insister sur le fait que lorsque son travail c’est d’apporter de la visibilité, on a intérêt à avoir une bonne vitrine !

N’hésitez pas à rejoindre le groupe Le métier du test

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

culture générale

[Programmez!] Un jeu pour le test logiciel ?

Les jeux sont présents presque partout, à tout moment de notre vie mais aussi dans le monde animal où ce dernier sert à mesurer et à établir un ordre établi. Cette présence montre un intérêt au-delà de l’amusement lié à cette activité. S’il est un endroit où les jeux ne

Lire la suite »
équipe

Ice Breaker: le chasseur de bug

Cet article fait suite à une expérience récente que j’ai eue dans une équipe agile . En fait, tout est parti d’une discussion sur un logo et cela a terminé avec cette question: Quelle est la première image qui te vient quand je te dis « Chasseur de bug » ? Et

Lire la suite »
Bug

Le Paradoxe des pesticides

Définition : Le paradoxe des pesticides n’est pas exclusif aux tests. En fait il a même été « récupéré » par le test car à l’origine c’est un paradoxe qui nous vient du monde agricole. Ce paradoxe est assez simple : plus on utilise de pesticides, plus on doit en utiliser car les « mauvaises

Lire la suite »