Workflow-Testing: Ein vollständiger Leitfaden zum Testen von Geschäftsprozessen

Dieser Leitfaden deckt den Workflow-Testing-Prozess von Ende zu Ende ab: Modellierung von Zuständen und Transitionen, Design von positiven und negativen Cases, Assertion von Checkpoints und Testing von Eskalationsregeln. Zusammen angewendet, geben diese Schritte Ihrem Team messbare Coverage des Prozesses, Branch für Branch.

Workflow-Testing validiert, dass eine vollständige Sequenz von Aktionen das erwartete Geschäftsergebnis liefert. In der Praxis bedeutet das den Beweis, dass Schritte in der richtigen Reihenfolge ablaufen und dass der Workflow den richtigen Endzustand erreicht.

Ein Genehmigungs-Workflow-Test folgt beispielsweise dem Anspruch von der Einreichung bis zur Rückerstattung. Er verifiziert das Routing zum korrekten Manager, die Zustandsänderung bei Genehmigung und einen einzelnen Rückerstattungsdatensatz in der Finanzabteilung.

Übergaben führen eine eigene Defektklasse ein. Ein Feld wird während einer Übergabe umbenannt, oder ein Status kommt an, bevor die zugehörigen Daten existieren. Eine ID kann auch das Format so ändern, dass die nächste Stufe sie nicht parsen kann. Tests auf Komponentenebene erkennen diese Bedingungen nicht, daher deckt Workflow-Testing die resultierenden Integrationsfehler, Berechtigungsübergabefehler und fehlerhafte Branching-Logik auf.

Workflow-Testing liefert den größten Wert, wenn ein Prozess eines der folgenden Elemente enthält:

• Explizite Zustände, wie Draft, Submitted oder Approved
• Geschäftsregeln, wie Betragsschwellen oder rollenbasiertes Routing
• Mehrere Rollen, die Arbeit untereinander weitergeben
• Asynchrone Events, wie Erinnerungen, Eskalationen und Retries
• Mehrere Systeme, einschließlich Microservices und externe APIs

Eine Bestellung kann Tests auf Stufenebene von der Erstellung bis zum Rechnungsabgleich bestehen. Trotzdem scheitert Procure-to-Pay, wenn die Genehmigung Metadaten entfernt, die das empfangende System benötigt.

Die Kosten dieses Musters sind im großen Maßstab dokumentiert. CISQ’s 2022 report beziffert die Kosten schlechter Softwarequalität in den USA auf 2,41 Billionen US-Dollar, mit akkumulierten technischen Schulden nahe 1,52 Billionen US-Dollar.

Die zugrundeliegenden Techniken basieren auf standardmäßigem Testdesign, weshalb ISTQB State-Transition-Testing hier als grundlegend behandelt. Workflows verhalten sich wie Zustandsmaschinen mit erlaubten und verbotenen Transitionen. Decision-Table-Testing gilt, wenn mehrere Bedingungen interagieren, wie Betragsschwellen kombiniert mit rollenbasiertem Routing.

KI-generiertes Bild.

Ein Software-Workflow ist eine strukturierte Sequenz von Zuständen, Aktionen, Entscheidungen und Transitionen, die vom Trigger bis zum Geschäftsergebnis läuft. Er definiert den Pfad, den Daten durch ein System nehmen, einschließlich wer sie berührt, welche Regeln gelten und welche Nebeneffekte folgen.

Trigger → Zustände → Aktionen → Entscheidungen → Transitionen → Nebeneffekte → Geschäftsergebnis

Eine Spesenabrechnung bewegt sich durch Created → Submitted → Manager Review → Finance Review → Reimbursement. Transitionen hängen von Rollen, Berechtigungen und Entscheidungslogik ab. Ansprüche unter 1.000 € benötigen möglicherweise nur die Manager-Genehmigung, während Ansprüche über diesem Schwellenwert Finance in die Kette ziehen. Über 10.000 € könnte ein Director in die Genehmigungskette eintreten.

Zwei Eigenschaften machen Workflows schwerer zu testen als einzelne Features.

Workflows umspannen Microservices, Anwendungen und Mensch-zu-automatisierte Schritte, sodass jede Grenze einen potenziellen Fehlerpunkt einführt:

• Umbenannte oder neu gemappte Felder
• Nicht übereinstimmende Datenformate oder Kodierungen
• Asynchrones Timing zwischen Stufen

