Testbare Qualitätsszenarien schreiben

Warum Szenarien

Abschnitt 2.2 hat Ihnen das Vokabular der Qualitäten gegeben; dieser Abschnitt gibt Ihnen die Grammatik. Ein Qualitätsname allein, etwa Performance oder Sicherheit, lässt sich weder entwerfen noch testen. Selbst eine Zahl allein genügt nicht: „2 Sekunden“ sagt nichts, solange Sie nicht wissen, für welche Operation, unter welcher Last, wo gemessen und für welchen Anteil der Anfragen. Das Qualitätsszenario, entwickelt am Software Engineering Institute (SEI) und von Len Bass, Paul Clements und Rick Kazman in Software Architecture in Practice beschrieben, löst das, indem es jede Qualitätsanforderung in dieselbe sechsteilige Form zwingt.

Die Idee ist einfach. Jede Qualität zeigt sich, wenn einem System etwas widerfährt: ein Ansturm von Benutzern, ein Absturz, ein Änderungswunsch, ein Angriff. Ein Szenario benennt dieses Ereignis, die Umstände, den betroffenen Teil des Systems, was geschehen soll und woran Sie erkennen, dass es gut genug geschehen ist. Es ist kurz (meist ein bis drei Sätze), konkret und testbar. Und weil jede Qualität dieselbe Form verwendet, können Szenarien für Performance, Sicherheit und Änderbarkeit nebeneinander in einer priorisierten Liste stehen.

Die sechs Teile

Die sechs Teile sind die Quelle des Stimulus, der Stimulus, das Artefakt, die Umgebung, die Antwort und das Antwortmaß. Lernen Sie sie in dieser Reihenfolge, denn zusammen erzählen sie eine kurze Geschichte: Jemand oder etwas tut etwas mit einem Teil des Systems unter bestimmten Bedingungen; das System tut etwas, und wir messen es so. Der Stimulus und das Antwortmaß sind die beiden Teile, die am häufigsten weggelassen werden, und sie sind die beiden wichtigsten.

Die Umgebung verdient besondere Sorgfalt, weil derselbe Stimulus unter verschiedenen Bedingungen ganz unterschiedliche Antworten verlangen kann. Ein abgestürzter Server im Normalbetrieb erfordert vielleicht ein automatisches Failover innerhalb einer Minute; derselbe Absturz während eines geplanten Wartungsfensters kann mit manueller Wiederherstellung akzeptabel sein. Ein Änderungswunsch zur Entwurfszeit (vor dem Release) kostet weit weniger als dieselbe Änderung, wenn sich bereits Daten in der Produktion angesammelt haben. Wer die Umgebung ausdrücklich angibt, verhindert, dass Szenarien verglichen werden, die in Wahrheit unterschiedliche Situationen betreffen.

Das Artefakt zählt aus ähnlichem Grund. „Das System antwortet innerhalb von 200 ms“ verbirgt, welcher Teil verantwortlich ist. Wer das Artefakt benennt (den Suchservice, das API-Gateway, den mobilen Client), sagt dem Team, wo die Entwurfsarbeit und die Messung stattfinden müssen. Bei manchen Qualitäten, etwa Änderbarkeit und Deploybarkeit, kann das Artefakt Code, Konfiguration oder die Delivery-Pipeline sein statt einer laufenden Komponente.

Allgemeine und konkrete Szenarien

Bass, Clements und Kazman unterscheiden zwei Arten. Ein allgemeines Szenario ist systemunabhängig: Für ein Qualitätsmerkmal listet es die typischen Werte auf, die jeder Teil annehmen kann. Für Verfügbarkeit etwa können die Quellen intern oder extern sein, Menschen, Hardware, Software oder Infrastruktur; Stimuli können ein Absturz, eine Auslassung, ein falsches Timing oder eine falsche Antwort sein; Antworten können Erkennen, Protokollieren, Wiederherstellen, Maskieren oder eingeschränkter Betrieb sein; und Maße können die Zeit bis zur Erkennung, die Zeit bis zur Reparatur, der Verfügbarkeitsprozentsatz oder der Anteil der bearbeiteten Anfragen sein.

Ein konkretes Szenario wählt spezifische Werte für ein bestimmtes System: „Die primäre Bestelldatenbank stürzt im Normalbetrieb ab; das Replikat übernimmt, und Schreibvorgänge laufen innerhalb von 60 Sekunden wieder, ohne dass eine bestätigte Bestellung verloren geht.“ Allgemeine Szenarien sind Vorlagen und Checklisten; konkrete Szenarien sind Anforderungen. Mit dem allgemeinen Szenario stellen Sie sicher, dass Sie die richtigen Quellen, Stimuli und Maße bedacht haben, und schreiben dann die Handvoll konkreter Szenarien, auf die es für Ihr System ankommt.

