Das Entwickeln von Software und das Testen von Software haben vieles gemeinsam, vor allem wenn es darum geht, den Erfolg zu messen. Daher ist es auch sinnvoll, die Gemeinsamkeiten besser zu verstehen, um daraus dann Synergien ableiten zu können. Diese können letztlich die Qualität der Software weiter erhöhen.

Je früher man als Tester das Konzept der Software kennt und eingebunden wird, umso größer kann der Beitrag für die Qualitätssicherung sein. Das Testen von Software basiert auf Regeln, die auch bei der Erstellung der Softwarearchitektur angewandt werden. Wer die Testroutinen zu einem frühen Zeitpunkt definiert und startet, kann damit neben der besseren Qualität auch eine Kostenreduzierung erreichen.

Tests sollen die Leistungsfähigkeit beweisen und Fehler finden, aber nicht beweisen, dass es keine Fehler gibt. Es handelt sich dabei um eine stochastische Methode, deren Ziele umso besser erreicht werden können, je früher man die Architektur kennt. Das soll an drei Beispielen verdeutlicht werden:

1. Ziele bei Architektur und Tests

Um die passende Architektur festzulegen, müssen zunächst einmal die Ziele definiert werden. Diese basieren auf den Produkt- und Projektzielen. Hier kann es vorkommen, dass es Widersprüche gibt, die sich in den Qualitätsmerkmalen äußern. In diesem Fall wird man abwägen müssen, welche Merkmale wichtiger sind und entsprechend eine Entscheidung bei der Architektur treffen müssen. Wenn der Tester in diesem Prozess eingebunden ist, können auch die Testziele artikuliert werden und in die Entscheidung mit einfließen. Man kann die Fehlertiefe definieren und vor allem Risiken einschätzen.

 

2. Prinzipien des Entwurfs und die Testbarkeit

Die Entwurfsprinzipien sind die Grundlage für Entscheidungen, wenn es um die Architektur geht. Sowohl die Prinzipien als auch eine mögliche Missachtung hat Konsequenzen für das Testen, und zwar auf verschiedenen Ebenen. Wenn ein System zum Beispiel auf Vererbung basiert, dann ist eine Testautomatisierung von Komponenten schwieriger als wenn Schnittstellen und eine Komponentisierung eingesetzt werden. Mit dem Testen kann man auch die Prinzipien selbst testen und damit eventuelle Schwachstellen im Design aufdecken. Voraussetzung ist, dass es frühzeitig eine transparente Zusammenarbeit bei der Architektur Entscheidung gibt.

 

3. Risiken der Architektur und Strategien für Tests

Architekten werden immer vor dem Problem stehen, Kompromisse eingehen zu müssen. Das bringt aber auch Risiken mit sich. Diese müssen auf Grundlage einer detaillierten Architekturdokumentation formuliert und kommuniziert werden. Die damit verbundene White-Box-Sicht ermöglicht dem Tester Input zu geben, Teststrategien optimal zu formulieren und Risiken in der Architektur zu verringern. So geht man beim Testen zum Beispiel davon aus, dass viele Fehler meistens auf wenigen Komponenten beruhen. Daraus folgt, dass man erwarten kann, nach einem Fehler auch weitere zu finden. Eine gute Dokumentation der Architektur und die Kommunikation mit Developern können den Testern helfen, nicht erst nach ähnlichen Komponenten suchen zu müssen, sondern mit Indikatoren arbeiten zu können. Diese geben schnellere Hinweise auf eventuelle Abhängigkeiten. So lassen sich Methodik und Teststrategie wesentlich verbessern.

 

Das sollen nur drei plakative Beispiele dafür sein, wie Architektur und Testen miteinander verbunden sind. Je früher Architekt und Tester zusammenarbeiten, umso eher können die sie die Grundlage für eine gute Softwarequalität legen.

 

 

 

Bild von onlineCup auf Pixabay