Ihr Modell muss deklarieren, welche Transitionen verboten sind: Draft zu Paid ohne Genehmigung, rejected zu fulfilled ohne Wiedereröffnung. OWASP behandelt Umgehung von Workflows als Business-Logic-Sicherheitsproblem, sodass ein Endpoint, der Identity-Verification-Anforderungen umgehen lässt, eine Schwachstelle darstellt.

Workflow-Tests werden üblicherweise nach Ausführungsebene klassifiziert, und vier gängige Typen sind auf die meisten Implementierungen anwendbar.

Die meisten Implementierungen sind hybrid, sodass der Testing-Workflow mehrere Ebenen kombiniert. API-Level-Runs decken den Großteil der Branches, Rejection-Paths und Retries ab, da sie in Sekunden ausführen und trotz UI-Änderungen stabil bleiben. Ein begrenztes Set von UI-Runs verifiziert, dass Bildschirme den korrekten Zustand widerspiegeln. Manuelles Testing gilt, wo sich ein Workflow weiterhin häufig ändert, da das Scripting eines Prozesses, der sich wöchentlich ändert, mehr kostet als seine manuelle Ausführung. Alle drei Ebenen in einem Repository zu halten, wie es Plattformen wie aqua cloud tun, reduziert doppelte Coverage.

Der Workflow-Testing-Prozess läuft in acht Schritten ab, von einem expliziten Modell über Case-Design, Ausführung bis zu permanenter Regressions-Coverage.

Workflow-Testing beginnt mit einem expliziten Modell, da ein BPMN-Diagramm, Zustandsdiagramm oder einfaches Flussdiagramm alle gleich gut dienen. Unabhängig vom gewählten Format dokumentiert das Modell Ihren Entry-Point, Aktionen, Entscheidungen, Zustände und Exits. System- und menschliche Übergaben werden ebenfalls darauf aufgezeichnet.

Ohne ein explizites Workflow-Modell schreibt Ihr Team Cases um einzelne Bildschirme herum und lässt den zugrundeliegenden Prozess ungetestet. ISTQB Model-based-Testing-Guidance integriert bereits State-Transition-, Decision-Table- und Use-Case-Techniken, sodass Workflow-Modellierung etablierte Methoden auf Geschäftsprozesse anwendet. Das resultierende Modell definiert dann den Umfang der Coverage.

Mapping erzwingt auch Gespräche mit Stakeholdern, weshalb das Modell neben Ihren Requirements-Management-Aufzeichnungen gehört. Meinungsverschiedenheiten über den Prozess werden im Diagramm sichtbar, bevor sie in Testergebnissen erscheinen.

Alle erdenklichen Workflows mit gleicher Tiefe zu testen ist unrealistisch, priorisieren Sie also nach Geschäftsauswirkung und Risiko. Priorisierte Workflows fallen in einige Kategorien:

• Account-Lifecycle, wie Registrierung und Account-Recovery
• Revenue-Pfade, wie Checkout und Subscription-Renewal
• Zahlungsabwicklung und Reconciliation
• Cross-Application-Prozesse in ERP- oder Supply-Chain-Systemen

Priorisierung kann auf drei Kriterien basieren:

• Failure-Cost: wie viel Schaden ein defekter Run verursacht
• Business-Exposure: Umsatz, Compliance oder Kundenvertrauen auf dem Spiel
• Komplexität: externe Integrationen und mehrere Rollen in der Kette

Das gleiche Ranking leitet die Automatisierung. Stabile, repetitive, hochwertige Workflows sind starke Automatisierungskandidaten, während sich häufig über Sprints ändernde Flows übermäßigen Wartungsaufwand erzeugen.

Ein explizites Zustandsmodell ersetzt ein generisches Ticket wie „Test expense approval“:

Draft → Submit → Pending Manager Approval → Approve → Pending Finance → Approve → Approved for Reimbursement → Payment Completed → Paid

Alternative Transitionen erfordern die gleiche Behandlung, da Manager-Rejection, Mitarbeiter-Stornierung und Finance-Requests für weitere Informationen alle einen dokumentierten Pfad benötigen. Diese Struktur macht Coverage-Gaps sofort sichtbar: ein Modell mit zehn Transitionen gegen eine Suite, die drei abdeckt, identifiziert die verbleibende Arbeit.

