Qualitätsmanagement ist Risikomanagement

In meinem vorherigen Blog habe ich darüber geschrieben, wie das Scheitern eine sinnvolle Strategie sein kann, abhängig von der aktuellen Qualitätsstufe. Bevor wir dieses Qualitätsniveau bestimmen können, müssen wir zunächst verstehen, was Qualität ist, und uns die Frage stellen, warum wir überhaupt Qualität wollen.

Über das Konzept der Qualität sind viele Bücher geschrieben worden und die Wikipedia-Seite über Qualität bietet die folgende Zusammenfassung:

"Qualität ist eine wahrnehmbare, bedingte und etwas subjektive subjektiv Attribut und kann von verschiedenen Menschen unterschiedlich verstanden werden. Die Verbraucher können sich auf die Spezifikationsqualität eines Produkts/einer Dienstleistung, oder wie es im Vergleich zu den Wettbewerbern auf dem Markt abschneidet. Produzenten könnten die Konformitätsqualitätoder der Grad, in dem das Produkt/die Dienstleistung korrekt hergestellt wurde. Das Supportpersonal kann die Qualität daran messen, inwieweit ein Produkt zuverlässig, wartbaroder nachhaltig."

Diese unterschiedlichen Wahrnehmungen in Einklang zu bringen, scheint eine Herausforderung zu sein. Wie also bestimmen wir, welches Maß an Qualität erforderlich ist? Wie legen wir die Messlatte für "das wäre für den Moment genug Qualität" fest?

Risikominderung

Wenn Sie beginnen, die verschiedenen Standpunkte zu analysieren, wird deutlich, dass sie eine Gemeinsamkeit haben: Sie alle zielen darauf ab, ein bestimmtes Risiko auf einem bestimmten Niveau zu halten. Sie wollen wissen, wie gut Ihr Produkt funktioniert, um zu verhindern, dass Ihnen die Kunden weglaufen. Sie wollen Einblicke in Ihre betriebliche Leistung haben, um einen Konkurs zu verhindern. Sie wollen die Effektivität Ihrer Prozesse kennen, um Geldstrafen zu vermeiden.

Das Risikomanagement kann dabei helfen. Das Konzept des Risikomanagements wird in verschiedenen ISO-Normen (z.B. 9001, 14001, 27001, 22301) erwähnt, aber sie alle verwenden ähnliche Strategien zum Umgang mit Risiken. Im Allgemeinen können Sie sie in vier Kategorien zusammenfassen:

• Vermeiden Sie: Dies ist die strengste der Optionen zur Risikobehandlung. Sie verlangt von den Unternehmen, dass sie alle Aufgaben oder Prozesse, die ein Risiko darstellen, einstellen. In der Softwareentwicklung kann man dies mit "verhindern, dass Fehler in die Codebasis gelangen" übersetzen. Das bedeutet, dass Sie beschließen, eine Funktion nicht zu bauen, da das Verhältnis zwischen Risiken und Nutzen nicht ausgewogen ist, oder Sie stellen sicher, dass die Funktion genau das tut, was sie soll. Ein Beispiel für die erste Kategorie wäre ein Team, das während der Verfeinerung unlösbare Probleme feststellt , oder die Erkenntnis, dass der Wert der Funktion abgenommen hat. Ein Beispiel für die zweite Kategorie wäre der Test - getriebene Entwicklung, bei der ein Testfall erstellt wird, bevor der Code entwickelt wird, und die Tests erfolgreich sein müssen, bevor der Code eingereicht werden kann. Dies bietet eine sehr hohe Testabdeckung, erfordert aber mehr Aufwand bei der Entwicklung.
• Reduzieren Sie: Die Verringerung eines Risikos bedeutet, dass es entweder weniger wahrscheinlich ist, dass es eintritt, oder dass es weniger Schaden anrichtet, wenn es eintritt. Bei der Softwareentwicklung geschieht dies meist durch die Ausführung von Testfällen gegen funktionalen und implementierten Code. Da die Abdeckung vom Umfang der Testfälle abhängt und die Ausführungszeit mit der Größe des Testsatzes wächst, liegt der Schwerpunkt darauf, die Probleme mit den größten Auswirkungen zuerst zu identifizieren.
• Aktie (oder Übertragung): Diese Option bedeutet, dass Sie das Risiko - entweder teilweise oder ganz - auf eine andere Partei übertragen. Die extremste Form wäre der Kauf einer Versicherungspolice, aber innerhalb der Softwareentwicklung kann dies auch durch die Verlagerung von Aktivitäten aus der Entwicklung in den Betrieb umgesetzt werden. Aktivitäten wie Überwachung und SLAs fallen in diese Kategorie.
• Behalten (oder akzeptieren): Die letzte Option, die Beibehaltung des Risikos, bedeutet, dass Sie das Risiko akzeptieren, ohne etwas dagegen zu unternehmen. Dies bedeutet, dass Sie davon ausgehen, dass das System korrekt ist, bis das Gegenteil bewiesen ist. Aus Sicht der Qualität geht es dabei vor allem darum, sicherzustellen, dass Abweichungen so schnell wie möglich abgemildert werden können.

