Bessere Software dank Test-driven Designs
Sicherheitsnetz für Architekten
Nicht nur Gebäude stehen und fallen mit der Architektur, Gleiches gilt für Softwareanwendungen. Unabdingbar ist es daher, eine Softwarearchitektur auch im Hinblick auf ihre Testbarkeit zu entwerfen.
Für das Testen von Software ist ausschließlich die Test- und Qualitätsabteilung zuständig. Diese Einschätzung war schon früher falsch. Sie scheitert erst recht bei agilen Projekten mit komplexen Anforderungen und Randbedingungen. Vernachlässigen Software- und Systemarchitekten ihre Mitverantwortung für das Testen, haben sie den ersten Schritt zum Scheitern bereits gemacht. Wie also können Architekten es besser machen?
Lernen aus Fehlern
Bei der internen Analyse von Problemen in einem Projekt stellte der Elektrokonzern Siemens fest, dass fehlendes Testen durch die beteiligten Architekten eine essenzielle Ursache für das Scheitern von Projekten darstellt. Speziell Testmaßnahmen, Reviews und Qualitätsmessung hatten Architekten eher als unliebsame Kontrolle ihrer Arbeit empfunden. Sie betrachteten Testen und Qualitätssicherung offensichtlich weder als Entwurfsansatz noch als Sicherheitsnetz. Doch genau das ist es, was Testen den Architekten bietet.
Sie stehen in der Verantwortung, ein schlüssiges und funktionierendes Integrationskonzept zu liefern, um eine kontrollierte Integration sicherzustellen. Schließlich beeinflussen Software- und Systemarchitektur den Integrationstest maßgeblich. Nicht zuletzt gehört es zu den Pflichten eines Architekten, ständig die Auswirkung von Architekturentscheidungen auf die Qualität im Auge zu behalten. Gerade unentdeckte oder unbehandelte Entwurfsprobleme können über die Projektlaufzeit zu „Big-Ball-of-Mud“-Architekturen führen, die sich jeder späteren Änderung heftig widersetzen. Ein geeignetes Mittel, ein Projekt gezielt zu sabotieren, dazu eines mit Erfolgsgarantie.
Schon am Anfang des Entwicklungsprozesses sind Architekten in die Qualitätssicherung involviert (siehe Abbildung 1). Sobald neben Geschäftszielen und Randbedingungen alle Anforderungen – oder realistischer eine Teilmenge davon – vorliegen, müssen Architekten diese Architekturtreiber auf ihre Qualität prüfen. Ohne hochqualitative Anforderungsspezifikation ist keine hochqualitative Architektur möglich: Garbage in, Garbage out. Im Idealfall haben Architekten mit anderen Beteiligten aus der Spezifikation die architekturrelevanten Anforderungen und ihre Prioritäten abgeleitet.
Aus den wichtigsten funktionalen Anforderungen entsteht die funktionale Architektur, die ein Architekt im nächsten Schritt um die wichtigsten nichtfunktionalen Anforderungen erweitert. Daraus entsteht Stück für Stück eine Basisarchitektur, die sich nach jedem Inkrement über Reviews und Tests einer Qualitätsprüfung unterziehen muss. Dabei stehen nicht nur Code- und Entwurfsartefakte auf dem Prüfstand, sondern auch die Dokumentation als wichtigstes Kommunikationsmedium. Je nach Ergebnis definieren Architekten Maßnahmen zum Redesign und zum Refactoring, nach deren Durchführung eine erweiterte, geprüfte und ausführbare Implementierung vorliegt. Im optionalen Akzeptanztest holt das Projekt unter Umständen vorher Feedback von Kunden und Nutzern ein.
Wer sich die Frage stellt, was Testen überhaupt bringt, kommt schnell zu dem Ergebnis, dass Testen und andere Qualitätssicherungsmaßnahmen lediglich Daten beziehungsweise Information liefern, die Hinweise auf Qualitätsprobleme geben können. Welche Daten wo, wann und wie zu ermitteln sind sowie deren anschließende Interpretation bleibt vor allem Entwicklern und Architekten überlassen. Für effiziente QS sind Fragen zu beantworten wie „In welchem Überdeckungsgrad sollen Tests ablaufen, wann endet das Testen beziehungsweise wann wird der Testaufwand so groß, dass die Kosten den Nutzen übersteigen?“, „Welche QS-Maßnahmen gibt es und welche sollen wofür zum Einsatz kommen?“.
Architektonisch relevante Testebenen
Architekturrelevantes Testen findet vor allem in folgenden Testebenen statt:
Die Architektur bildet die Basis von Integrationstests, die das Zusammenspiel aller Komponenten und Subsysteme in einem System prüfen, etwa das dynamische Systemverhalten und die Kommunikation. Dazu gehört auch die Integration eines Systems in seine Umgebung. Das alles sowohl hinsichtlich des Kontroll- als auch hinsichtlich des Datenflusses.