State-Modellierung richtet auch Ihre negativen Tests ein, da eine Zustandsmaschine den Beweis benötigt, dass verbotene Transitionen abgelehnt werden.

Geschäftsregeln mappen auf Condition-Sets, die sich dann in Testfälle umwandeln. Die drei Genehmigungsstufen produzieren mehrere Condition-Sets, bevor Exception-Paths hinzugefügt werden.

Decision-Tables eignen sich gut für diese Arbeit, weil die Anzahl der Kombinationen schnell wächst, sobald mehrere Bedingungen interagieren. In einer Tabelle ausgelegt, enthüllen diese Kombinationen zuvor nicht abgedeckte Condition-Sets.

Branches umfassen auch Exception-Paths: Integrations-Timeouts, Genehmigungen, die nie ankommen, und zwei Manager, die gleichzeitig genehmigen. Diese alternativen Routen sollten unabhängig getestet werden, da sie selten im Happy-Path-Modell erscheinen.

Der positive Test verifiziert, dass der Workflow abgeschlossen werden kann. Negative Tests sollten dann sechs Kategorien abdecken:

• Eine erforderliche Stufe überspringen
• Eine Stufe wiederholen, die einmal laufen soll
• Schritte außerhalb der Reihenfolge ausführen
• Mit der falschen Rolle handeln
• Ungültige Daten zwischen Stufen senden
• Auf halbem Weg abbrechen

OWASP empfiehlt zu testen, ob Benutzer Aktionen überspringen, wiederholen oder neu anordnen können. Dokumentierte Muster umfassen einen Benutzer, der den Account-Opening-Endpoint ohne Identity-Verification erreicht, und einen Kunden, der denselben Single-Use-Discount zweimal anwendet.

Negative Coverage erstreckt sich auf Failure-States. Nach einer fehlgeschlagenen Zahlung sollte eine Bestellung nicht unbegrenzt in „Processing“ verbleiben, und ein nicht verfügbarer externer Service sollte ein sauberes Timeout produzieren.

Ein Workflow modifiziert Daten im Laufe der Zeit, sodass statische Datasets unzureichend sind. Datasets müssen Initial State → Intermediate State → Final State widerspiegeln. Sie sollten auch die Grenzen um jede Genehmigungsschwelle herum abdecken, sodass 1.000 € und 10.000 € beide Werte auf beiden Seiten benötigen.

Realistische Kombinationen sind genauso wichtig wie realistische Werte, da die Anzahl der Positionen und die Rolle des Einreichers beide das Routing ändern.

Edge-Cases fallen in dieselbe Kategorie. Zero-Value-Transaktionen, negative Mengen und fehlende optionale Felder qualifizieren sich alle als Workflow-Tests, wenn sie Routing oder Downstream-Integrationen beeinflussen.

Assertions laufen bei Zwischenstufen der Ausführung, vor dem finalen Bildschirm. Checkpoint-Assertions decken fünf Elemente ab:

• State: der Datensatz hält den erwarteten Status
• Daten: Feldwerte blieben über die Übergabe hinweg intakt
• Rolle und Owner: der korrekte Akteur hält das Item
• Integrationsergebnis: der Downstream-Call gab die Daten zurück, die die nachfolgende Stufe benötigt
• Nebeneffekt: die Zahlung, Benachrichtigung oder Inventory-Änderung ist tatsächlich passiert

Wenn ein 25-Schritte-Workflow am Ende fehlschlägt, identifizieren Checkpoint-Daten die Transition, die den Defekt eingeführt hat. Checkpoints decken auch ein häufiges False-Positive auf, wo die UI „Success“ meldet, während die Geschäftsaktion nie stattfand. Bei flaky Tests zeigen dieselben Daten, wo die Race-Condition entsteht, was wiederholte Ausführungen zur Reproduktion vermeidet.

Jeder Workflow-Fehler, der die Produktion erreicht, sollte in ein permanentes Regressions-Szenario umgewandelt werden. Im Laufe der Zeit dokumentiert die Suite dann sowohl beabsichtigtes Verhalten als auch die Edge-Cases, die zuvor Fehler verursacht haben.

Jeder Workflow-Fehler, der die Produktion erreicht, sollte in ein permanentes Regressions-Szenario umgewandelt werden. Im Laufe der Zeit dokumentiert die Suite dann sowohl beabsichtigtes Verhalten als auch die Edge-Cases, die zuvor Fehler verursacht haben.

