Introduction

Ce chapitre aborde les moyens de tests à l’échelle liés aux éléments attendus sur la solution. Sur ce premier versant duquel le Pantesting va être utilisé, ses différents composants vont être progressivement introduits par le biais de la testabilité des attentes du métier. Vous allez retrouver ces éléments plus en détail dans le chapitre Pantesting appliqué au cycle de développement avec l’application du Pantesting au cycle de développement.

Testabilité des fonctionnalités

Les premiers éléments sur lesquels la testabilité doit pouvoir s’exprimer sont les éléments du Backlog dont l’appellation générique est Product Backlog Item (PBI - élément de Backlog produit).

1. Capture du besoin et génération des idées

La première étape dans la création des idées est la découverte du besoin. Dans une simple équipe Scrum, cet aspect est mené par le PO, qui réunit les besoins et fait émerger les idées qui deviennent des US.

Dans un « bon vieux » Waterfall, ce rôle est fait en amont de la génération de la solution, mais la réalité montre que le besoin est en fait affiné avec la découverte de la solution.

L’approche Lean-agile répond à cette particularité en proposant aux participants de ne pas aller trop loin dans la capture du besoin afin de ne pas créer un stock d’idées trop important. En effet, plus le stock est important, plus on augmente la probabilité d’avoir des idées inutiles et l’effort de gestion que cela implique.

En matière de panarchie, l’exploration des idées (phase R) doit être la plus rapide possible afin de :

ne conserver que l’essentiel,
publier au plus vite une version (phase Ω) pour obtenir un feedback de l’écocycle de rang supérieur.

La notion de MVP développée dans le chapitre Pantesting appliqué au cycle de développement apporte une approche qui va dans ce sens. Elle donne rapidement les moyens d’établir la connexion entre les écocycles de l’organisation et du marché.