Gestaltung Ihrer Qualitätsstrategie

Um Risiken zu verringern, führen wir die Qualitätssicherung ein. Die Qualitätssicherung kann daher als ein Prozess des Risikomanagements betrachtet werden, und der Aufwand für Qualität ist in der Tat eine Strategie zur Risikominderung. Wenn wir die Strategien des Risikomanagements verstehen, können wir eine Qualitätsstrategie entwickeln.

Wie können Sie also feststellen, welche Qualitätsstrategie Sie anwenden sollten, wenn Sie sich mit den zugrunde liegenden Risiken befassen?

Die Entscheidung, welche Strategie Sie verwenden, hängt von Ihrer Risikobereitschaft für ein bestimmtes System oder eine bestimmte Funktion ab und davon, wie viel Sicherheit Sie bereits haben. Risikoprofile können auch auf mehreren Ebenen angewendet werden. Einige Systeme sind kritischer als andere, aber selbst innerhalb dieser Systeme gibt es wahrscheinlich Komponenten mit unterschiedlichen Risikoprofilen.

Die Wahl einer Strategie, die weniger Sicherheit bietet (d.h. mehr Risiko zulässt), wird dazu führen, dass mehr Abweichungen nicht so früh wie möglich erkannt werden, aber wenn Sie Ihr Risikoprofil richtig einschätzen, ist das möglicherweise kein Problem. Da Sie nur einmal eine Stunde oder einen Euro aufwenden können, müssen Sie entscheiden, wo Sie die besten Ergebnisse erzielen.

Ein Beispiel für eine risikobasierte Qualitätsstrategie auf hohem Niveau ist die folgende:

• Vermeiden - Testgetriebenes Design, um sicherzustellen, dass Probleme gar nicht erst im Produkt landen
• Reduzieren - Testautomatisierung, um sicherzustellen, dass problematische Probleme im Produkt identifiziert werden, bevor sie in die Produktion gelangen

• Monitor - Funktionale Überwachung, um sicherzustellen, dass Probleme in der Produktion erkannt werden, bevor sie sich auswirken.
• Accept - Incident Response, um sicherzustellen, dass Probleme in der Produktion entschärft werden, wenn sie sich auswirken

Abbildung 1: Beispiel für die Verknüpfung von Risikomanagement und Qualitätsstrategie

Risiko ist nicht statisch, Qualität ist granular

Wenn das Risikoprofil eines Systems, oder die Gewissheit darüber ändert, kann sich auch die beste Qualitätsstrategie ändern. In Situationen mit hohem Risiko und geringer Gewissheit sollten Sie mehr Aufwand in die Qualität investieren und sich für einen stark präventiven Ansatz wie das testgetriebene Design entscheiden. Wenn Sie mehr Gewissheit über die Lösung haben, können Sie sich für weniger präventive Strategien wie die klassische Testautomatisierung oder auch nur die Überwachung Ihres Systems auf Probleme entscheiden. Per Definition ist eine Strategie also nicht statisch, sondern sollte vielmehr als Leitfaden dienen.