Über Defektprävention hinaus bewahrt Regressions-Coverage organisatorisches Wissen. Wenn ein Entwickler Ihr Team verlässt, behält die Suite beispielsweise den Kontext hinter diesen Szenarien. Neue Mitglieder können dann die Tests lesen, um zu verstehen, wie sich der Workflow verhalten sollte. Ausführbare Coverage dieser Art bewahrt Verhalten zuverlässiger als Dokumentation, die neben der Implementierung ungewartet bleibt.

Diese Best Practices für Workflow-Testing reduzieren Nacharbeit, während eine Suite auf Release-Kadenz ausführbar bleibt.

Produktions-Workflows enthalten Decision-Points, Fallbacks und alternative Routen. Eine Spesenabrechnung kann durch Manager-Genehmigung, Manager plus Finance oder alle drei Stufen laufen, und eine Zahlung kann erfolgreich sein, retry oder dauerhaft fehlschlagen. Wenn ein Modell zehn Pfade dokumentiert und die Suite zwei abdeckt, erreichen die verbleibenden acht die Produktion ungetestet.

Eine Bestätigungsseite liefert keinen Beweis, dass eine Zahlung erfasst, Inventory reduziert oder eine Benachrichtigung gesendet wurde. Zuverlässige Assertions lesen den zugrundeliegenden Datensatz: eine Datenbankabfrage, einen Audit-Log-Eintrag, eine Integrationsantwort oder eine zugestellte E-Mail. Schwächere Assertions produzieren ein False-Positive, wo der Run besteht, obwohl die Geschäftsaktion nie stattfand.

Gültige Transitionen erhalten ihre eigenen Cases, und verbotene erhalten Cases, die die Ablehnung beweisen. Weil sich ein Workflow wie eine endliche Zustandsmaschine verhält, wird N-1-Switch-Coverage über die Transitionstabelle messbar. State-basiertes Design deckt auch Cases ab, die Ad-hoc-Testdesign oft vermisst.

Betragsschwellen, Benutzerrollen, Zeitfenster und Inventory-Levels interagieren kombinatorisch, sodass das Regelset schneller wächst als manuelles Case-Design verfolgen kann. Eine Decision-Table listet die Condition-Action-Paare systematisch auf, und ISTQB empfiehlt die Technik genau aus diesem Grund.

Workflows modifizieren Datensätze über Stufen hinweg, sodass Datasets Werte auf beiden Seiten einer Regel benötigen. Ein 999-€-Anspruch und ein 1.001-€-Anspruch trainieren verschiedene Branches, wenn 1.000 € die Genehmigungsschwelle setzt, sodass Boundary-Value-Analysis Teil der Workflow-Datenvorbereitung wird.

Assertions zu State, Daten und Nebeneffekten gehören ans Ende einer Stufe sowie ans Ende eines Runs. Checkpoint-Daten identifizieren dann direkt die fehlerhafte Transition, was schneller ist als eine vollständige Sequenz nach dem finalen Bildschirm zu bisezieren.

Lange UI-Scripts sind wartungsintensiv, sodass eine Layered-Automation-Strategie diesen Overhead reduziert:

• Layer 1, Business- und State-Rules: schnelle Tests nah am Code
• Layer 2, Orchestrierung mit gemockten Dependencies: Branching, Retries und Timeout-Verhalten
• Layer 3, echte API- und Integrationsgrenzen: Auth, Contracts, Daten und externes Verhalten
• Layer 4, UI-Workflow: nur die hochwertigsten User-Journeys

Workflow-Engines dokumentieren dieselbe Trennung. Conductor deckt Definitions-Validation ab, dann Orchestrierung gegen gemockte Tasks, dann echte Ausführung gegen Workers. Ähnlich unterstützt Microsoft Logic Apps gemockte Trigger und Actions, sodass ein Workflow-Ergebnis unabhängig assertiert werden kann.

Erinnerungen nach 24 Stunden, Eskalationen nach 48 Stunden und Ablauf nach 30 Tagen sind in Echtzeit unpraktisch zu testen. Temporal bietet Workflow-Testumgebungen, die Zeit automatisch vorspulen. Microsoft Power Automate unterstützt auch statische Outputs, sodass verzögerte Action-Ergebnisse innerhalb eines normalen Runs testbar werden.

