Jidoka sur le pipeline

Amélioration

Capacité du pipeline à être autonome dans la reprise sur erreur

Amélioration

Description

Dans les usines d'assemblage, les lignes d'assemblage manuelles gèrent les incidents grâce à "Andon", un mécanisme d'alerte qui implique une action immédiate des personnes. Dans ce contexte, le responsable de ligne est là pour soutenir la gestion des incidents ou l'équipe d'assistance peut être appelée à intervenir pour résoudre le problème le plus rapidement possible et aussi pour résoudre la cause première dans un deuxième temps. Lorsque la ligne est automatisée, l'opérateur de ligne surveille les robots défaillants pour résoudre les incidents.

L'opérateur de ligne surveille les incidents sur les robots

Au lieu de réparer les unités, les robots sont mis à niveau pour gérer de nouvelles situations en alertant l'opérateur de ligne.

Cette automatisation qui corrige automatiquement les problèmes est nommée "Jidoka", un mot japonais (自働化) basé sur les idéogrammes suivants . 

  • 自 : soi-même
  • 働 : travail
  • 化 : changement

que l'on peut traduire par "Autonomation", un mot-valise composé de "Autonomie" et "Automatisation". Le Jidoka est utilisé pour améliorer les robots en détectant chaque situation et en adaptant les comportements des robots avec les manipulations appropriées.

Jidoka améliore le robot avec des fonctions d'auto-réparation

Jidoka est très important dans le contexte CI/CD car les problèmes de faux positifs (FP) provenant des scripts de test arrêtent le pipeline d'intégration et obligent le développeur à résoudre le problème, tout comme l'opérateur de ligne dans une usine automatisée.

En fait, les FP surviennent 72 % du temps lorsqu'un problème est soulevé, principalement en raison de problèmes de script (46 %) [Philipp 2019].

Les problèmes trouvés par les scripts de test sont en fait des FP avec 72% [Moustier 2020].

Supposons que la fiabilité globale des scripts de test atteigne 99,7 % ; si le pipeline intègre 400 scripts, sa fiabilité ne sera que de 30 % (99,7 %^400) ; par conséquent, le pipeline échouera dans 70 % (100 %-30 %) des cas, et dans 50 % des cas (70 %*72 %), cela sera dû à des FP.

Avec 700 scripts, la fiabilité globale sera alors de 12% avec 63% de FP.

Mais si la fiabilité du script est améliorée à 99,9%, alors 700 tests passeraient à 49,6%, avec 36% de FP ; cela prouve que l'amélioration de la fiabilité est majeure. Jidoka est un moyen d'améliorer cela car il vise à permettre au script d'être plus résilient à chaque situation.

Impact sur la maturité des tests

Il existe différents types de techniques Jidoka adaptées à l'automatisation des scripts de test qui peuvent être explorées :

  • Jidoka basé sur la répétition
  • Jidoka basé sur la testabilité
  • Jidoka basé sur Poka Yoke
  • Jidoka basé sur les KPI
Types de Jidoka

Le Jidoka basé sur la répétition est l'approche de test la plus stupide : imaginez simplement que vous êtes confronté à un comportement inattendu, réessayez-vous seulement votre scénario ou préférez-vous faire des tests plus approfondis et essayer des solutions de contournement ?

La répétition d'un scénario est également consommatrice de temps et de ressources, ce qui ralentit les performances du pipeline et ne fait que prévenir les retards du système. Il serait plus judicieux de tester les parties internes pour qu'elles s'adaptent à des situations connues, comme le fait Jidoka. En fait, la technique du dumb-retry reflète le peu de connaissances que nous avons de la testabilité des parties invoquées.

Enfin, les scripts basés sur le dumb-retry ne sont pas fiables et fournissent des résultats non déterministes [Axelrod 2018].

Bien que certaines écoles de test [Pettichord 2007] préfèrent fournir un statut d'échec au lieu de faire une enquête plus approfondie, cela ne fait que conduire au problème de la PF vu ci-dessus. Il est alors préférable d'essayer d'atteindre l'objectif du test, ce qui est l'idée de base du Jidoka.

Par conséquent, la technique de "Réessayer" devrait être transformée en "essayer des solutions de rechange à partir des situations détectées" au lieu de la réessayer muette, et finalement augmenter le nombre de chemins alternatifs pour apprendre où sont vos points faibles en ce qui concerne le besoin de Jidoka.

Testabilité-basée sur Jidoka: Comme on l'a vu avec les techniques de réessai, plus vous pouvez creuser dans les sous-parties de test, plus vous serez en mesure de connaître leurs configurations et leurs statuts pour repérer les changements de situation et définir le comportement approprié pour éviter les PF.

La testabilité couvre différents aspects

  • testabilité extrinsèque : couvre les moyens de test évidents et visibles
  • testabilité intrinsèque : couvre les moyens de test disponibles des sous-parties
  • testabilité technique : interfaces techniques disponibles à partir desquelles les tests peuvent être effectués.
  • testabilité sociale : le partage du "comment tester ceci" fait également partie de la testabilité puisque les moyens existent mais sont inconnus du testeur.

