Vue systémique

Description

SAFe applique ce principe pour comprendre le développement logiciel dans son ensemble car [SAFe 2021-2] :

• la solution est un système à part entière
• l'entreprise qui construit ce système est un système à part entière
• cette entreprise doit optimiser l'ensemble de la chaîne de valeur
• si le système global n'est pas géré, il ne se gérera pas lui-même et finira par constituer des parties autonomes, mais individuelles et indépendantes qui se feront concurrence les unes aux autres

Il faut donc pousser chaque partie à coopérer.

Si l'on considère les modes de collaboration, ne serait-ce qu'au niveau de l'architecture, Eric Evans, le créateur de la conception pilotée par le domaine (DDD), propose un outil appelé "Context Mapping" qui offre différents modes de collaboration [Evans 2004] [Moustier 2020] :

• "Voie séparée" : les deux groupes n'ont pas d'impact l'un sur l'autre et peuvent évoluer séparément.
• "Couche anti-corruption" : les activités d'un groupe sont isolées des autres par un groupe qui reflète les interactions avec le sous-système qui est alors protégé.
• "Conformiste" : un groupe doit se conformer aux changements imposés par un autre groupe.
• "Relation client-fournisseur" : les changements dans un groupe impliquent une adaptation de l'autre groupe.
• "Noyau partagé" : plusieurs groupes se partagent les besoins réalisés par une seule entité.
• "Service d'accueil ouvert" : il s'agit d'une généralisation de la couche anti-corruption à plusieurs groupes qui tentent d'interagir avec un sous-système à protéger.
• "Partenariat" : lorsque deux groupes ont leurs succès et leurs échecs intimement liés.
• "Mudball" : un contexte trop amalgamé pour établir des relations simples entre les groupes qui le composent
  

Bien que DDD soit présenté comme une technique d'architecture, il s'avère que l'organisation et l'architecture de l'entreprise sont fortement liées [Conway 1968] et justifie ce parallèle comme base de réflexion pour une approche des systèmes organisationnels et techniques.

Application à la maturité des tests

Les tests ont différentes facettes, notamment [Moustier 2019-1] :

• l'aspect commercial, qui permet de produire des tests pertinents
• l'aspect industriel, qui permet d'organiser les tests lorsque la massification des ressources (personnes, scénarios, données, environnements, automatisation, etc.
• le côté systémique, qui permet d'aller plus loin dans les tests car lorsque les deux premiers aspects sont maîtrisés, les tests seront limités par tous ceux qui produisent la solution ; c'est alors que l'organisation doit changer pour intégrer les tests dans toutes les parties telles que :

                  ○ améliorer l'idéation pour avoir des User Stories testables.

                  ○ améliorer le développement avec des tests unitaires et avoir une pyramide de tests dans la bonne direction [Cohn 2009].

                  ○ demander aux développeurs d'ajouter des identifiants aux widgets HTML pour faciliter les recherches

                  ○ intégrer les exigences non fonctionnelles dans toutes les phases du produit.

                  ○ aso

Sans une approche globale, le test est limité à une position réactive et l'anticipation ne conduit qu'à un effet tunnel. Agile, avec son approche itérative et courte [SAFe 2021-4], réduit cet effet mais laisse les testeurs dans une situation où ils ont très peu de temps, ce qui les conduit à tester après le sprint alors que le Product Owner devrait avoir un incrément de produit potentiellement livrable [Schwaber 2020].

Ainsi, l'apport de la vision systémique dans les tests agiles donne une sorte de " Manifeste des tests agiles " [Laing 2016] [Moustier 2019-1] :

• Testez pendant le sprint plutôt qu'à la fin ou après le sprint.
• Prévenir bugs plutôt que de le rechercher
• Comprendre ce qu'il faut tester plutôt que de vérifier les fonctionnalités
• Concevoir un meilleur système plutôt que d'essayer de casser le logiciel.
• L'équipe est responsable de la qualité du produit plutôt que les testeurs qui sont responsables de la qualité.

‍

La position d'Agilitest sur cette pratique

En tant qu'outil d'automatisation, Agilitest doit s'inscrire dans une démarche ou une stratégie d'automatisation. Sa simplicité ne doit pas conduire les équipes à déléguer cette automatisation à un groupe de personnes qui doit réaliser l'automatisation des tests, sinon on se retrouvera rapidement dans les pièges mentionnés ci-dessus.

Pour découvrir l'ensemble des pratiques, cliquez ici.