Par ailleurs, pour faciliter l’émergence d’une connaissance tacite perçue par les parties prenantes et parvenir à des informations tangibles, la théorie de la connaissance propose une phase de socialisation de la connaissance [Nonaka 1994], ce qui peut être compris par la combinaison d’un effet de révolte (émergence) et de mémoire (ce que la collectivité va finalement accepter) lors de l’atelier d’idéation (tel que les « 3 Amigos » [Moustier 2019a] ou le « PI...

Testabilité des exigences non fonctionnelles

L’implication de certains profils dans la conception des PBI permet d’élargir le périmètre d’un besoin, notamment en ce qui concerne les problématiques de test et testabilité, mais aussi les besoins en matière d’exploitation et plus généralement les exigences non fonctionnelles. Pour faciliter cela, un profil :

de type testeur pousse les questions liées aux quatre quadrants du test [Marick 2003] [Bach 2014] [Moustier 2019a] et il pousse ainsi la stratégie de tests [Bach 2019] [Moustier 2019a] [Moustier 2019d]
de type exploitant pose les questions relatives à l’exploitation
de type "White Hat" (sécurité) pousse l’analyse dysfonctionnelle par création de cas malicieux [Moustier 2019a]

Figure II-9 : notation UML des cas malicieux pour analyse de vulnérabilité

Les Exigences non fonctionnelles (ENF) peuvent prendre beaucoup de temps sur leur ingénierie comme pour l’exécution. L’équipe de réalisation joue un rôle majeur dans le test de ces ENF, car une grosse partie se joue dès la conception (voir section Pantesting appliqué à la testabilité technique - Architecture agile) et il faut les traiter au même titre que les exigences liées à des capacités fonctionnelles [Larman...

Documentation liée à la solution

Bien que le manifeste agile privilégie un logiciel fonctionnel à une documentation exhaustive [Beck 2001], l’entreprise a néanmoins besoin de capitaliser la connaissance tacite et de la transformer en connaissance tangible [Nonaka 1998] - (voir section Pantesting appliqué au support - Gestion de la connaissance). En effet, pour aligner l’organisation et les clients, il est nécessaire [Leffingwell 2018] :

d’avoir une vue d’ensemble et cohérente,
de disposer d’une source unique de vérité,
d’enregistrer et communiquer les accords et les décisions (contrats, besoins, architecture),
d’aligner les équipes internes et les fournisseurs,
de faciliter la prise de décision sur les prochaines étapes,
de disposer des éléments de preuve pour les conformités avec les engagements et les certifications,

mais aussi d’utiliser la documentation pour faciliter la mise à l’échelle de l’organisation, avec tout ce que cela peut entraîner sur le long terme (ex. le turnover des équipes) [Rüping 2003].

La documentation de la solution et vue d’ensemble

Compte tenu qu’en agile la solution émerge aussi du feedback des utilisateurs à partir des incréments, la documentation de la solution ne se fait pas de façon linéaire et un même chapitre peut être réécrit plusieurs fois à des moments espacés. Par ailleurs, une lecture des US réalisées ne saurait être une action efficace pour prendre connaissance de la solution, ce serait comme si on devait regarder chaque pièce d’un puzzle pour comprendre l’image…

Ainsi, il arrive que certaines entreprises ressentent le besoin de traduire les US en un document de spécification classique pour des raisons culturelles ou réglementaires.

Un autre cas relatif à la documentation de la solution est celui du fameux manuel utilisateur ou plus généralement de la documentation liée aux opérations.

Chez SAFe, cette documentation peut être générée par un Enabler de conformité pour assumer les évolutions ; en même temps, cette activité peut aussi être intégrée...

DoD à l’échelle

Au niveau d’une équipe Scrum, la présence d’une définition du "terminé" (Definition of Done - DoD) est incontournable [Schwaber 2017]. Vous pouvez retrouver dans [Moustier 2019a], [Silva 2017] ou [Purushotham 2013] quelques idées et astuces pour la DoD d’une équipe, mais au-delà des différents critères qui peuvent être rajoutés dans la DoD, il convient ici d’y appliquer la TdC (Théorie des contraintes) ; en effet, la TdC vient pousser la DoD à rehausser la contrainte (4e règle de la TdC) tant que cela ne vient pas dégrader le système (5e règle de la TdC - voir un exemple avec [Moustier 2019b]).

Lorsqu’il s’agit de passer à l’échelle, l’enjeu est de fournir de la transparence, non plus seulement au niveau de l’équipe, mais au niveau de la solution. C’est pourquoi [Larman 2017] propose une DoD générique à toutes les équipes. Cette DoD est alors régulièrement améliorée, sprint après sprint et au sein de chaque équipe, une définition adaptée et éventuellement plus forte est utilisée.

Larman note que toutes les activités nécessaires à la publication qui ne sont pas présentes dans la DoD ni entreprises...

DoR à l’échelle

La DoR (Definition of Ready - définition du "Prêt") n’est pas une condition sine qua non pour légitimer l’accès d’un PBI au sprint Planning, mais plutôt un guide pour faciliter la prise en main de ce PBI [Moustier 2019a].

Traditionnellement, la DoR se contente d’une vérification autour d’INVEST, mais avec le modèle du Pantesting, la DoR peut s’enrichir grâce à :

l’identification d’éléments de testabilité tels que :

les conditions et moyens d’acceptation fonctionnels spécifiques au PBI
les moyens à mettre à disposition pour vérifier le bon fonctionnement de la réalisation (ex. un log, une API, un comportement spécifique en cas d’erreur)

l’identification de connexions vers d’autres écocycles tels que :

des dépendances, attentes et contraintes avec d’autres PBI fonctionnels ou d’autres équipes
des références vers des documents existants

des prérequis tels que des Enablers pour en apprendre davantage sur la façon de procéder.

Et suivant la théorie des contraintes, ces critères doivent augmenter progressivement avec la maturité de l’environnement, des parties prenantes et des connexions dont elles ont conscience. Dans cette optique...

Résumé

La génération des éléments d’idéation en groupe permet :

une large diffusion, la plus fidèle qui soit tout en limitant les distorsions,
de les tester à la volée en apportant un maximum d’éléments contradictoires ou de consolidation sur différents plans (métier, technique…) dans un court laps de temps afin de limiter l’effet de révolte panarchique au démarrage des écocycles sur la phase de réalisation.

Les US générées doivent rester proches des idées initiales pour limiter l’apparition d’écocycles intermédiaires qui rajoutent de la latence, des distorsions et plus de difficultés à tester, car les doubles boucles d’apprentissage doivent alors s’empiler. C’est pourquoi générer des US tournées vers le métier, comme dans LeSS, est un choix pertinent. Cette orientation va de pair avec les équipes de fonctionnalités (voir chapitre Pantesting appliqué au support - section Rôles), car cela facilite la cohérence.

De même, l’utilisation d’un même langage dans toutes les couches (ex. Gherkin - voir chapitre Pantesting appliqué à la testabilité technique - section Domain-Driven Design - DDD) est à forte valeur ajoutée pour rester compréhensible par le client. Par ce langage ubiquitaire (c’est-à-dire que l’on retrouve partout), les échanges entre les écocycles sont ainsi...

Pantesting appliqué au métier