Man kann niemals allestesten , daher müssen Sie sich überlegen, welche geschäftlichen Risiken in Ihrem Entwicklungsprojekt bestehen. Auf dieser Grundlage können Sie die Reihenfolge der Tests planen, festlegen, wie Sie die mit den Tests verbundenen Risiken minimieren, und die Tests so priorisieren, dass Sie die kritischsten zuerst testen. Ihre Teststrategie hat dann dieselbe geschäftliche Priorität, die für das gesamte Entwicklungsprojekt maßgeblich ist. In diesem Blogbeitrag beschreibe ich, wie Sie beim risikobasierten Testen vorgehen sollten.
Es gibt eine geschäftliche Perspektive darauf, wie wichtig das Testen ist. Auch die Branche, in der Ihr System entwickelt wird, spielt eine wichtige Rolle. Wenn Ihr Projekt beispielsweise in den Bereichen Bankwesen, Versicherungen, Medizintechnik oder bei Behörden angesiedelt ist, hat das Unternehmen den Ruf, dass alles einwandfrei funktionieren muss. Selbst wenn es sich bei dem Fehler nur um einen Rechtschreibfehler handelt, kann dies das Vertrauen in das gesamte Unternehmen untergraben. In anderen Fällen kann es für das Unternehmen , für dasSie arbeiten,von größter Bedeutung sein , ein Produkt vor allen anderen auf den Markt zu bringen, sodass es für das Unternehmen durchaus akzeptabel sein kann, dass die erste Version des Produkts einige Fehler enthält. In allen Projekten gibt es in der Regel einen Zielkonflikt zwischen Zeit, Kosten und Qualität. Wenn Sie der Qualität Vorrang einräumen, wirkt sich dies auf Zeit und Kosten aus. Ist Zeit am wichtigsten, werden Kosten und Qualität beeinträchtigt.
Mit anderen Worten: Zeit-, Kosten - und Qualitätsfaktoren sind ebenfalls wichtige Parameter für Ihre Testplanung. Es besteht tatsächlich die Möglichkeit, dass Sie im Verhältnis zur Gesamtpriorität des Projekts „zu viel“ testen. Dies ist wichtig, damit die Testbemühungen auf dasselbe Ziel ausgerichtet sind, an dem das gesamte Projekt gemessen wird. Wenn Sie Ihre Tests planen, erstellen Sie Ihre Testfälle, Testszenarien oder die Voraussetzungen für explorative Tests und erhalten eine Liste aller zu testenden Elemente. Doch nicht alle Tests sind gleich wichtig; es gibt immer Funktionen im System, die viele Male ausgeführt werden, während andere Funktionen seltener zum Einsatz kommen. Es gibt auch andere Faktoren, die bestimmen, ob eine Funktion im System mehr oder weniger Tests erfordert . Wie komplex eine Funktion hinsichtlich der Anforderungen und der Entwicklung ist, hat großen Einfluss auf Ihre Priorisierung der Tests.
Ein risikobasierter Test basiert auf einer Risikoanalyse, die sich in der Regel darauf stützt, was innerhalb einer bestimmten Testebene – zum Beispiel im Systemtest oder innerhalb eines Sprints – getestet werden soll. Die Art der von Ihnen gewählten Risikoanalyse ist nicht besonders wichtig; entscheidend ist vielmehr, dass Sie die Wahrscheinlichkeit und Konsistenz der vom Projekt ausgewählten Aspekte berücksichtigen, wie z. B. geschäftskritische Aspekte, komplexe Implementierung, komplexe Daten und mehr. Berücksichtigen Sie außerdem die oben genannten Faktoren Zeit, Kosten und Qualität.
Eine risikobasierte Testanalyse kann auf verschiedene Artendurchgeführt werden ; hier ist ein Vorschlag, der zeigt, wie Sie dabei vorgehen können. Möglicherweise passt dieser nicht genau zu Ihnen und Ihrem Projekt, aber wir geben Ihnen einige nützliche Tipps, die Sie nutzen können.
1. Ernennen Sie eine Person zum Risikomanager, der die risikobasierte Testanalyse durchführt – vorzugsweise den Testleiter.
2. Zunächst müssen die Risiken im Rahmen des Auftrags identifiziert werden. Dies kann auf klassische Weise mithilfe von „gelben Notizzetteln“ erfolgen. Oder warum nicht Mind Mapping nutzen, bei dem Sie Risiken – hohe und niedrige – notieren? Dies geschieht am besten in einer Gruppe, zum Beispiel in einem Gemeinschaftsraum, damit Sie sich gegenseitig inspirieren, kreativer werden und über den Tellerrand hinausdenken können.
3. Wenn die Erfassung der Risiken abgeschlossen ist, müssen diese gruppiert werden, was in der Regel nach Funktionen oder Bereichen erfolgt. Es kann jedoch auch andere Möglichkeiten der Gruppierung geben, die besser zum Auftrag passen. Die Gruppierung erfolgt durch den Risikomanager.
4. Der Risikomanager beruft eine neue Sitzung zur Risikoanalyse ein, in der er die Risiken und deren Gruppierung vorstellt. Nun können die Teilnehmer Kommentare abgeben und gegebenenfalls neue Risiken hinzufügen ; bei Bedarf können die Risiken auch detaillierter aufgeschlüsselt werden. Nach dieser Sitzung muss die Risikokarte vorliegen, und es müssen die Voraussetzungen für die Durchführung einer Risikoanalyse ermittelt werden, bei der die Eintrittswahrscheinlichkeiten und Folgen bewertet werden.
5. Der Risikomanager beruft einen neuen Workshop ein, in dem die Risikoanalyse selbst durchgeführt wird.Zu den Teilnehmern gehören beispielsweiseder Testleiter,ein erfahrener Tester,ein Kunde,ein Architekt, der Projektmanager,der Product Owner/Systemmanager sowieein erfahrener Entwickler.
6. Für jedes Risikomüssen Wahrscheinlichkeit und Folgen abgewogen werden. Beginnen Sie damit, die Wahrscheinlichkeit des Eintretens des Risikos auf einer Skala von 1 bis 4 zu bewerten und tragen Sie diese in die Tabelle ein.
Bei der Wahrscheinlichkeit berücksichtigen wir verschiedene Faktoren, die die Wahrscheinlichkeit des Eintretens des Risikos beeinflussen.
Bewerten Sie weiterhin die Folgen für jedes Risiko. Blenden Sie die Spalte „Wahrscheinlichkeit“ aus, damit sie die Gewichtung der Folgen nicht beeinflusst.
Hier ist es wichtig, alle relevanten Interessengruppen zu identifizieren und zu überlegen, ob einige davon wichtiger sind als andere und, falls ja, wie sie gewichtet werden sollten.
7. Multiplizieren Sie die Wahrscheinlichkeit mit der Auswirkung, um einen Risikowert zu erhalten. Ordnen Sie die Risiken entsprechend ihrem Risikowert ein:
8. Entscheiden Sie, wie Sie die Risiken beseitigen wollen:
9. Beginnen Sie mit den Risiken, die den höchsten Risikowert aufweisen:
10. Anschließend ist es an der Zeit, mit dem Verfassen von Testfällen/Szenarien bzw. der Festlegung von Bedingungen für explorative Tests auf detaillierter Ebene zu beginnen.
11. Wenn Sie eine vollständige Anforderungsabdeckung anstreben, können Sie parallel zur Detaillierung der Tests überprüfen, inwieweit die Anforderungen abgedeckt sind. In Punkt 9 wurden Risiken, Anforderungen und Tests zugeordnet; nun können Sie prüfen, ob es Anforderungen gibt, für die keine Tests definiert sind. Falls es Anforderungen gibt, die nicht durch Testfälle, Szenarien oder explorative Tests abgedeckt sind, notieren Sie diese und tragen Sie sie ein, vorzugsweise in einer neuen Registerkarte der Excel-Tabelle.
12. Führen Sie die Schritte 3–10 für die Anforderungen durch, die bei der Risikoanalyse nicht berücksichtigt wurden. Behandeln Sie die Anforderungen genauso wie die Risiken, d. h., ermitteln Sie einen Risikowert, der Ihnen bei der Planung hilft, in welcher Reihenfolge die Tests erstellt und durchgeführt werden sollten.
13. Nun verfügen Sie über ein Testsystem mit vollständiger Anforderungsabdeckung und haben alle hohen Risikenbeseitigt, indem Sie Testfälle, Testszenarien und explorative Tests erstellt haben, die sicherstellen, dass alle wichtigen Funktionen getestet werden.
14. Wenn es Zeit für die nächste Lieferung/den nächsten Sprint ist, ist es sinnvoll, an die vorherige Risikoanalyse anzuknüpfen und sich zu fragen:
15. Gehen Sie bei der Planung der nächsten Lieferung/des nächsten Sprints genauso vor wie oben beschrieben, wobei hier zusätzlich Regressionstests identifiziert werden müssen. Ein Tipp ist dabei, Testfälle/Szenarien/explorative Tests auszuwählen, bei denen Abweichungen gefunden und behoben wurden, sowie Testfälle/Szenarien/explorative Tests mit einem hohen Risikowert.
—
Ich hoffe, das hilft Ihnen im Alltag weiter. Alle Tests sind unterschiedlich, und Sie müssen flexibel vorgehen, damit es zur Organisation, zur Testebene oder zu den Sprints passt, mit denen Sie arbeiten.