Nehmen wir ein fiktives Beispiel für die Entwicklung eines Produkts, das Risikoprofil in jeder Phase und die passende Qualitätsstrategie für diese Situation:

1. Ein neues Geschäft- Eine kritische Anwendung wird von Grund auf mit neuen Technologien entwickelt. Da das Team nur wenig Erfahrung mit der Technologie hat und viel auf dem Spiel steht, beschließen sie, testgetriebene Entwicklung zu verwenden, um ein Höchstmaß an Sicherheit zu gewährleisten.
2. Später beschließt das Team, zusätzliche Integritätsprüfungen in den Kerndienst einzubetten. Dadurch wird das Risiko der Anwendung verringert, aber da es sich um eine weitere neue Technologie handelt, beschließt das Team, mit TDD fortzufahren.
3. Eine der risikoreichsten Komponenten soll zu einem bekannten Anbieter migriert werden, um das Gesamtrisiko der Anwendung zu verringern. Da dieser Dienst über eine umfangreiche Dokumentation und Testmöglichkeiten verfügt, beschließt das Team, eine Reihe von Basistests durchzuführen und mit der Funktionsüberwachung zu beginnen.
4. Aufgrund der guten Erfahrungen mit dem externen Anbieter beschließen sie, weitere Dienste mit diesem zu verbinden. Da dies mehr Risiken für Betrug birgt, beschließt das Team, die Testsuite zu erweitern und so viele betrügerische Beispiele wie möglich zu verifizieren.
5. Der externe Anbieter geht zu einer SaaS-Lösung über, die in der Lage ist, Transaktionen in größerem Umfang zu verifizieren. Dies wird die Betrugsmöglichkeiten verringern, aber das Team muss alle Schnittstellen umstellen. Auch hier beschließen sie, die Testsuite zu erweitern, um alle Transaktionen ordnungsgemäß zu überprüfen.
6. Aufgrund der guten Erfahrungen mit der SaaS-Lösung beschließt das Team, weitere Funktionen auf die Lösung zu übertragen. Da die riskantesten Transaktionen bereits ordnungsgemäß getestet sind , beschließt das Team, das Dashboard für die Funktionsüberwachung zu erweitern.
7. Alle Transaktionen wurden nun in die SaaS-Lösung verlagert und die funktionale Überwachung wird zur Überwachung aller Transaktionsarten eingesetzt. Das Team beschließt, keine Zeit mehr für Tests aufzuwenden und bei Bedarf Incident Management zu betreiben.

Abbildung 2: die Reise zum Risikoprofil

Linksverschiebung ist kontinuierliches Risikomanagement

Die Verwaltung dieser verschiedenen Aspekte ist im Bereich der Qualitätssicherung nicht neu. Ansätze wie das risikobasierte Testen gibt es schon seit einiger Zeit und können dabei helfen, schnell die effektivste Strategie für eine bestimmte Komponente oder ein System zu ermitteln.

Die Linksverschiebung erfordert, dass wir mit einem kontinuierlichen Risikomanagement beginnen. Die Bestimmung des genauen Risikoprofils kann mit Techniken erfolgen wie Risiko-Stürmung oder Bedrohungsmodellierung. Ein genaues Risikoprofil ermöglicht es, die am besten geeignete Qualitätsstrategie zu bestimmen und Ihren Qualitätssicherungsprozess bei Bedarf anzupassen. Die Verwendung des optimalen Qualitätssicherungsprozesses verhindert eine "Überbearbeitung" und "vergoldete Technik" und stellt sicher, dass Ihr Qualitätssicherungsprozess dem Risikoprofil entspricht.