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...

Pour consulter la suite, découvrez le livre suivant :
couv_DPTESSAF.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
Résumé
Suivant
Rôle de la vision