Architekturzentriertes Testen

Als Ansatzpunkt dienten dafür bisher die Anforderungen. Liegen hier bereits Qualitätsdefizite vor, sind diese oftmals die Ursache für später auftretende Fehler, weshalb beispielsweise über Reviews eine frühzeitige Prüfung von Anforderungen erfolgt.

Mit dem „Architekturzentrierten Testen“ wird dies nun in Bezug auf Architektur erweitert, denn auch die Architektur liefert bereits sehr frühzeitig sehr detaillierte Informationen, damit die Teststrategie optimal ausgerichtet werden kann und Fehler im Vorfeld vermieden werden können.

Der Architekturprozess

Das Erstellen einer Softwarearchitektur folgt einem iterativen Prozess. Folgt man diesem

Prozess, erhält man eine Architektur, die mit allen Stärken und Schwächen bewusst entschieden wurde. Wichtige Elemente beziehungsweise Phasen dieses Prozesses sind:

• Systemabgrenzung: Hierbei wird untersucht, welche Teile des Systems gestaltbar sind und wo Randbedingungen liegen, die als gegeben hingenommen werden müssen.
• Wechselwirkungen: Aus den Randbedingungen, den Anforderungen und den Architekturzielen ergeben sich in Summe die Einflussfaktoren, die in Wechselwirkungen zueinander stehen, weshalb eine Architektur fast immer einen Kompromiss darstellt. Dieser wiederum führt zu Risiken, die pro-aktiv ausgesteuert werden müssen.
• Fachliche Architektur: In diesem Schritt wird das Problem zunächst fachlich in Bausteine zerlegt. Diese Zerlegung ist wichtig, um die Komplexität des Problems beherrschbar zu machen. Technische Aspekte werden in diesem Schritt (noch) nicht oder nur sehr wenig berücksichtigt.
• Technische Architektur: Die technische Architektur zeigt die Umsetzung. Die Bausteine der fachlichen Architektur werden also näher untersucht, es werden die Wechselwirkungen herangezogen und der Architekt einigt sich mit den Stakeholdern auf einen Kompromiss und übersetzt diesen (oftmals unter Verwendung von Architekturmustern) in eine technische Architektur.
• Architekt: Wichtig für den Prozess ist auch die Rolle des Architekten. Da eine Architektur einen Kompromiss darstellt, ist es unter anderem seine Aufgabe, diesen mit den Stakeholdern abzustimmen und die verschiedenen Sichten und Erwartungen zu einer gemeinsamen Win-Win-Situation zusammenzuführen.

Systemabgrenzung

Die Systemabgrenzung ist der erste Ansatzpunkt des Testmanagers, Anforderungen an die Architektur einzubringen.

Dazu gehört zum Beispiel, welche Testwerkzeuge und Technologien des Testrahmens bezüglich ihrer Schnittstellen von der Architektur berücksichtigt werden müssen. Es muss zudem ein konsistentes Bild zwischen Testmanager und Architekt hinsichtlich des Systemkontextes geben.

Die Grenze zum Systemkontext ist gerade zu Anfang noch breit und eher unscharf. Sie wird im weiteren Verlauf durch viele Diskussionen und Erkenntnisse konkreter. In jedem Fall darf sie vom Testmanager und vom Architekten nicht unterschiedlich gezogen sein. Zieht der Testmanager sie zum Beispiel enger, so wird er beim Systemtest manche Teile nicht berücksichtigen, die vom Architekten jedoch bei der Architektur mitgestaltet wurden und getestet werden sollten. Analog gilt dies auch für die Abgrenzung zu der irrelevanten Umgebung (siehe Abbildung 1).

Wechselwirkungen

Einflussfaktoren, die sich aus Randbedingungen (z. B. Kosten), funktionalen Anforderungen, nicht-funktionalen Anforderungen und Architekturzielen (z. B. Wartbarkeit) zusammensetzen, stehen in Wechselwirkung zueinander. Performanz wirkt zum Beispiel oft negativ auf die Wartbarkeit und die Kosten, wenn der Code sehr auf das Zeitverhalten hin zugeschnitten ist.

Entgegen einer einfachen Analyse der Anforderungen richtet der Testmanager beim „Architekturzentrierten Testen“ seine Strategie an der tatsächlichen Entscheidung in Bezug auf den Architekturkompromiss aus. Der Kompromiss drückt aus, welche Einflussfaktoren sicher erfüllt werden und bei welchen die Erfüllung nur schwer gewährleistet werden kann.

