Gérer ou ne pas gérer les Defects ?

1. Pourquoi cette question ?

Supposons qu’une campagne de test de validation d’Items soit implémentée dans QC comme nous le proposons dans le présent chapitre, que doit faire celui qui détecte qu’un test est à Failed ou à Blocked dans le Test Lab ?

Nous venons de voir dans la section précédente qu’il se doit de communiquer avec le ou les développeurs du Sprint pendant les Stand Up Meetings pour indiquer l’impossibilité de valider l’Item.

Mais pourquoi ne devrait-il pas alors saisir un Defect dans QC comme n’importe quel autre testeur exécutant une campagne ? Et quelle incidence sur l’organisation Agile du projet ?

a. De l’influence des contrats

Si l’équipe MOE est externe avec un engagement forfaitaire, il est peu probable qu’elle soit encline à afficher par un volume quantifiable d’objets les difficultés rencontrées.

La question de remonter des défauts pendant les développements n’est donc pas neutre, à plus forte raison en Agilité. Car dans un kanban (mural ou électronique), tout devient visible.

Mais est-ce dans l’intérêt de tous que tout soit visible ? Théoriquement, c’est ce que prône le Manifeste Agile. Dans la pratique, les choses ne sont pas si simples.

Notre expérience nous a montré qu’un coach Agile également...

Pour consulter la suite, découvrez le livre suivant :
couv_EPALMQC.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Valider les Items dans le Test Lab
Suivant
Les inconvénients