Aspects de testabilité [Moustier 2020]

Si la testabilité est faible, il sera difficile d'interpréter les résultats puisque le retour d'information ne montrera pas si le système présente un problème ou s'il a simplement mal évalué la situation. Il en résultera alors un besoin de prendre des mesures pour contrer un contrôle inefficace, ce qui augmentera la charge de travail [Bainbridge 1983]. C'est pourquoi vous devriez chercher des moyens de testabilité à automatiser afin de détecter les situations et de deviner la solution appropriée applicable pour améliorer votre Jidoka.

Jidoka pourrait aussi être basé sur Poka-Yokes. Le Jidoka basé sur le Poka-Yoke, en tant qu'extension du Jidoka basé sur la relance, peut être introduit progressivement d'une simple atténuation à son élimination :

Degrés de Poka Yoke

A partir de ces composants, des KPI peuvent être calculés à partir de certaines informations qui peuvent être récupérées pour repérer avec précision les scripts non fiables et permettre des améliorations de Jidoka.

Vous pouvez alors 

  • compter le nombre d'échecs (FP et bugs) pour deviner dans une approche de type bayésien [3Blue1Brown 2019] si un FP est hautement probable.
  • mettre en évidence la stabilité du script en fonction de la PF et de l'âge du script - les fonctionnalités anciennes et non modifiées sont moins sujettes à la PF
  • compter des scénarios de base et des solutions de contournement pour voir dans quelle mesure les situations sont stables.

Ces chiffres seront

  • aider à la prise de décision à partir des résultats des tests afin d'orienter le suivi des tests les plus pertinents
  • fournir un état de santé sur la robustesse des scripts - chaque solution de contournement et chaque PF trouvée peut être suivie pour indiquer à quel point chaque script est douteux et commencer à mesurer votre fiabilité globale.

Cette approche vise à prévenir les problèmes lors de l'essai des robots

  • au moment de l'idéation :
    - Introduire des andons dans le produit (journaux, problèmes dans le backlog, alertes pour des actions immédiates)
    - Mettre à jour la conception pour désactiver les problèmes
    - Fournir des harnais de test pour permettre des retours rapides et fiables
  • au moment de l'exécution : détection/prévention des problèmes en production (dans le cadre du pipeline CI/CD)
  • à tout moment :
    - Inspections et rétrospectives des sources
    - Automatisez tout ce que vous pouvez - y compris la surveillance

Pour commencer, seuls les tests de sanité sont lancés dans le CI. La suite de sanity doit couvrir la plupart des fonctionnalités, mais juste un peu de chacune d'entre elles [Axelrod 2018] car c'est plus facile à maintenir. Les permutations et les cas limites sont éventuellement exécutés dans un pipeline différent. Cependant, seule la combinaison de tous ces composants permettra d'atteindre la barre de fiabilité de 100 %, à condition que des rétrospectives soient impliquées.

Les rétrospectives doivent être combinées avec les types de Jidoka pour améliorer les robots.

Cette structure de boucle en couches a été découverte par Chris Argyris sous le nom de "Double Loop Learning" [Argyris 1977] [Smith 2001]. Cette composante du PanTesting évite de réduire un résultat (un produit, un robot, ou autre) à sa simple conformité aux objectifs fixés en introduisant des directives et un retour d'information à un niveau plus élevé, éventuellement avec des cycles de retour d'information plus longs comme avec Lean Startup, OKRs ou ATDD/TDD. L'apprentissage en double boucle fournit un mélange d'objectifs à court, moyen et long terme.

L'apprentissage en double boucle offre des niveaux de plongée profonde et de vue d'ensemble.

En un mot, Flaky Tests devrait vous amener à disposer de solides scripts de tests automatisés au cours du sprint. Ce défi est en fait celui auquel les équipes sont confrontées :

" Dis-moi comment tu testes, je te dirai à quel point tu es agile ! "

Le point de vue d'Agilitest sur cette pratique

Agilitest est principalement une solution basée sur le dumb-retry. Cependant, puisqu'il s'agit d'une approche de script #nocode, la quantité de PF due aux scripts est inférieure à celle des scripts basés sur le code. De plus, Agilitest incorpore quelques heuristiques pour faciliter la recherche de widgets et réduire la quantité de PF en cas de changement de GUI.

Agilitest est également doté d'interfaces API REST pour sonder les sous-parties, à condition que les scripteurs favorisent la testabilité ou aient accès à des moyens de testabilité.

La contrepartie du #nocode est que le Poka Yoke est plus facile sur le code de production puisqu'il n'y a pas d'instruction de branchement sauf sur le type de navigateur. Cela renforce le besoin de faire une rétrospective sur la FP pour interagir étroitement avec les développeurs et éventuellement fusionner les écocycles de développement / automatisation des tests.

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

Pour aller plus loin

© Christophe Moustier - 2021