Abbildung 2 zeigt dies exemplarisch. Hier sind einige Einflussfaktoren auf dem Kreis gezeigt. Je weiter zwei Faktoren gegenüberliegen, desto stärker beeinflussen sie sich gegensätzlich. So ist zum Beispiel das Erreichen einer hohen Performanz mit hohen Kosten verbunden. Der innere Kreis ist der Lösungsraum für Architekturalternativen. Eine Alternative (hier als Punkt dargestellt) wird manche Faktoren mehr, andere weniger gut umsetzen. Man kann sich dies als Gummibänder zu den Faktoren vorstellen, die entweder stärker oder weniger stark angespannt sind. In diesem Beispiel gibt es eine starke Spannung zur Performanz. Entsprechend wird dies bei der Teststrategie intensiv berücksichtigt (intensive Schulung der Tester, Anschaffung von Werkzeugen, Tests auf allen Ebenen).

Fachliche Architektur

Die Abhängigkeiten auf fachlicher Ebene zeigen, wo mit Risiken zu rechnen ist. Sind zum Beispiel viele Baustein fachlich von einem Baustein abhängig, sollte dieser besonders intensiv getestet werden, da sich sonst sein Fehlverhalten auf viele andere auswirkt.

Sie geben unter anderem auch Hinweise bezüglich der Reihung der Testautomatisierung. Existieren zum Beispiel für einen Baustein viele Abhängigkeiten zu anderen, ist er als instabil anzusehen [Mar18], weshalb die Tests dieses Bausteines früher automatisiert werden sollten.

Die fachliche Architektur zeigt auch die Schnittstellen nach außen. Hier wird sichtbar, wo frühzeitig Testdaten bereitgestellt werden müssen. Abbildung 3 zeigt dies schematisch. Dort ist ein System mit seiner Systemgrenze (äußeres Rechteck), seinen Ports nach außen, den inneren Bausteinen und ihren Abhängigkeiten untereinander gezeigt.

Bausteine, von denen viele andere abhängig sind (Pfeile direkt oder indirekt hinein), sollten früher und intensiver getestet werden. Bei Bausteinen, die von anderen abhängig sind, stellt sich die Frage der Robustheit (wie reagieren sie auf Änderungen). Ports, die externe Systeme verwenden, müssen frühzeitig Daten bereitgestellt werden. Externe Systeme, die Ports verwenden, können im Zusammenspiel nur hinsichtlich ihrer Anforderungen an das System getestet werden, wenn sie auch verfügbar sind.

Technische Architektur: Metriken

Übliche klassische Qualitätsmetriken einer Architektur (z. B. Zyklen, Average Component Dependency) sind auch im „Architekturzentrierten Testen“ hilfreich und nützlich. Bisher lagen diese in der Verantwortung des Architekten, da sie ein tiefes Verständnis der Architektur voraussetzen. Hier wird der Testmanager nun stärker als bisher eingebunden, beziehungsweise sollte hier der Testmanager den Prozess über Checklisten steuern. Fragen dabei können sein:

• Wann wird geprüft?
• Was wird geprüft?
• Wer prüft?
• Was wird konkret bei Defiziten unternommen?

Technische Architektur: Prinzipien

Architekturprinzipien sollen helfen, Best Practices beim Erstellen einer Architektur einfließen zu lassen. Werden diese nicht eingehalten, lassen sich frühzeitig Rückschlüsse auf Qualitätsdefizite ziehen.

Ein sehr wichtiges Prinzip ist zum Beispiel das Erreichen einer hohen Kohäsion. Beim „Architekturzentrierten Testen“ wird eine Verletzung dieses Prinzips über die Auswirkung auf den Testprozess geprüft. Verteilen sich nämlich fachliche Aspekte, die untereinander abhängig sind, auf mehrere weit auseinanderliegende Komponenten (niedrige Kohäsion), können diese nicht oder nur sehr schwer entkoppelt für die Testautomatisierung bereitgestellt werden, was einen Zeitverzug zur Folge hat. Zwar obliegt es nicht der Qualitätssicherung, derartige Defizite in der Architektur zu korrigieren, die Strategie kann mit dieser Kenntnis aber zielgerichteter angepasst und mit der Entwicklung diskutiert werden.

Abbildung 4 zeigt dazu in der ersten Spalte ein System mit hoher Kohäsion. Somit kann eine Komponente isoliert weiterentwickelt und frühzeitig einzeln getestet werden. Die zweite Spalte zeigt die Auswirkungen einer niedrigen Kohäsion. Liegt eine niedrige Kohäsion vor, ist abzusehen, dass das Herausnehmen einzelner Komponenten für den Test möglicherweise undurchführbar beziehungsweise zu aufwendig ist. Somit muss gewartet werden, bis das gesamte System zu einem späteren Zeitpunkt für Tests verfügbar ist. Änderungen von Komponenten werden zudem mit höherer Wahrscheinlichkeit Auswirkungen auf das gesamte System haben, was einen intensiveren Regressionstest notwendig macht.

Dies ist nur eines von vielen Prinzipien, die in dieser oder ähnlicher Weise beim „Architekturzentrierten Testen“ berücksichtigt werden. Die Resultate helfen dem Testmanager und dem Architekten, den Prozess an den Ursachen (der Architektur) zu verbessern und nicht an den Symptomen.

