Die frühe Kenntnis einer Softwarearchitektur und der Einbezug des Testmanagers oder der Testspezialisten in den Entscheidungsprozess für eine Architektur trägt positiv zur Qualität des Softwareprodukts bei. Testen folgt allgemein bekannten Grundsätzen. Einige stehen in engem Zusammenhang zur Erstellung und Entscheidung über die Architektur einer Software. Hervorzuheben ist bespielsweise, dass Testen frühzeitig begonnen werden sollte, damit Kosten bei der Fehlerfindung und Behebung möglichst gering bleiben.
Auch die Tatsache, dass Testen nicht die Fehlerfreiheit beweisen kann und somit ein stochastischer und risikogesteuerter Prozess ist, zeigt, dass eine frühe Kenntnis der Architektur eines Systems positiv zum Erreichen von Testzielen beitragen kann. Im Folgenden sind dazu beispielhaft drei Aspekte beim Entwurf einer Architketur herausgegriffen, die den Zusammenhang verdeutlichen.
a) Architekturziele <=> Testziele
Der Entscheidung über eine Architektur liegen Ziele zugrunde. Diese sind meist von Projekt-/Produktzielen abgeleitet. Ziele (meist ausgedrückt in Qualitätsmerkmalen) stehen dabei oft im Widerspruch zueinander. Somit ist die letztendliche Architekturentscheidung ein Kompromiss, je nachdem, wie die Ziele gewichtet sind.
Wird der Test frühzeitig in die Diskussion eingebunden, kann er wiederum seine Ziele und Gewichtungen danach ausrichten, Fehlertiefe und Methodik ableiten und auch Risiken besser einschätzen.
b) Entwurfsprinzipien <=> Testbarkeit
Architekturentscheidungen werden auf Basis von Entwurfsprinzipien getroffen. Diese Prinzipien, oder die bewusste Verletzung derselben, kann erheblichen Einfluss auf die Testbarkeit des Testobjekts auf den verschiedenen Leveln haben. So ist z.B. eine Testautomatisierung (Komponententest) in Systemen, die stark auf Vererbung ausgelegt sind, deutlich schwerer zu realisieren, als auf Systemen, die stattdessen mehr auf Komponentisierung und Schnittstellen setzen. Testen kann aber auch bewusst darauf ausgelegt sein, bestimmte einzuhaltende Prinzipien zu testen und somit die Qualität der Umsetzung von Designentscheidungen zusätzlich abzusichern. Dies bedingt aber, dass Architekturentscheidungen transparent kommuniziert werden und nachvollziehbar sind.
c) Architekturrisiken <=> Teststrategie
Trotz sorgfältiger Planung muss ein Architekt oftmals Kompromisse eingehen, wenn Architekturen entwickelt werden. Hieraus folgen immer auch Risiken. Damit der Testmanager dies wirksam verwenden kann, sollten Risiken auf Basis einer sorgfältig erstellen Architekturdokumentation kommuniziert werden. Eine solche Dokumentation kann insbesondere durch die White-Box Sicht wesentliche Hinweise für den Tester liefern, seine Teststrategie optimal auszurichten, um Risiken in der Architektur minimieren zu helfen. Ein Beispiel in diesem Zusammenhang: Einer der Grundsätze vom Testen besagt, das eine Fehlerhäufung auf wenigen Komponenten zu beobachten ist. Wenn also im Test Fehler gefunden werden, sind oftmals weitere Fehler zu erwarten. Ein Blick in eine gute Architekturdokumentation (oder eine Gespräch mit dem Architekten) sollte helfen, solche Komponenten nicht erst stochastisch finden zu müssen, sondern gleich auf Indikatoren (z.B. zu viele Abhängigkeiten) achten zu können, um die Teststrategie und Methodik entsprechend von Anfang an besser zu optimieren.
Hier wurden nur drei der offensichtlichsten Zusammenhänge kurz erläutert. Wer sich näher mit Architketur und Test auseinandersetzt wird merken, dass weitere zu finden sind.
Es ist daher zielführend, wenn Architekt und Testmanager/Tester sich frühzeitig und regelmäßig austauschen, um damit gemeinsam ein optimales Umfeld für hohe Softwarequalität zu schaffen.
