Nicht ohne Risiko – die richtige Teststrategie

Auch Softwarearchitekten benötigen ein Sicherheitsnetz für ihre Entwürfe und deren Implementierung. Neben Methoden zur Architekturbewertung hat vor allem Testen eine wichtige Rolle. Doch wie können Architekten und Tester bei der Testplanung effektiv zusammenarbeiten?

In Pocket speichern vorlesen Druckansicht 5 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Dr. Michael Stal

Auch Softwarearchitekten benötigen ein Sicherheitsnetz für ihre Entwürfe und deren Implementierung. Neben Methoden zur Architekturbewertung hat vor allem Testen eine wichtige Rolle. Doch wie können Architekten und Tester bei der Testplanung effektiv zusammenarbeiten?

Wie halten Sie es als Softwarearchitekt mit dem Testen? Haben Sie sich etwa die Annahme zu eigen gemacht, dass Sie sich als Softwarearchitekt nicht darum kümmern müssen, weil Teststrategien und Testpläne vom Test-Architekten/-Manager kommen? Leider ist diese Annahme falsch! Fakt ist: Testen liefert Information. Welche Information relevant ist, müssen die Architekten entscheiden. Tester liefern die notwendige Methodik und Infrastruktur. Nur durch Zusammenarbeit zwischen Testern und Architekten ergibt sich ein erfolgreiches Projekt.

Im Detail bedeutet das, dass die Teststrategie in einem Projekt auch die Handschrift der Softwarearchitekten tragen muss. Für die Zusammenarbeit von Test- und Architektenteam eignet sich als Methodik insbesondere die sogenannte risikobasierte Teststrategie.

Eine risikobasierte Teststrategie – nomen est omen – fokussiert auf die technischen Risiken im Entwicklungsprojekt. Der meiste Testaufwand soll auf diejenigen Anwendungsszenarien, Qualitäten, Architekturentitäten und Komponenten entfallen, die aus Risikosicht besonders kritisch erscheinen. Im Umkehrschluss lohnt es sich erfahrungsgemäß nicht, viel Testaufwand für risikoarme oder wenig relevante Aspekte zu spendieren.

Das klingt sehr theoretisch. Daher möchte ich das Beispiel eines Brandmelders in einem Gebäude untersuchen. Der Brandmelder soll im Ernstfall die Anwohner und gleichzeitig die Notrufzentrale alarmieren. Auch ohne große Phantasie lassen sich hieraus einige Risiken ableiten. Im konkreten Beispielszenario gehe ich davon aus, dass der Brandmelder ein Feuer nicht erkennt. Ich fokussiere mich also auf den Brandmelder und dort konkret auf den Ausfall der Sensoren.

  • Artefakt: Brandmelder.
  • Risiko: Temperatur- bzw. Rauchsensor im Brandmelder fallen aus.
  • Folgen: Nichterkennen eines Brandes mit daraus resultierendem Totalschaden (Worst Case).
  • Subsystem: Alle Brandmelder sind Teil des Brandschutzsubsystems in der Gebäudeautomatisierung.
  • Eintrittswahrscheinlichkeit: Auf einer Skala von 1 (niedrig) bis 5 (hoch) gehen wir von 2 aus.
  • Schaden: Auch hier verwenden wir der Einfachheit halber eine Skala von 1 bis 5. Da der Schaden typischerweise recht hoch ist, setzen wir ihn auf 5.
  • Erwartungswert: Der Erwartungswert ergibt sich als das Produkt von Eintrittswahrscheinlichkeit und Schaden, also im Beispiel 2 x 5 = 10. Der Hintergrund dieses Wertes liegt auf der Hand. Wenn ein System zwar schnell ausfallen kann, dabei aber marginalen Schaden verursacht, ist die Situation wesentlich unkritischer als in dem Fall, dass die Eintrittswahrscheinlichkeit zwar minimal, aber der resultierende Schaden immens ist. Beispiel Fukushima.
  • Testbarkeit: Hierunter ist zu verstehen, ob dieses Risiko überhaupt mit Testmaßnahmen überprüft werden kann, etwa durch Ermittlung der MTBF (Mean Time Between Failure). Wie üblich steht der Wert 1 der Nichttestbarkeit und 5 für sehr gute Testbarkeit. Ein Brandmelder lässt sich gut auf Ausfallwahrscheinlichkeit testen, weshalb wir für die Testbarkeit den Wert 4 annehmen.
  • Testpriorität = Erwartungswert x Testbarkeit = 10 x 4 = 40. Dieser Wert liegt zwischen 1 und 125. Testprioritäten helfen, den Testaufwand auf die wirklich kritischen Aspekte in der Architektur zu konzentrieren.
  • Testklassifizierung: Wer führt mit welchem Aufwand welche Art von Test wann aus, um dieses Risiko im System zu überprüfen, etwa mittels Integrationstest, Akzeptanztest, oder Systemtest. In unserem Fall benötigen wir einen Systemtest des Brandmelders, bei dem der Brandmelder simulierter Abnutzung ausgesetzt ist und ständig daraufhin überprüft wird, ob seine Sensoren einen Brand sicher erkennen.

Natürlich gibt es zu einem Artefakt mehrere Risiken. Und natürlich gibt es auch mehrere Artefakte. Was ich in dem Beispiel als schlichte Liste dokumentiert habe, wäre im konkreten Projekt eine von mehreren Tabellenzeilen mit jeweils Artefakt als erster Spalte und Testklassifizierung als letzter Spalte.

Wie eingangs erwähnt, erfolgt die Erstellung dieser Tabelle gemeinsam durch Architekten und Tester. Das Ganze ist allerdings nicht für lau zu haben, sondern erfordert ein wenig Aufwand. Dieser lohnt sich allerdings erfahrungsgemäß rechts schnell.

In meinem Umfeld sind risikobasierte Teststrategien die Basis für die Testplanung in Entwicklungsprojekten und haben sich als sehr gut strukturierte Methodik bewährt.

Nebenbei bemerkt: Als Seiteneffekt erlauben die Testprioritäten auch einen Quercheck, inwieweit sich diese mit den Anforderungsprioritäten decken. Die Erstellung der Teststrategie fördert zudem das nochmalige Reflektieren über Anforderungen und Architektur. Es gibt also gute Gründe für risikobasierte Teststrategien. ()