Als Beispiel seien hier Scrum und der damit verbundene Bedarf an Testautomatisierung genannt. Zeigt sich in dem Prozess bei der Retrospektive, dass ein Sprint nicht vollständig getestet werden kann, weil das Testobjekt (oder Teile davon) zu spät testbar zur Verfügung stehen, wird oft beim Testteam angesetzt, dass dieses bei der Erstellung der Testautomatisierung effizienter wird. Das „Architekturzentrierte Testen“ zeigt nun zusätzliches Verbesserungspotenzial auf, indem es auf mögliche Schwächen in Bezug auf die niedrige Kohäsion hinweist, was die Ursache der verspäteten Verfügbarkeit sein kann. Somit wird dann über zum Beispiel Refactoring die Ursache des Problems angegangen.

Technische Architektur: Muster

Muster stellen Schablonen oder Ansätze dar, eine technische Architektur zu konzipieren. Besonders nicht-funktionale Anforderungen haben Einfluss darauf, welche Muster am zweckmäßigsten verwendbar sind. Diese Muster haben Stärken und Schwächen, was beim „Architekturzentrierten Testen“ berücksichtigt wird.

Beispielhaft sei hier das Schichtenmuster genannt. Es hat seine Stärken in der Austauschbarkeit. Seine Schwäche liegt in möglichen Performanzabstrichen, da bei Anfragen alle Schichten von oben ab durchlaufen werden müssen. Der Testmanager muss also untersuchen, wie die Schichten entkoppelt wurden, was durch das Mocken einer Schicht geprüft werden kann. Die Spezifikation von Testfällen sollte berücksichtigen, dass bei der Ausführung der Testfälle alle Schichten durchlaufen werden, um Schwächen in Bezug auf die Performanz offenzulegen.

Auch hier sei angemerkt, dass viele weitere Muster existieren, die beim „Architekturzentrierten Testen“ entsprechend geprüft werden. Letztlich werden Muster je nach ihrer Eigenschaft hin ausgewählt, nicht-funktionale Anforderungen abzudecken. Hat also ein verwendetes Muster allgemein seine Stärken zum Beispiel in der Performanz, sollte auch der Test den Schwerpunkt auf diesen Aspekt legen, damit sichergestellt wird, dass das Muster korrekt umgesetzt wurde. Dort, wo verwendete Muster allgemein Schwächen haben, sollte durch entsprechende Wahl der Testfälle gezielt auf die Schwächen hin geprüft werden, um Risiken zu reduzieren.

Technische Architektur und Testabdeckung

Abdeckungsmaße im Testen sind eine wesentliche Metrik, um Testziele zu definieren und den Umfang der Risikoabschätzung durch das Testen beurteilen zu können.

Allgemein wird das Ziel einer „hohen“ Abdeckung verfolgt, was jedoch nicht immer effektiv und auch – allgemein betrachtet – nicht immer notwendig ist. Besser ist es, unterschiedliche Abdeckungsziele zu verfolgen, denn nicht jede Komponente hat in gleichem Umfang Einfluss auf die Erfüllung funktionaler und nicht-funktionaler Anforderungen.

Steht zum Beispiel die Performanz hoch priorisiert im Vordergrund, sind meist nicht alle Komponenten gleich relevant, was die Erfüllung dieser Anforderung betrifft. Die Analyse der Architektur gibt dem Testmanager daher die Möglichkeit, den Einfluss einzelner Komponenten zu ermitteln und entsprechend die Abdeckungsziele zielgerichtet anzupassen.

Fazit

Testen und Entwicklung arbeiten immer enger zusammen. Bisher fehlte dies jedoch auf der abstrakteren Architekturebene. So wie der Tester in den letzten Jahren seine Entwicklungsskills erweitern musste, sollte und wird nun auch analog der Testmanager seine Skills über das „Architekturzentrierte Testen“ im Bereich der Architektur ergänzen.

Dies fördert den Ansatz, Fehler möglichst vor der Implementierung zu erkennen und zu beheben. Umgesetzt wird dies durch statische und dynamische Methoden. Statisch ist hier das Review zu nennen, ausgerichtet auf die Ziele, Kompromisse und Risiken der Architektur. Dynamisch kommen zum Teil neue Testmethoden zum Einsatz (z. B. um Testfälle zum Prüfen der Einhaltung von Architekturprinzipien zu spezifizieren) oder die bisher bekannten dynamischen Methoden werden mit Kenntnis der Architektur effektiver angewandt

Referenzen

[Mar18]
R. C. Martin, Clean Architecture, mitp, 2018

[Spi14]
A. Spillner, Praxiswissen Softwaretest – Testmanagement, 4. Aufl., dpunkt.verlag GmbH, 2014

[Sta17]
G. Starke, Effektive Softwarearchitekturen: Ein praktischer Leitfaden, 8. Aufl., Carl Hanser Verlag GmbH & Co. KG, 2017