© Excellent backgrounds/Shutterstock.com
Teil 4: Qualität von Websystemen verifizieren können

Testbarkeit


Der Nachweis, dass ein Websystem fehlerfrei ist, ist unmöglich zu erbringen, weil wir nicht alles testen können. Deswegen konzentrieren wir uns auf die Aspekte des Systems, die uns am wichtigsten erscheinen, und testen nur diese. Dabei ist es wichtig, dass sich diese Aspekte auch tatsächlich testen lassen. Um die Herstellung der Testbarkeit von Websystemen geht es in diesem Artikel.

Video: Und wie war ich so? – Die Krux mit dem Feedback

Die Testbarkeit bestimmt, wie leicht ein System seine Fehler preisgibt. Eine einfache Metrik zur Bestimmung der Testbarkeit ist die Zeit, die benötigt wird, um die Ursache für einen bestimmten Fehler zu finden. Hierzu gehört auch, dass ein automatischer Test für die Reproduktion geschrieben wird, d. h. für ein gut testbares System sollten sich automatische Testfälle leicht entwickeln lassen. Zur Testbarkeit gehört zudem die physische Möglichkeit der Testdurchführung. Diese will in Form von Umgebungen für manuelle und automatische Tests bereitgestellt werden.

Test Harness

Mittel zum Zweck ist dabei der Test Harness, ein spezialisiertes Softwaresystem, das sich um den Test unseres Websystems kümmern soll. Üblicherweise kann der Test Harness nicht nur automatische Tests ausführen, sondern verwaltet auch Testdaten und kann das Zielsystem konfigurieren. Hierfür muss der Harness das Zielsystem installieren, starten, stoppen, löschen und seinen Zielzustand messen können.

Websysteme müssen eine breite Anzahl von Geräten und Browsern unterstützen, und dies gilt somit auch für den Test Harness. Mit der steigenden Diversität im Endgerätemarkt hat es insbesondere das Frontend schwer, für alle Geräte in hoher Qualität zu produzieren. Es haben sich hier mittlerweile Dienste wie BrowserStack [1] etabliert, die eine Automatisierung der Tests über verschiedenste Endgeräte möglich machen. Wenn Sie eine hohe Anzahl an Geräten testen müssen, kommen sie um solch einen Dienst nicht mehr herum. Es ist eine gute Idee, die Integration in den Test Harness früh einzuplanen.

Die Entwicklung eines Test Harness kann bei komplexen und verteilten Systemen teuer werden. Meiner Erfahrung nach fallen für den Test Harness eines großen Websystems zwischen 60 und 90 Tagen Aufwand an. Die Eigenentwicklung ist oft nötig, da es keine Software von der Stange gibt, die die Aufgabe erledigen könnte. Wehe dem, der diese Fertigung nicht budgetiert hat: Ohne Test Harness lassen sich automatische Integrationstests nicht durchführen, und das erhöht die Kosten der Entwicklung nachhaltig.

Schließlich sorgt die Testbarkeit für eine nachhaltige Änderbarkeit unseres Websystems, aber zu diesem Thema kommen wir erst im übernächsten Artikel dieser Serie.

Klassifikation

Die Testbarkeit gehört nach ISO/IEC 25010 zur Wartbarkeit. Stefan Toth hat in seinem Buch [2] die Qualitätsmerkmale nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern klassifiziert. Die Testbarkeit ist natürlich eine Qualitätsgeschichte. Sie ist unabhängig von den funktionalen Anforderungen an das System und kann eigenständig bearbeitet werden. Bemerkenswert ist, dass die Testbarkeit die Grundlage für die Schaffung von messbaren Akzeptanzkriterien schafft.

Architektur vs. Design

Bereits im letzten Artikel der Serie wurde der Unterschied zwischen Modul und Komponente besprochen. Analog dazu unterscheiden sich Architektur und Design [3].

Das Softwaredesign beschäftigt sich mit der Planung und Entwicklung von Modulen. Ein Modul ist eine gekapselte Implementierungseinheit, beispielsweise ein Package. Module können aber auch eine einzelne Klasse oder XML-Datei sein. Sprechen wir von einem Modul, so haben wir einen konkreten Bezug zur Implementierung. Module werden per Unit Test getestet.

Softwarearchitektur hingegen definiert die im System verwendeten Komponenten. Eine Komponente ist eine Laufzeiteinheit, die unabhängig deployt werden kann. Die Struktur des Innenlebens der Komponente ist dabei für die Architektur nicht wesentlich. Sprechen wir von einer Komponente, so beziehen wir uns auf ihre Laufzeiteigenschaften. Eine Komponente besteht aus verschiedenen Modulen, wobei die Abbildung surjektiv, aber nicht injektiv ist. Komponenten werden per Integrationstest getestet.

Sandboxing

Erste Voraussetzung für die Testbarkeit ist die Existenz von Testumgebungen, auf denen Tests durchgeführt werden können. In der Regel geht man von vier verschiedenen Umgebungen aus, die für eine Website benötigt werden (Abb. 1).

Die lokale Entwicklungsumgebung dient, wie der Name sagt, dem Entwickler für die Produktion automatischer Tests (DEV). Die Integrationsumgebung führt die Arbeitsergebnisse verschiedener Entwickler bzw. Teams zusammen (IGR). Hier ist in der Regel Continuous Integration (CI) im Spiel, das über eine Kette von Build-Plänen Softwarepakete produziert. Zu CI gibt es viel Literatur, es sei der grundlegende Artikel von Martin Fowler empfohlen [4].

Die erstellten Pakete werden dann in der User-Acceptance-Test-Umgebung (UAT) eingespielt, wo sie manuell geprüft werden können. Schließlich gibt es das Produktionssystem, das immer dann im Rahmen des Testings benötigt wird, wenn sich ein Fehler nirgendwo sonst reproduzieren lässt (PRD). Die genauen Namen dieser Umgebungen unterscheiden sich von Organisation zu Organisation. Es gibt hier keinen Standard, nur ein gemeinsames Verständnis von der Wichtigkeit dieser Umgebungen für den Testprozess.

Die systematische Planung und Budgetierung dieser Umgebungen erwächst aus der Aufnahme der Anforderungen an die Testbarkeit. Der Betrieb von IGR- und UAT-Umgebungen kann kostspielig sein, und da macht es Sinn, dies bereits während der Projektinitialisierung entsprechend zu planen. Nutzen Sie hierfür die Qualitätsszenarien (siehe unten).

Verwendet Ihr Projekt eine Standardsoftware, beispielsweise ein CMS, so sollten die Lizenzbedingungen analysiert werden. Nicht jede Enterprise-Software erlaubt den Gratisbetrieb verschiedener Umgebungen. Hier kommen dann schnell einige zehntausend Euro an zusätzlichen Lizenzgebühren zusammen.

Ein interessanter Punkt an dieser Stelle ist auch die Schulungsumgebung. Um Kosten zu sparen, besteht oft der Wunsch, Schulungen auf UAT durchzuführen. Dies hat aber Auswirkungen auf die Projektplanung, da während der S...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang