Rédiger des scénarios d’attributs de qualité testables

Pourquoi des scénarios

La section 2.2 vous a donné le vocabulaire des qualités ; cette section vous en donne la grammaire. Le nom d’une qualité à lui seul, comme les performances ou la sécurité, ne permet ni de concevoir ni de tester. Même un chiffre seul ne suffit pas : « 2 secondes » ne veut rien dire tant que l’on ne sait pas pour quelle opération, sous quelle charge, mesuré où et pour quelle proportion des requêtes. Le scénario d’attribut de qualité, mis au point au Software Engineering Institute (SEI) et exposé par Len Bass, Paul Clements et Rick Kazman dans Software Architecture in Practice, résout ce problème en imposant à chaque exigence de qualité la même forme en six parties.

L’idée est simple. Chaque qualité se manifeste lorsqu’il arrive quelque chose à un système : un afflux d’utilisateurs, une panne, une demande de changement, une attaque. Un scénario nomme cet événement, les circonstances, la partie du système touchée, ce qui doit se passer et la manière dont vous saurez que cela s’est passé suffisamment bien. Il est court (en général une à trois phrases), concret et testable. Et comme toutes les qualités utilisent la même forme, des scénarios de performances, de sécurité et de modifiabilité peuvent figurer côte à côte dans une même liste hiérarchisée.

Les six parties

Les six parties sont la source du stimulus, le stimulus, l’artefact, l’environnement, la réponse et la mesure de la réponse. Apprenez-les dans cet ordre, car ensemble elles racontent une courte histoire : quelqu’un ou quelque chose fait quelque chose à une partie du système dans certaines conditions ; le système fait quelque chose, et nous le mesurons ainsi. Le stimulus et la mesure de la réponse sont les deux parties que l’on oublie le plus souvent, et ce sont les deux qui comptent le plus.

L’environnement mérite une attention particulière, car un même stimulus peut exiger des réponses très différentes selon les conditions. Un serveur en panne pendant le fonctionnement normal peut exiger un failover (basculement) automatique en moins d’une minute ; la même panne pendant une fenêtre de maintenance planifiée peut être acceptable avec une reprise manuelle. Une demande de changement au moment de la conception (avant la mise en production) coûte bien moins cher que le même changement une fois que des données se sont accumulées en production. Écrire l’environnement explicitement évite que l’on compare des scénarios qui portent en réalité sur des situations différentes.

L’artefact compte pour une raison similaire. « Le système répond en 200 ms » cache quelle partie est responsable. Nommer l’artefact (le service de recherche, l’API gateway, le client mobile) indique à l’équipe où le travail de conception et la mesure doivent avoir lieu. Pour certaines qualités, comme la modifiabilité et la déployabilité, l’artefact peut être du code, de la configuration ou le pipeline de livraison plutôt qu’un composant en cours d’exécution.

Scénarios généraux et scénarios concrets

Bass, Clements et Kazman en distinguent deux types. Un scénario général est indépendant de tout système : pour un attribut de qualité donné, il énumère les valeurs typiques que peut prendre chaque partie. Pour la disponibilité, par exemple, les sources peuvent être internes ou externes, des personnes, du matériel, du logiciel ou de l’infrastructure ; les stimuli peuvent être une panne, une omission, un timing incorrect ou une réponse incorrecte ; les réponses peuvent consister à détecter, enregistrer, rétablir, masquer ou dégrader ; et les mesures peuvent être le temps de détection, le temps de réparation, le pourcentage de disponibilité ou la proportion de requêtes traitées.

Un scénario concret choisit des valeurs précises pour un système particulier : « la base de données principale des commandes tombe en panne pendant le fonctionnement normal ; la réplique prend le relais et les écritures reprennent en moins de 60 secondes sans perte d’aucune commande validée ». Les scénarios généraux sont des modèles et des listes de contrôle ; les scénarios concrets sont des exigences. Vous utilisez le scénario général pour vous assurer d’avoir envisagé les bonnes sources, les bons stimuli et les bonnes mesures, puis vous rédigez la poignée de scénarios concrets qui comptent pour votre système.

Des énoncés vagues aux scénarios testables

La plupart des exigences de qualité commencent leur vie sous forme d’adjectifs. Tout l’art consiste à poser les questions qui transforment chaque adjectif en scénario : quelle opération ? déclenchée par qui ? à quelle fréquence ou en quelle quantité ? dans quelles conditions ? que doit-il se passer ? quel chiffre nous dira que cela a fonctionné ? Le tableau présente des paires « avant » et « après » typiques. Remarquez que les versions « après » révèlent parfois que la partie prenante voulait dire plusieurs choses différentes, qui deviennent alors plusieurs scénarios.

Des exemples de scénarios pour six qualités

Les exemples ci-dessous portent tous sur une même boutique en ligne, pour que vous puissiez voir comment des qualités différentes se présentent dans le même format. Chacun est écrit de façon compacte avec ses six parties étiquetées ; en pratique, les équipes les écrivent souvent en une ou deux phrases.

Deux caractéristiques de ces exemples méritent d’être relevées. D’abord, les scénarios ne portent pas uniquement sur le logiciel en cours d’exécution. Les scénarios de modifiabilité et de déployabilité ont pour sources des développeurs et des product owners, et leurs mesures portent sur l’effort, le temps écoulé et l’étendue du changement. Ensuite, les bonnes mesures combinent souvent un chiffre de rapidité et un chiffre d’exactitude : « en moins de 60 secondes » et « aucune commande validée perdue ». Un failover rapide qui perd des données n’est pas ce que voulait le métier.

Erreurs courantes

À relire des centaines de scénarios rédigés par des équipes, on retrouve sans cesse les mêmes erreurs. Chacune rend un scénario intestable ou trompeur.

Des scénarios aux tests d’acceptation et aux fonctions d’aptitude

Un scénario bien rédigé constitue déjà l’essentiel d’un test. La source et le stimulus vous disent quelle charge ou quel événement générer, l’environnement vous dit comment préparer le test, l’artefact vous dit quoi observer et la mesure de la réponse fournit la condition de réussite. Un scénario de performances devient un test de charge ; un scénario de disponibilité devient un exercice de failover ou une expérience de chaos ; un scénario de modifiabilité devient l’examen de la quantité de code touchée par une modification type et du temps qu’elle a pris ; un scénario de sécurité devient un cas de test d’intrusion.

L’étape suivante consiste à continuer de vérifier. Une fonction d’aptitude (fitness function), terme popularisé par Neal Ford, Rebecca Parsons et Patrick Kua dans Building Evolutionary Architectures, est toute vérification automatisée ou reproductible de la mesure dans laquelle le système atteint un objectif architectural. Exécutée dans le pipeline de livraison ou sur la télémétrie de production, elle fait passer un scénario du statut de test d’acceptation ponctuel à celui de garde-fou permanent : le build échoue, ou une alerte se déclenche, quand la qualité dérive. Le chapitre 11 traite des fonctions d’aptitude en profondeur dans Fonctions d’aptitude et architecture évolutive.

# A performance scenario expressed as an automated check (illustrative)
# Scenario: at 300 searches/s, p95 <= 400 ms and p99 <= 1000 ms.
import statistics

def check_search_latency(latencies_ms, p95_target=400, p99_target=1000):
    cuts = statistics.quantiles(latencies_ms, n=100)  # 99 cut points
    p95, p99 = cuts[94], cuts[98]
    assert p95 <= p95_target, f"p95 {p95:.0f} ms exceeds {p95_target} ms"
    assert p99 <= p99_target, f"p99 {p99:.0f} ms exceeds {p99_target} ms"
    return p95, p99

# latencies_ms comes from a load test that replays 300 searches per second
# for ten minutes against a production-like environment.

Comment les professionnels utilisent les scénarios

En pratique, les équipes rédigent rarement de longs tableaux de scénarios en six parties pour tout. Elles en écrivent un petit nombre, souvent de dix à trente pour un système d’une certaine taille, pour les qualités qui sont architecturalement significatives, et elles les conservent là où tout le monde peut les voir : dans le document d’architecture (la section 10 d’arc42 demande exactement cela), dans le backlog sous forme de critères d’acceptation, ou sur un tableau partagé des qualités. Certaines équipes utilisent une forme plus courte ; le projet Q42 de Gernot Starke, par exemple, recommande une structure compacte : contexte, déclencheur et critères d’acceptation. La forme compte moins que la discipline : chaque qualité importante a un stimulus, un contexte et un chiffre.

Les scénarios alimentent aussi les méthodes d’évaluation. Le Quality Attribute Workshop et l’Architecture Tradeoff Analysis Method (ATAM), tous deux issus du SEI, recueillent et hiérarchisent des scénarios avec les parties prenantes, puis confrontent l’architecture aux plus importants d’entre eux. La section 2.8 montre comment les scénarios sont recueillis et classés dans un arbre d’utilité.