Comment signaler les anomalies au responsable du développement - qui est également votre responsable

Dans certaines organisations, les testeurs de logiciels rapportent directement au responsable du développement. Ça n'est pas une situation idéale pour d'évidentes raisons, mais c'est une autre discussion.

Je discute ici de la manière de signaler les anomalies à la personne qui a probablement rédigée une partie du code ou à la personne qui est responsable des développements... et à qui vous rapportez personnellement.

Faisant partie du processus de test, vous devriez:

• Prédéfinir des critères de sévérité et de priorité, avec la définition de chaque valeur
• Obtenir l'accord de votre responsable pour ces définitions
• Utiliser ces définitions dans le plan de test de chaque projet à tester
• Définir un seuil d'acceptance en terme de sévérité et de priorité. Par exemple, afin de valider les tests d'intégrations, il ne doit plus y avoir d'anomalie critique et des solutions doivent être identifiées pour les anomalies très importantes
• Créer un seuil d'acceptance pour chaque phase de test. Par exemple, afin de valider les tests utilisateurs, il ne doit pas y avoir d'anomalie critique ou très importante, et les solutions doivent être identifiées pour les anomalies de moyenne importance
• Obtenir l'accord de votre responsable sur ces définitions
• Fournir un rapport synthétique des critères d'acceptances, comprenant le nombre d'erreurs non résolues au regard du pourcentage définit dans les critères d'acceptances, en plus de votre rapport sur les anomalies normales

Lorsque vous livrez les résultats des test à l'équipe de développement, aux partenaires métiers, et à n'importe qui d'autre, il est important de rester objectif et professionnel. Laissez les données parler elles-mêmes.

• Si la décision est prise de passer en production même si vous n'êtes pas d'accord, acceptez la décision.
• Gardez des copies des rapports d'anomalies et des résultats comme référence pour l'avenir.

En tant que testeur, nous sommes motivés pour livrer le meilleur produit possible et parfois nous nous sentons mal lorsque nous mettons en production du code qui contient des anomalies. En tant que testeur, nous n'avons pas le contrôle sur ces décisions et nous devons reconnaître que nous avons fait le meilleur travail possible.

source originale: the analyst coach