La taverne du testeur

La faute à qui?

Cette idée d’article m’est venue suite à une discussion avec Rajae AOUCHI lorsque j’ai publié cette caricature.

La question est simple: Qui est responsable dans ce cas?

faute

Afin d’avoir une réponse plus précise je vais préciser un contexte:

  1. Les tests sont effectués, tout va bien sauf un problème critique qui est détecté sur les freins.
  2. Un bilan très court est envoyé au métier: Tout fonctionne parfaitement sauf les freins
  3. Le métier ne cherche pas plus et décide de sortir en production pour ne pas être en retard.

Qui est responsable de cet accident?

Voici mon point de vue: Le métier a la responsabilité d’une sortie en production. C’est donc lui qui est responsable.

Néanmoins le testeur a mal (voir très mal) fait son travail. Lorsqu’un bug critique est détecté il doit mettre tout en oeuvre pour que les membres du projet soient bien au courant de son impact et des risques encourus. Dans le contexte que j’ai présenté la visibilité était très mauvais.

Et vous, quel est votre avis, et pourquoi?

A vos commentaires!

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.

 

 

Commentaires sur LinkedIn:

com_1

com_2

com_3

com_4

com_5

com_6

com_7

com_8

com_9

com_10

com_11

Une réponse

  1. Personnellement dans la méthode AGILE j’ai toujours appris que l’on ne parle plus de personne mais d’une équipe. Et ici on est en plein dans le sujet. C’est la responsabilité de l’équipe.
    – Le développeur n’a pas (bien) fait les tests unitaires/integration
    – Le testeur n’a pas (bien) communiqué le problème
    – Le PO n’a pas (bien) pris en compte le bug
    – Le métier n’a pas (bien) évalué les risques.
    – Le PO/BA/Test Manager qui n’a pas (bien) écrit les critères d’acceptations
    Bref vous l’aurez compris c’est une chaîne de dysfonctionnement qui fait que le concorde s’est écrasé sur un hotel, un seul chaînon répond et le drame est évité. La responsabilité vient de l’équipe et c’est sur ce point qu’il faut travailler. c’est un problème de fond qu’il faut réaliser pas un problème de personne. Pour moi les actions à prendre sont multiples:
    – Rappel des règles de qualité avec les TU + relecture de code
    – Relecture des stories et des critères d’acceptation
    – Mise en place de revue de bug avec l’équipe
    – Diffusion d’un rapport de test clair
    – Déplacement de la responsabilité du GO/NOGO du PO vers le Test manager.
    – Réunion de Go en prod avec tous les principaux acteurs
    Je pense que plutôt de rechercher un responsable (personne physique), il est important de recherche les éléments responsables (actions) afin de les corriger à tous les niveaux. C’est pour cela que je préfère parler de qualité plutôt que de test car la qualité est l’affaire de tous et ce cas en est un parfait exemple.

Laisser un commentaire

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

Campagnes

Xray et armoire à vêtements – Aude Murguet

Un nouvel outil est de plus en plus déployé : JIRA XRAY Mais, nouvel outil signifie aussi nouveaux concepts. Aussi, pour mieux comprendre les concepts XRAY, je vous propose de faire une analogie avec votre armoire à vêtement. En effet, nous avons toutes et tous une armoire, une commode pour ranger

Lire la suite »
culture générale

Industrie classique ≠ Industrie logicielle

Encore trop de personnes haut placées dans les entreprises logicielles ne jurent que par la « productivité ». La sacro-sainte « productivité » ! Dans l’industrie classique cela revient à produire des pièces mécaniques. Dans l’industrie logicielle on  représente malheureusement souvent cela comme « pisser du code » (ce qui explique « productivité »). Cela me met hors de

Lire la suite »
Formation

Webinaire: se former au test

Revivez le webinaire sur la formation dans le test. Ci-dessous le support de présentation: Il s’est articulé autour de 3 types de formations: Il était divisé en 4 parties: Merci aux animateurs de ce webinaire: Bruno Legeard:Membre du bureau du CFTL et membre actif de la communauté ISTQB dans la

Lire la suite »