Von vagen Aussagen zu testbaren Szenarien

Die meisten Qualitätsanforderungen beginnen ihr Leben als Adjektive. Die Kunst besteht darin, die Fragen zu stellen, die jedes Adjektiv in ein Szenario verwandeln: Welche Operation? Von wem ausgelöst? Wie oft oder wie viel? Unter welchen Bedingungen? Was soll geschehen? Welche Zahl zeigt uns, dass es funktioniert hat? Die Tabelle zeigt typische Vorher-nachher-Paare. Beachten Sie, dass die „Nachher“-Fassungen manchmal offenlegen, dass der Stakeholder mehrere verschiedene Dinge gemeint hat, die dann zu mehreren Szenarien werden.

Szenariobeispiele für sechs Qualitäten

Die folgenden Beispiele verwenden einen einzigen Onlineshop, damit Sie sehen, wie verschiedene Qualitäten im selben Format aussehen. Jedes ist kompakt geschrieben, mit allen sechs Teilen beschriftet; in der Praxis schreiben Teams sie oft als ein oder zwei Sätze.

Zwei Merkmale dieser Beispiele verdienen Beachtung. Erstens geht es in Szenarien nicht nur um laufende Software. Szenarien zu Änderbarkeit und Deploybarkeit haben Entwickler und Product Owner als Quellen, und ihre Maße sind Aufwand, verstrichene Zeit und Umfang der Änderung. Zweitens verbinden gute Maße oft eine Geschwindigkeitszahl mit einer Korrektheitszahl: „innerhalb von 60 Sekunden“ und „keine bestätigte Bestellung verloren“. Ein schnelles Failover, das Daten verliert, ist nicht das, was das Unternehmen wollte.

Häufige Fehler

Wer Hunderte von Teams geschriebene Szenarien prüft, findet immer wieder dieselben Fehler. Jeder macht ein Szenario untestbar oder irreführend.

Von Szenarien zu Akzeptanztests und Fitness Functions

Ein gut geschriebenes Szenario ist schon der größte Teil eines Tests. Quelle und Stimulus sagen Ihnen, welche Last oder welches Ereignis Sie erzeugen müssen, die Umgebung, wie Sie den Test aufsetzen, das Artefakt, was Sie beobachten müssen, und das Antwortmaß liefert die Bestehensbedingung. Ein Performance-Szenario wird zum Lasttest; ein Verfügbarkeitsszenario wird zur Failover-Übung oder zum Chaos-Experiment; ein Änderbarkeitsszenario wird zur Überprüfung, wie viel Code eine Beispieländerung berührt hat und wie lange sie dauerte; ein Sicherheitsszenario wird zum Testfall eines Penetrationstests.

Der nächste Schritt besteht darin, weiter zu prüfen. Eine Fitness Function, ein Begriff, den Neal Ford, Rebecca Parsons und Patrick Kua in Building Evolutionary Architectures bekannt gemacht haben, ist jede automatisierte oder wiederholbare Prüfung, wie gut das System ein Architekturziel erfüllt. In der Delivery-Pipeline oder gegen Telemetriedaten aus der Produktion ausgeführt, macht sie aus einem Szenario statt eines einmaligen Akzeptanztests einen dauerhaften Wächter: Der Build schlägt fehl oder ein Alarm wird ausgelöst, wenn die Qualität abdriftet. Kapitel 11 behandelt Fitness Functions ausführlich in Fitness Functions und evolutionäre Architektur.

# 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.

Wie Fachleute Szenarien einsetzen

In der Praxis schreiben Teams selten lange Tabellen sechsteiliger Szenarien für alles. Sie schreiben eine kleine Zahl, bei einem größeren System oft zehn bis dreißig, für die architekturrelevanten Qualitäten, und bewahren sie dort auf, wo alle sie sehen: im Architekturdokument (arc42 Abschnitt 10 verlangt genau das), im Backlog als Akzeptanzkriterien oder auf einem gemeinsamen Qualitätsboard. Manche Teams verwenden eine kürzere Form; das Projekt Q42 von Gernot Starke etwa empfiehlt eine kompakte Struktur aus Kontext, Auslöser und Akzeptanzkriterien. Die Form ist weniger wichtig als die Disziplin: Jede wichtige Qualität hat einen Stimulus, einen Kontext und eine Zahl.

Szenarien treiben auch Bewertungsmethoden an. Der Quality Attribute Workshop und die Architecture Tradeoff Analysis Method (ATAM), beide vom SEI, sammeln und priorisieren Szenarien mit den Stakeholdern und prüfen die Architektur dann gegen die wichtigsten. Abschnitt 2.8 zeigt, wie Szenarien in einem Utility Tree gesammelt und gewichtet werden.