Sommaire

Introduction

La façon dont les activités de développement sont conduites est décisive dans la testabilité d’une solution. Chaque activité est une opportunité d’introduire des pratiques de test et en améliore l’efficacité.

La difficulté à laquelle le test agile à l’échelle est confronté est due :

  • aux cadences de mise en œuvre des besoins des clients

  • à la quantité d’éléments produits tels que les besoins, le code ou les documents

  • aux activités et compétences décloisonnées des organisations pleinement agiles de type C [Nonaka 1986], car tout est effectué « en même temps », ce qui pose la question du moment où se fait le test. Dans [Moustier 2019a], la question trouve des réponses, mais comment limiter (voire éviter) de générer un phénomène d’étagement des actions entre chaque équipe et le client ? En effet, il est facile de concevoir des équipes agiles qui livrent leur produit à une équipe d’intégration qui assemble les différentes parties pour livrer la solution complète pour des tests de bout en bout. Hélas, cet exemple décrit clairement une organisation de type B, voire A.

Loin d’apporter une baguette magique, cette section donne des éléments pour s’approcher de cet idéal. ...