Single-Use-Discounts, die zweimal angewendet werden, und selbstgenehmigte eingeschränkte Requests sind Sicherheitsdefekte, sodass Workflow-Testing funktionales QA und Business-Logic-Security umspannt. Security Magazine bemerkte, dass die CISQ-Gesamtsumme Verluste durch Cyberangriffe gegen Schwachstellen umfasst, die bereits im Produktionscode vorhanden sind.

Eine Test-Management-Lösung zeichnet auf, welche Business-Requirement ein Test validiert, welche Variationen abgedeckt sind und ob das Release bereit ist. Ohne diese Verbindung bleiben Coverage-Fragen und Post-Change-Impact-Analysen unbeantwortbar.

Spesengenehmigung ist das laufende Beispiel für diesen Leitfaden, da es drei Genehmigungsstufen, zwei Reviewer-Rollen und eine Audit-Anforderung umfasst. Der Workflow läuft von Mitarbeiter-Einreichung über Manager-Review, optionalem Finance-Review, Zahlung und Benachrichtigung.

Sechs Szenarien unten decken die höchstpriorisierten Pfade ab.

Szenario 6 erfordert einen Workaround, da 72 Stunden während der Regressions-Ausführung zu warten unpraktisch ist. Entweder eine Time-Skipping-Umgebung oder ein verkürzter Timer in einer kontrollierten Umgebung gibt Ihnen dieselbe Coverage in Sekunden.

Über alle sechs Szenarien hinweg prüft die Assertion das aufgezeichnete Ergebnis in der Datenbank und dem Audit-Log.

KI-generiertes Bild.

Positive Tests verifizieren, dass der Workflow unter gültigen Bedingungen abgeschlossen wird. Negative Cases zielen hingegen auf die teureren Produktionsdefekte ab: umgangene Genehmigungen, Doppelzahlungen und beschädigte Übergabedaten.

Positive Cases folgen den beabsichtigten Pfaden:

• Eine Spese bewegt sich von Draft zu Submitted zu Approved zu Paid
• Eine Bestellung läuft von Created zu Approved zu Received zu Invoiced
• Ein Support-Ticket wandert von Open zu Assigned zu Resolved zu Closed

Verifikation in allen dreien deckt Datenintegrität, Rollenberechtigungen und die erwarteten Nebeneffekte ab.

Negative Cases decken Aktionen ab, die der Workflow nicht akzeptieren sollte, und strukturiertes Test-Case-Management hält beide Sets mit demselben Workflow-Modell verknüpft.

Für eine vollständige Spesengenehmigungssuite würden Ihre positiven Cases 100-€-, 5.000-€- und 15.000-€-Ansprüche über die drei Genehmigungsstufen abdecken. Ihre negativen Cases würden Selbstgenehmigung, übersprungene Manager-Genehmigung, fehlenden Beleg, negativen Betrag, Bearbeitungen an bezahltem Anspruch und doppelte Genehmigungsversuche abdecken. Kombinierte Coverage verifiziert, dass das System unter korrekter Nutzung funktioniert und unter inkorrekter Nutzung sicher fehlschlägt.

Workflow-Testing ist eine geschäftsprozessfokussierte Form des End-to-End-Testings. Die Terminologie überlappt stark in der Branche, und keine universelle Definition trennt die beiden sauber, sodass der praktische Unterschied im Fokus liegt.

End-to-End-Testing bestätigt, dass ein System von Anfang bis Ende über den gesamten Stack hinweg funktioniert, von UI bis Datenbank. Ein typischer E2E-Test führt einen Kunden durch den Checkout, vom Warenkorb zu Versanddetails, Zahlung, Bestellbestätigung und der Bestätigungs-E-Mail.

Workflow-Testing konzentriert sich speziell auf Prozesslogik. Ein Workflow-Test des Checkouts deckt Gast- und registrierte Benutzer, Split-Payments, nicht vorrätigen Artikel und internationalen Versand ab, wobei jeder Decision-Point korrekt routet.

Die folgende Tabelle zeigt, wie sich die vier verwandten Praktiken unterscheiden.

Workflow-Integrationstests liegen zwischen den beiden. Es kombiniert individuelle Service-Integrationen und erweitert sie mit State-Management, Decision-Logik und Rollendurchsetzung.

