Architekturzentriertes Testen

Einflussfaktoren, die bei der Konzeption einer Architektur zu berücksichtigen sind, stehen in Wechselwirkung und oft in Widerspruch zueinander. Somit gibt es für ein zu entwickelndes Softwaresystem nicht DIE Architektur, sondern maximal einen mit allen Beteiligten transparent abgestimmten Kompromiss.

Dies eröffnet den Zusammenhang zum Software-Testen, denn einem Kompromiss wohnen immer Stärken und Schwächen inne. Testen sollte somit an diesen für die Architektur gefundenen Kompromiss in Methodik und Umfang ausgerichtet sein. Eine Kenntnis der Einflussfaktoren, der Wechselwirkungen und der daraus resultierenden Architekt plus der Abstimmung mit dem Architekten bzw. Architekturteam liefert dem Tester daher eine wertvolle Basis, um Tests und Testziele effektiv und effizient zu gestalten.

Nutzen für den Teilnehmer:
- Bewusstsein bilden, dass Tester sich mit Architektur auskennen müssen
- Argumente liefern, warum sich Tester dbzgl. fortbilden sollten.
- Ansätze zeigen, wie man dies beim Testkonzept strukturiert berücksichtigen kann.
- Probleme hinsichtlich der Effektivität des Testens zeigen, wenn man dies nicht tut.
- Die Basis vermitteln, dass Architektur immer ein Kompromiss ist.
- Erkennen, dass der Tester Schnittstellen bei der Komponentisierung von Software benötigt und parallel eine TA aufzusetzen.

Behandelte Problemstellungen:
Nachgelagerte Tests ohne Kenntnis der Architektur sind nicht effizient. Die Kenntnis der Wechselwirkungen ist essentiell bei der Ausrichtung des Testens, da es dann zielgerichteter gestaltet werden kann.

Trotz dieses Zusammenhangs, beschäftigen sich aktuell Tester noch sehr wenig mit Architektur. Ausbildung und Kenntnis sollten hier in Zukunft angepasst werden. Testern ist dieser Zusammenhang bisher eher verborgen, was man auch daran sieht, dass es keine für Tester angepasste Architekturkurse (z.B. ISTQB) gibt.

Ein methodisches Vorgehen beim architekturzentrierten Testen fehlt bisher. Zwar gibt es statische Analysen von Code, die die Verletzung von Architekturregeln prüfen. Auch gibt es ATAM als qualitative Architekturbewertung, jedoch fehlt ein anfänglicher und kontinuierlich im Projekt aktualisierter Testprozess, der die Ausgestaltung des Architekturkompromisses ständig reflektiert und die Tests(methoden) entsprechend anpasst.

Vorgetragen von: Stephan Christmann
Unternehmen: Software Quality Lab GmbH

Vortragssprache: Deutsch
Level: Fortgeschrittene
Zielgruppe: Tester, QA-Manager, Architekten, Projektleiter, SCRUM-Master

Partner 2018