Pantesting

Testabilité

Cette notion est majeure dans le test. Elle correspond à la capacité à offrir des moyens de test sur une solution réalisée par une organisation.

Ces moyens peuvent être des retours d’informations disponibles sur l’IHM de l’utilisateur final ou rendus accessibles par une configuration de la solution à la suite d’une séquence d’actions plus ou moins complexes.

Sur ce premier niveau de testabilité "extrinsèque", il apparaît simplement que les connaissances tangibles et tacites de la solution peuvent ralentir un feedback attendu sur la solution. On imagine facilement qu’un logiciel de comptabilité peut donner le chiffre d’affaires sur un tableau de bord affiché en permanence, ou alors laisser le comptable naviguer au travers de dizaines d’IHM pour parvenir à trouver l’information, voire devoir la réunir sur différentes parties du logiciel. À ce titre, on peut comparer ce tableau de bord à un cockpit d’avion ou d’hélicoptère.

Un cockpit d’hélicoptère, pas un sapin de Noël Pour une testabilité efficace, on peut être tenté de mettre des voyants partout pour tout voir, tout le temps. Avec cette approche, on arrive vite à avoir des indicateurs dans tous les sens et il faut cinq ingénieurs pour comprendre une information… Figure I-3 : Un cockpit d’hélicoptère

En 2006, l’auteur a développé le module de gestion des alarmes du simulateur du NH90, qui affiche les informations les plus critiques, avec plusieurs niveaux de couleurs (classiquement, rouge / orange / vert). Les alarmes sont la combinaison hiérarchique de signaux secondaires qui aident à attirer l’attention et éventuellement assistent le pilote dans l’identification du problème et du diagnostic ; par exemple, si trois sous-parties sont en niveau orange, l’alarme principale sera rouge avec un signal sonore.

Lorsque le moyen de testabilité commence à impliquer la connaissance d’autres personnes, en particulier celles qui connaissent la tuyauterie du logiciel, ou des moyens techniques spécifiques. Ici, on commence à adresser la testabilité "intrinsèque", tels...

Panarchie

1. Le concept

À partir d’observations faites sur les écosystèmes rencontrés dans la nature, et à quelques exceptions près, Gunderson et Holling identifient quatre phases [Gunderson 2002] :

• Le stade α : le système est forcé de se réorganiser face aux contraintes.

• Le stade R : le système explore des solutions.

• Le stade K : le système accumule des ressources et tente de conserver un état stable.

• Le stade Ω : l’équilibre du système se relâche (le terme d’origine est "Release") et devra éventuellement repartir sur un stade Alpha.

Figure I-6 : Écocycles - Représentation stylisée des quatre fonctions de transition (α, R, K, Ω) d’un système [Gunderson 2002]

Les systèmes complexes sont connectés à d’autres. Ce sont leurs interactions qui rendent le système global complexe, et le modèle de Gunderson montre les phases où la connectivité prend une importance particulière.

• Un système dans un état de connectivité élevé va transmettre ses effets.

• Lorsque son potentiel est élevé, il aura accumulé des ressources qui seront alors diffusées en phase de relâchement aux écocycles connectés.

Lorsque les systèmes sont hiérarchisés par la présence de sphères organisationnelles comme dans une entreprise, chaque système induit des évolutions sur les autres systèmes.

Figure I-7 : Influences dans les systèmes hiérarchisés [Gunderson 2002]

Mémoire/Révolte et testing En matière de test, on peut se représenter la notion de mémoire vue dans la panarchie de Gunderson par sous la forme : d’un rapport des tests système, de la base d’anomalies, de la base d’indicateurs sur le fonctionnement de la solution (voir chapitre Pantesting appliqué à la testabilité technique - section DevOps). Un bug trouvé au sein d’une équipe de développement d’une fonctionnalité ou d’un composant crée une rupture dans le mécanisme d’intégration et livraison, c’est une révolte dans l’écocycle...

Théorie des contraintes - TdC

La théorie des contraintes (TdC ou ToC en anglais) vient de l’étude des goulots d’étranglement dans les flux de production dans les années 70 et a été popularisée par E. Goldratt dans un livre écrit sous la forme d’un roman intitulé « The Goal » (« Le But ») [Goldratt 1984], puis développée comme suit [Goldratt 1990] :

Point de vue de Kent Beck sur la TdC Kent Beck (le créateur du framework Extreme Programming, du Pair Programming, du TDD, cosignataire du manifeste agile) reproche à ce modèle d’enfermer les gens impliqués dans l’activité de développement dans des boîtes d’un processus, ce qu’ils ne sont pas. Il reconnaît cependant l’éveil que cette approche suscite sur la recherche des goulots d’étranglement [Beck 2004]. Kent Beck ajoute, par ailleurs...

Double boucle d’apprentissage

Pour limiter les effets pervers d’une mauvaise contrainte telle que vue dans la section précédente, on introduit la notion d’apprentissage en double boucle.

L’apprentissage en double boucle est une pratique esquissée par Argyris et Schön dès 1974 [Argyris 1974]. Elle est basée sur la théorie des actions.

Pour ces deux chercheurs, l’amélioration se fait :

Ainsi, le premier niveau porte sur une amélioration locale tandis que le second a une influence systémique. Les correctifs apportés correspondent à un apprentissage organisationnel à deux niveaux, comme une mise en pratique d’une théorie, et agit comme une boucle d’expérimentation d’une modélisation donnée.

Figure I-15 : La double boucle d’apprentissage [Smith 2005]

Cette représentation aide à comprendre les situations où les équipes de réalisation se rendent compte depuis des mois que la solution ne répond pas aux attentes des utilisateurs tandis que ces signaux sont filtrés par le management, qui envoie des informations biaisées à sa hiérarchie. [Argyris 1977] illustre ce propos par un exemple où une partie des managers est persuadée qu’avec plus d’efforts la solution peut être sauvée ; à force d’entêtement, l’évidence des équipes émerge et ces managers vérifient cette situation. Ils doivent alors progressivement changer leur communication vers leur hiérarchie pour justifier leur méprise pendant que les pertes s’accumulent et que le top management continue à flatter la solution…

Exemple...

Pantesting en entreprise

1. Atelier « Panarchy »

Dans le monde agile, ce modèle de panarchie est déjà utilisé par les « Liberating Structures » pour :

• identifier les obstacles et les opportunités liés à la diffusion des idées novatrices à plusieurs niveaux de l’organisation,

• travailler sur les goulots d’étranglement du groupe et correspond à la boucle d’évolution d’un système.

	Les Liberating Structures (LS - structures libératrices) Les LS sont le résultat de travaux de Henri Lipmanowicz et Keith McCandless [Lipmanowicz 2014], qui ont examiné les problèmes liés aux cinq types de meetings rencontrés : les rapports d’avancement, les sessions de brainstorming, les discussions ouvertes, la conduite des discussions, les présentations.
	Ces travaux font le même constat : trop de contrôle de la part du modérateur ou, au contraire, pas assez (notamment dans le cas de sessions de brainstorming), avec comme conséquence l’absence d’implication des participants [Bieraugel 2017]. Figure I-13 : Classement des types de réunions [McCandless 2016]
	Les 33 LS qui ont émergé (https://www.liberatingstructures.fr/menu-des-ls/) partent d’une invitation à répondre à une question, un challenge ou un problème, et chaque participant se retrouve alors impliqué de façon structurée. La structure de ce type de meeting permet aux participants...