ISTQB definiert Workflow-Testing nicht als separates Test-Level, behandeln Sie es also als Design-Linse für E2E-Coverage. Anwendungen, die hauptsächlich aus zustandslosen CRUD-Operationen bestehen, gewinnen wenig daraus. Im Gegensatz dazu erhalten Systeme, die mehrstufige, mehrrollige Prozesse orchestrieren, eine klarere Coverage-Struktur.

Verteilte Architekturen und automatisierte Entscheidungsfindung haben zwei spezialisierte Varianten des Workflow-Testings hervorgebracht: API-Workflow-Testing und KI-Workflow-Testing.

API-Workflow-Testing validiert Geschäftsprozesse, die über mehrere Endpoints und Services hinweg ausgeführt werden. Ein Order-Fulfillment-Workflow könnte Inventory-Check, Payment-Processing, Warehouse-Allocation, Shipping-Label-Generierung und Notification-Services nacheinander aufrufen. Ihre Tests bestätigen, dass diese Services kooperieren, konsistenten State über verteilte Transaktionen halten und sauber degradieren, wenn ein Service oder eine Dependency nicht verfügbar wird.

Dependency-Management erzeugt hier die meiste Schwierigkeit. Statuscodes allein verifizieren nur einen Bruchteil des Prozesses, sodass Ihre Assertions Folgendes abdecken müssen:

• Daten, die korrekt zwischen Services fließen
• Asynchrone Operationen, die in der richtigen Reihenfolge abgeschlossen werden
• Retries, die keine doppelten Aktionen produzieren
• Kompensierende Transaktionen, die nach einem Fehler ausgeführt werden

Contract-Testing verifiziert, dass ein Service seine Interface-Commitments einhält. API-Workflow-Testing erweitert dies, indem es die Orchestrierungslogik validiert, die diese Services zusammenbindet.

KI-Workflow-Testing adressiert Workflows, die Machine-Learning-Modelle oder Rule-Engines beinhalten. Traditionelles Workflow-Testing nimmt deterministisches Verhalten an, während KI-Komponenten probabilistische Outcomes, sich entwickelnde Modelle und kontextabhängige Entscheidungen einführen, die feste Assertions unzuverlässig machen.

Ein Kundenservice-Workflow könnte Tickets mit einem KI-Classifier routen. Über die Bestätigung hinaus, dass hochprioritäre Tickets Senior-Agents erreichen, erstreckt sich die Validierung auf die Confidence-Thresholds des Classifiers und Fallback-Verhalten. Unsichere Cases müssen auf einen definierten Handling-Pfad zurückfallen, und Model-Drift darf die Routing-Regeln nicht ungültig machen.

Testing von KI-gestützten Workflows erfordert zusätzliche Techniken:

• Shadow-Testing zum Vergleich von KI-Entscheidungen mit bekannten Outcomes
• Canary-Deployments zur Validierung von Modelländerungen vor vollständigem Rollout
• Drift-Monitoring zur Erkennung von Prediction-Änderungen, die Workflow-Verhalten ändern
• Fallback-Testing zur Bestätigung graceful Degradation, wenn KI-Komponenten fehlschlagen

Beide Varianten hängen stark von Observability ab. Ein fehlgeschlagener verteilter Workflow benötigt Tracing, um den verantwortlichen Service zu identifizieren, während unerwartete KI-Entscheidungen geloggte Inputs und Confidence-Scores benötigen. Aus diesem Grund ist Checkpoint-Validation hier noch wichtiger. Teams in regulierten Umgebungen führen auch einen Penetration-Testing-Workflow gegen dieselben Endpoints durch.

Ein Workflow-Test bestätigt, dass ungültige Transitionen abgelehnt werden und dass Nebeneffekte genau einmal auftreten. Das Audit-Trail muss auch dem entsprechen, was in der Datenbank passiert ist.

Ein zuverlässiger Workflow-Testing-Prozess beginnt mit einem expliziten Modell. Cases folgen dann den Zuständen und Branches, Outcomes werden an Checkpoints validiert, und Produktionsfehler werden zur Regressions-Suite hinzugefügt. Teams, die mehrstufige, mehrrollige Prozesse betreiben, profitieren am meisten, da ihre Defekte sowohl funktionale als auch sicherheitsrelevante Konsequenzen tragen.