Vendredi saint tout le monde, amis! À la fin du mois de juin, nous lançons un nouveau groupe lors du cours de
spécialiste en AQ , qui fera l'objet de la publication d'aujourd'hui.
Il existe de nombreux indicateurs grâce auxquels vous pouvez mesurer l'efficacité de l'équipe de testeurs. L'un d'eux est le taux de défauts rejetés, ou le nombre de rapports d'erreur rejetés divisé par le nombre total de rapports reçus. Vous devez penser que si le nombre de rapports rejetés est nul, c'est bien, mais ce n'est pas si simple. Examinons les types d'erreurs rejetées, voyons comment elles affectent le taux d'erreurs rejetées et calculons le ratio correct pour votre équipe.
Il existe trois catégories d'erreurs rejetées:
- Erreurs irréprochables;
- Erreurs incorrectes
- Erreurs en double.
Commençons par les erreurs elles-mêmes.
Erreurs irréproductibles
Il existe deux types d'erreurs irréprochables. La première est une erreur qui est vraiment difficile à reproduire. Cela peut être une erreur résultant de l'interaction de plusieurs paramètres, dont certains que vous ne connaissez même pas.
Supposons que vous ayez effectué plusieurs tests consécutifs et que l'un des tests ait modifié le paramètre de configuration de la valeur par défaut A en une autre valeur B. L'erreur se produit uniquement lorsque le paramètre de configuration contient la valeur B et que la valeur d'entrée est C. En essayant de reproduire l'erreur, vous souhaiterez probablement commencer par un état connu afin d'initialiser le système (ou, éventuellement, d'effectuer une installation propre). Aucune erreur ne se produira car le paramètre de configuration contient à nouveau la valeur par défaut A.
Une autre variante de ce type d'erreur non reproductible est lorsque le test a vraiment trouvé un défaut, mais il n'y a pas de données dans les informations de lecture: une étape, une valeur d'entrée spécifique ou une compréhension que l'erreur ne se produit qu'avec une certaine procédure. Par conséquent, les tentatives de reproduction de l'erreur ne mènent à rien.
Cependant, dans les deux cas ci-dessus, il y a effectivement un défaut dans le produit lui-même.
Le deuxième type d'erreur irréproductible est lorsque l'erreur ne peut pas être répétée car elle n'existe pas. Le testeur a peut-être remarqué quelque chose, mais a mal interprété, ou le système utilisé pour les tests peut avoir un problème, tel qu'un composant matériel défectueux, un pilote incompatible ou des paramètres d'accès incorrects. Les tentatives de reproduction de l'erreur sur un système correctement configuré échouent.
Ces deux types d'erreurs sont généralement signalés dans les systèmes de rapport d'erreurs comme «rejetés - ne peuvent pas être reproduits».
Erreurs incorrectes
Ce type d'erreur se produit si le testeur décide que le produit doit se comporter d'une certaine manière et signale une erreur lorsque le comportement ne répond pas à ses attentes. Cependant, une étude plus détaillée des exigences montre que les attentes du testeur étaient erronées et que le produit fonctionnait correctement. Autrement dit, le produit testé fonctionnait correctement et le testeur, qui n'était pas suffisamment familiarisé avec les exigences, a fait une erreur.
De telles erreurs sont généralement signalées dans les systèmes de rapport d'erreurs comme «rejetées - pas des erreurs» ou «rejetées - par l'architecture» (c'est-à-dire que le comportement est cohérent avec l'architecture).
Erreurs en double
Les erreurs répétitives sont les erreurs que l'on a déjà signalées et la suivante les signale. Une erreur n'est répétitive que si les «symptômes» de son apparition sont les mêmes. Et si la cause première de l'erreur est la même, mais que les «symptômes» se sont avérés différents, ce n'est pas une répétition de l'erreur!
Ces erreurs sont généralement signalées dans les systèmes de rapport d'erreurs comme «rejetées - dupliquées / répétées»
Comment les erreurs rejetées affectent une équipe
De toute évidence, une erreur incorrecte est une sorte de perte de temps que le testeur a passé à reproduire l'erreur et à la signaler, le temps que ceux qui trient les erreurs passent à les lire et à les comprendre, et le temps que les développeurs passent à essayer de reproduire une erreur non reproductible ou pour réparer (et dysfonctionner) quelque chose qui n'avait pas besoin de ce correctif.
En plus du fait que le taux d'erreur rejeté ou RDR est une mesure de l'inefficacité de l'équipe de testeurs, il parle également du professionnalisme des testeurs en général. Une erreur qui ne peut pas être reproduite en raison du manque d'informations nécessaires dans le rapport indique que les testeurs n'étaient pas méticuleux et n'ont pas travaillé assez dur pour reproduire cette erreur en utilisant les étapes décrites ci-dessus. De plus, pour les erreurs qui sont rarement reproduites, les testeurs n'ont généralement pas noté la faible fréquence de lecture dans le rapport.
L'apparition d'une erreur incorrecte indique que les testeurs ne comprennent pas parfaitement les exigences du produit. Des erreurs répétées indiquent que les testeurs n'ont pas effectué de recherche minimale dans la base de données d'erreurs locale pour vérifier si elle s'est produite plus tôt. Ou, cela signifie que le spécialiste qui a signalé cette erreur n'a pas été le premier à inclure les bons mots clés dans le nom pour faciliter la recherche de ses autres collègues.
À son tour, s’il s’avère que l’erreur que j’ai trouvée est rejetée, je suis irrité, car j’étais considéré comme un profane. D'une part, cela signifie que je défendrai les erreurs constatées. Lorsque mon rapport est rejeté, je procède comme suit:
- Je vérifie à nouveau si l'erreur se reproduit dans mon système et j'ajoute les étapes de lecture si j'ai raté quelque chose;
- Si ma mauvaise compréhension des exigences a été causée par une exigence ambiguë ou une documentation incorrecte, j'insisterai pour que l'erreur soit marquée comme une erreur de documentation et ne soit fermée que lorsque la documentation est corrigée;
- Si je pense que le comportement du produit lors de la satisfaction de l'exigence est incorrect, je parlerai des exigences avec les architectes et les développeurs, essayer de les convaincre que les exigences doivent être mises à jour (au final, je représente l'opinion du client!);
- Si l'erreur est rejetée en double, je m'assurerai qu'elle n'a pas été marquée de la même manière, ou qu'elle n'apparaît pas «selon le même scénario».
D'un autre côté, une certaine probabilité de rejet d'erreur me rend prudent. Si je ne suis pas complètement sûr d'avoir trouvé un bogue, je passerai un peu plus de temps à vérifier avant de signaler. Je demande souvent à un collègue si j'interprète correctement les exigences ou si je vérifie si l'erreur se reproduit sur le système de quelqu'un d'autre.
Avis contre l'absence totale d'erreurs rejetées
L'équipe de test doit surveiller et s'efforcer de réduire le niveau de RDR. La seule question est, quel RDR doit être considéré comme bon?
À première vue, il semble que 0% soit le résultat optimal, mais je suis fortement en désaccord avec cela. Je pense que lorsque le RDR est maintenu à un niveau sain, c'est normal, car s'il est proche de zéro, l'équipe de test souffre évidemment de problèmes non moins graves que, disons, un RDR trop élevé.
L'équipe de test doit faire de gros efforts pour atteindre un RDR extrêmement bas. Chaque erreur rejetée sera analysée pour comprendre ce qui ne va pas, et chaque testeur qui a signalé une erreur rejetée devra expliquer ce qui s'est réellement passé et comment une telle situation peut être évitée à l'avenir. En conséquence, les testeurs rapporteront des erreurs dans lesquelles ils sont absolument sûrs.
S'ils remarquent un comportement qui, selon eux, nuira à l'utilisabilité du produit, ils préféreront considérer ce comportement comme acquis, plutôt que de justifier qu'ils ont trouvé une erreur qui, en fait, n'est pas une erreur fondée sur des exigences. S'ils ont des preuves qu'une erreur s'est produite, mais qu'il n'y a pas de bon scénario pour la reproduire, ils préféreront ne pas la signaler; ils ne veulent vraiment pas se fâcher. S'ils rencontrent un bogue frivole, ils peuvent décider de ne pas le signaler du tout, car les bogues mineurs ne le corrigent pas toujours, alors pourquoi prendre le risque et avoir peur que l'erreur que vous avez trouvée soit rejetée?
En bref, la recherche d'un RDR très faible provoque du stress et un comportement malsain dans l'équipe de test, et augmente également la probabilité que certaines erreurs passent inaperçues.
Nous avons besoin de testeurs qui non seulement signalent des erreurs évidentes, mais avertissent également de tout comportement suspect dans le projet. Nous pensons que les testeurs qui attachent une grande importance à ce que l'erreur ne disparaisse pas, même au prix de rapports en double, sont meilleurs que les testeurs qui passent des heures à vérifier si un bogue a déjà été signalé dans les rapports ou non, de peur qu'ils ne faire un double. Nous voulons que les testeurs se sentent à l'aise en remettant en question le mot de l'architecte système ou de la spécification des exigences, même si cela signifie que certaines de leurs erreurs seront marquées comme rejetées.
Nous avons besoin de testeurs qui n'ont pas peur de faire des erreurs de temps en temps. Cela signifie que l'équilibre est nécessaire, donc un petit RDR est considéré comme acceptable.
Trouver le taux optimal de défauts rejetés
Ma règle d'or est que le RDR devrait être de 15%. Cette valeur est basée sur mon expérience avec l'équipe de testeurs, qui, selon tous les comptes, était une bonne équipe efficace. C'était notre RDR au cours de plusieurs projets qui se sont succédé, tandis que l'autre équipe, qui a travaillé sur les mêmes projets et en parallèle avec nous, bien qu'elle soit moins consciente du produit et considérée comme moins efficace, avait un RDR de 30%. .
Je ne pense pas qu'il y ait une justification à ce sens autre que mon sentiment intérieur. Ce n'est certainement pas scientifique. Je ne discuterai pas avec une équipe qui vise 10 ou 20%, mais je pense que supporter 30% ou fixer un objectif de 5% est déjà un problème.
En fin de compte, c'est une décision qui doit être prise par l'équipe de testeurs, en fonction des caractéristiques du produit, du niveau d'expertise de l'équipe, du modèle de développement, de l'expérience de l'équipe de développement et bien plus encore. Je vous recommande fortement de garder un œil sur le RDR et de vous demander si vous devez en faire quelque chose. Et s'il est trop élevé ou trop bas, des mesures appropriées doivent être prises.
Par tradition, nous attendons vos commentaires et vous invitons à un
webinaire gratuit , qui se tiendra le 14 juin. A très bientôt!