Teil 4: Qualität von Websystemen verifizieren können

Was die Qualität von Websystemen ausmacht: Testbarkeit

Daniel Takai

© Shutterstock/Danang Setiawan

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.

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 etabliert, die eine Automatisierung der Tests über verschiedenste Endgeräte möglich machen. Wenn Sie eine breite 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 [1] 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 [2].
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.

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 vom Martin Fowler empfohlen.

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 Schulungen meist ein anderer Konfigurationsstand benötigt wird als für das Testing. Es kann also sein, dass geplante Schulungen die Releaseplanung stören, da nicht getestet werden kann. Als Anekdote kann ich hier berichten, dass ich schon erlebt habe, wie just zu Beginn einer Schulung ein Lasttest gestartet wurde. Wohl dem, der seine Planung besser im Griff hat.

Grundsätzlich ist hier derjenige im Vorteil, der die Virtualisierung seiner Umgebungen im Griff hat und flexibel auf Bedürfnisse reagieren kann. Der größte Knackpunkt ist dabei oft, dass sich Lizenzmodelle kommerzieller Produkte noch nicht an die Cloud gewöhnt haben.

Abb. 1: Logische Testkette

Abb. 1: Logische Testkette

Externe Dienste

Websysteme sind keine isolierten Inseln, sondern integrieren in der Regel unterschiedliche Services, um Geschäftsfunktionalität bereitstellen zu können. Oft sind im Rahmen eines einzigen Geschäftsprozesses mehrere externe Services beteiligt, und ihr System hat damit mehrere komplexe Abhängigkeiten. Um nun die korrekte Funktion testen zu können, gilt es zu planen, auf welcher Umgebung welche Services angelegt werden, oder ob ein Testdouble zum Zuge kommt. Und falls dies der Fall ist, welche Art von Testdouble. Die folgenden Kategorien von Testdoubles sind üblich:

Fake Objects haben eine funktionierende Implementierung, die sich sehr ähnlich wie Produktion verhält, jedoch Abstriche macht, um leichtgewichtig und schnell zu sein. So würde beispielweise ein File Sink Fake Object nicht wirklich in eine Datei schreiben. Eine transiente In-Memory-Datenbank ist ein weiteres gutes Beispiel.

Stubs antworten mit gespeicherten Antworten, die manchmal von den echten Objekten aufgezeichnet wurden. Damit eignen sie sich gut für einfache Dienste, die immer sehr ähnliche und wenig kontextsensitive Antworten liefern. Stubs sind in der Regel unflexibel und entwickeln sich manchmal zu Fake Objects weiter, wenn die Anforderungen an das Verhalten steigen und die Entwicklung „echter“ Logik notwendig wird.

Mocks sind Objekte, die mit dem erwarteten Verhalten im Rahmen der Tests mit zu erwarteten Methodenaufrufen vorprogrammiert werden. Mocks lassen sich als Stubs oder Fake Objects schwieriger wiederverwenden, sind aber flexibler.

Testservices sind Kopien der Produktionsinstanz eines Service, werden ihrem Team bereit gestellt und sind ausschließlich für das Testing vorgesehen. Es kann sein, dass ihnen eine laufende Instanz mitgeteilt wird, oder sie bekommen ein Image, das sie dann selbst betreiben können. Testservices sind oft die günstigste und einfachste Variante für die Verifikation von Software in Kombination mit externen Diensten.

Um die Testbarkeit externer Dienste zu erreichen, erstelle ich für jede geplante Umgebung eine dedizierte Bausteinsicht, die spezifiziert, welches Testdouble wo eingesetzt wird. Diese Architekturen müssen meist über einen längeren Zeitraum verhandelt werden, da Kosten rund um die Fertigung der Testdoubles entstehen. Die Bausteinsicht ist ein gutes Mittel, um zu verdeutlichen, welche Doubles für welche Tests benötigt werden.

Eine Standardintegration ist übrigens die eines Mailservers. In so gut wie jedem Webprojekt ist der Test von Inhalten ausgehender E-Mails von Bedeutung. Ein gutes Werkzeug hierfür ist MailHog, das sehr leichtgewichtig ist und die Anforderungen an das E-Mail-Testing gut unterstützt.

First Principles

Wie bereits erwähnt, benötigen wir einen Test Harness, um die automatische Testbarkeit eines Systems herzustellen. Die Funktionsweise eines Test Harness zeigt Abbildung 2. Dieses System wird in der Literatur auch „Orakel“ genannt, da wir an dieser Stelle nach transzendenter Offenbarung der Fehler unseres Systems streben [3]. Für Modultests ist dieser Harness in der Regel trivial, denn Unit Tests können heute in jeder IDE problemlos ausgeführt werden. Für Integrationstests sieht dies anders aus. Wir eingangs erwähnt, braucht es einigen Aufwand, damit der Test Harness alle Komponenten steuern kann.

Der Test Harness füttert das Zielsystem (in Abb. 2 als Komponente modelliert) mit Eingaben und misst dessen Ausgaben. Da es sich um ein Websystem handelt, spricht es HTTP, und hierfür gibt es eine stattliche Anzahl verschiedener Bibliotheken, die diese Kommunikation stark vereinfachen, zum Beispiel HtmlUnit. Unser Test kann also beispielsweise ein Formular ausfüllen und die Antwort des Systems auf Korrektheit überprüfen.

Damit können wir aber noch nicht die volle Transzendenz sicherstellen, denn manchmal möchten wir im Zielsystem eine Zustandsveränderung feststellen, die sich nicht über die HTTP Response messen lässt. Hierfür brauchen wir dann einen spezialisierten Port, der die Messung des Zustands unseres Systems erlaubt. Dieser Port ist zumeist nur für Tests gedacht, sollte also nicht notwendigerweise auf einem Produktionssystem offen sein, und kann möglicherweise die Sicherheit kompromittieren. Das Design dieser Schnittstelle will also gut überlegt sein.

Ein etabliertes Pattern, um den Zustand eines Websystems zu messen, ist der Self-Test. Es handelt sich um eine Statusseite, die die wesentlichen Systemfunktionen automatisch testet und den Zustand des Systems per HTTP-Code kommuniziert. Diese Seite kann dann im Rahmen von anderen Tests verwendet werden, um zu beurteilen, ob sich das System noch in einem ordentlichen Zustand befindet. Ein konkreter Anwendungsfall wäre ein Loadbalancer, der prüft, ob der Knoten noch lebt.

Noch ein Wort zur Notation an dieser Stelle: Abbildung 2 verwendet einen Port für die Verbindung von Komponente und Test Harness und nicht, wie oft üblich, ein Interface. Der Grund hierfür ist, dass ein Port weniger begrenzt ist, da er auch mehrere Schnittstellen darstellen kann. Zudem besteht dann im Diagramm die Möglichkeit, einen Blow-up der Komponente zu erstellen, also die Verbindung des Ports mit internen Modulen anzuzeigen.

Abb. 2: Prinzip des Test Harness

Abb. 2: Prinzip des Test Harness

Test Cases

Wenn wir einen Test Harness haben, dann können wir auch kompliziertere Szenarien gegen unser System testen. Dies ist gar nicht so einfach, da die Konstruktion dieser Szenarien neben Domänenexpertise zumeist auch ein tiefes Verständnis der Anforderungen an das System benötigt. Abbildung 3 zeigt die im Testing verwendeten Konzepte. Pro Anforderung kann es mehrere Testfälle geben, die per Testausführung dann Fehler feststellen können. Testfälle werden dabei von einem Testmanager erstellt und durch den Developer automatisiert. Der Test Harness beobachtet Fehler. Fehler und Testausführung können dann zu Qualitätsberichten zusammengefasst werden. Diese Berichte legen wiederum den Grundstein für Entscheidungen im Rahmen des Release-Managements, wie zum Beispiel den Go-Live.

Per Definition sind die erstellten Testfälle gleichzeitig User-Acceptance-Tests, d. h. das System ist in Ordnung, wenn diese automatisiert durchlaufen und grün sind. Leider funktioniert dies in der Praxis aber nicht, denn die Tests validieren nur die Anforderungen. Ob die Anforderungen tatsächlich stimmen, können Sie mit einem automatischen Test nicht feststellen. Es kommt häufig vor, dass Anforderungen nicht richtig verstanden oder dokumentiert wurden. Dies stellt man erst fest, wenn die User selbst testen oder die Anforderungen und Testfälle genau lesen, was eher selten vorkommt. Ein Mittel zum Zweck, die Akzeptanz der trockenen Anforderungskontrolle beim Fachbereich zu erhöhen, ist die Verwendung von Techniken des Behavior-driven Development. Hier werden Szenarien als Testfälle geschrieben, die sich zur automatischen Ausführung eignen, aber gleichzeitig natürlichsprachlich verfasst sind und damit vom Fach gut verstanden werden können. Ich habe gute Erfahrungen mit Behat gemacht.

Abb. 3: Wesentliche Konzepte im Testing

Abb. 3: Wesentliche Konzepte im Testing

Storage State

Ein wesentlicher Performancefaktor automatischer Integrationstests ist die Größe der Testdaten. Mehr noch als bei anderen Systemen sind Websysteme oft inhaltslastig und speichern große Mengen an Inhalten. Eine durchschnittliche Corporate-Website kommt schnell auf 20–30 GB an Daten. Dies stellt uns vor die Frage, wie unser Test Harness die Daten verwaltet. In der Regel wird ein Standard-Backend wie Drupal, TYPO3, Sitecore oder AEM eingesetzt, sodass die Technologie zur Speicherung vorgegeben ist. Wir müssen uns also „nur noch“ darum kümmern, dass die richtigen Testdaten bereitstehen und schnell geladen werden können. Bei 30 GB Daten dauert der Upload schlicht zu lange. Hieraus ergeben sich für unsere Architektur also einige Rahmenbedingungen.

Zum einen sollten die Testdaten weitestgehend kanonisch sein, um den Speicherbedarf zu minimieren: Statt eintausend hochauflösenden Bildern reichen für Funktionstests auch fünf oder sechs, wenn man gerade noch ein besonders schönes Bild zur Hand hat.

Die Testdaten müssen zudem zusammen mit den Quelltexten entwickelt werden. Hierfür ist eine möglichst einfache Pflege derselben im Entwicklungsprozess zu verankern. Ein einfaches Skript zum Upload/Download der Testdaten schafft Ergonomie und Effizienz. Besonderes Augenmerk gilt der Versionierung. Wenn die Daten zusammen mit den Quelltexten entwickelt werden, macht es Sinn, sie auch gemeinsam zu versionieren. Hier gibt es dann Probleme, wenn das Team groß und die Daten in einem einzigen SQL Dump verwaltet werden. Kommunikationsregeln im Team können dann Abhilfe schaffen, besser ist es aber, wenn Testdaten mergeable sind, d. h. mehr oder weniger atomar bearbeitet werden können.

Ein Download der Testdaten aus dem laufenden System per Skript ist bei Websystemen oft praktisch, weil dann eine existierende Redaktionsoberfläche für die Testdatenpflege verwendet werden kann.

Schließlich sollten die Testdaten leicht austauschbar sein, damit man auch die Möglichkeit hat, Last- oder Stresstests zu fahren. Hat man bereits Skripte für Up- und Download parat, ist dies einfach zu erreichen.

Ein immer wiederkehrendes Thema ist die Kopie von Produktivdaten zum Testen. Es heißt oft, es sei einfacher damit zu arbeiten, weil man die Daten nicht mehr erstellen müsste und jeden auftretenden Fehler gut reproduzieren könnte. Ich teile diese Meinung nicht. Zum einen müssen Produktionsdaten aus Datenschutzgründen anonymisiert werden, was aufwändig sein kann. Und zum anderen finden sich die Fehler nicht im Content, sondern eher in den Quelltexten oder der Konfiguration des Systems. Hat man außerdem eine gute Analysierbarkeit hergestellt, so kann der Fehler auch auf Produktion identifiziert werden und dann mit ein paar Handgriffen lokal nachgestellt werden. Hinzu kommt, dass die Produktionsdaten sehr groß sind und der Datentransfer lange dauert.

Nonfunctional Quality

Nur wenige Qualitätsziele eines Websystems lassen sich automatisch erfassen. Die meisten Ziele werden als Indikatoren erfasst und müssen im Kontext interpretiert werden. Im Buch von Stefan Toth [1] finden Sie Beispiele für solche Indikatoren. Für eine Diskussion von Qualitätsmodellen und der Messung von Qualität ist das Buch von Stefan Wagner [4] interessant. Wer große Systeme auch im Betrieb unter Druck setzen möchte, dem sei ein Blick auf die Simian Army von Netflix empfohlen.

Die einzige nicht funktionale Qualität, die sich automatisch gut messen lässt, ist die Performance. Hier kann auch der Test Harness unterstützen. Aber auch hier gibt es Fallstricke, denn es gibt viele Einflussfaktoren, die berücksichtigt werden müssen. Ein einfacher Indikator wäre, die Durchlaufzeit von bestimmten Integrationstests zu messen, um ein Gespür für die Entwicklung der Performance zu erhalten. Ich werde in dieser Artikelserie noch über Performance schreiben, sodass ich an dieser Stelle nicht näher darauf eingehen möchte.

Static Quality

Neben der Laufzeitqualität liefert die statische Quelltextanalyse wertvolle Hinweise auf die Qualität unserer Software. SonarQube ist an dieser Stelle zu einem Standard avanciert, da dieses Werkzeug auch als Open-Source-Version verfügbar ist und heute für unterschiedlichste Programmiersprachen Analyzer liefert. Es verfügt über eine gute Usability und ist robust in der Analyse. Laufzeitprobleme konnte ich noch nicht feststellen.

Soll auch die statische Codequalität in die Bewertung Ihrer Software einfließen, so gibt es eigentlich nur ein wesentliches Problem: die Erstellung der Regeln zur Analyse. Diese sind nämlich nicht standardisiert, und Sie müssen sie selber erarbeiten. Es gibt hier zwar vorgegebene Regelwerke, zum Beispiel für Java, aber die Chancen stehen gut, dass diese nicht gut zu Ihrem Projekt passen, vielleicht, weil Sie einen Codegenerator einsetzen oder das verwendete Framework Sie zu Regelverstößen zwingt. Sie werden die Regeln also zumindest anpassen müssen, und das ist eine schwierige Aufgabe. Zum einen müssen Sie an sehr viel denken, und dabei wird zu Beginn manches übersehen. Merkt man dies später und passt die Regeln an, entdeckt man dann, dass bereits an vielen Stellen gegen die neue Regel verstoßen wird. Diese Stellen im Code müssen dann bereinigt werden. Hinzu kommt, dass die Regeln rund um die Syntax nicht in jedem Fall etwas mit Qualität zu tun haben, sondern mit den persönlichen Vorlieben des Produzenten. Ironischerweise helfen die Regeln aber insbesondere hier weiter, weil es klar geregelt ist, wie die Syntax aussehen soll.

Die statische Codeanalyse hilft im Projekt die Konventionen einzuhalten und sorgt für klare syntaktische Verhältnisse. Sie finden damit aber auch potenzielle Fehler (FindBugs) und können schlechte Praktiken (PMD) identifizieren. Der Nutzen ist im Verhältnis zum Aufwand für mich gegeben, und ich empfehle stets den Einsatz, denn das System gibt seine Fehler leichter preis.

Qualitätsszenarien

Wie bei jedem Artikel dieser Serie, zeige ich auch hier Qualitätsszenarien [3] auf, die in der Kommunikation mit dem Fach nützlich sein können. Wir beginnen mit den einfachsten Szenarien:

  • Ändert ein Entwickler ein Modul des Systems, so kann er in kürzester Zeit für seine Änderung einen Unit Test schreiben.
  • Ändert ein Entwickler ein Modul des Systems, so kann er für jede Komponente, die dieses Modul verwendet, in kurzer Zeit einen Integrationstest schreiben.

Diese beiden Szenarien sind auf den ersten Blick sehr leicht zu erfüllen, aber es gibt ein paar Hürden. Für Integrationstests muss bekannt sein, in welchen Komponenten das Modul zum Zuge kommt. Außerdem lässt sich gut für die absolute Dauer von „kurz“ und „kürzer“ streiten, aber die Szenarien werden nicht automatisch ausgewertet, sondern interpretiert, und die Intention ist klar. Hat man ein externes System zu integrieren, lohnt es sich, auch hierfür ein Szenario zu spezifizieren:

  • Bei der Entwicklung kann ein Entwickler zu jeder Zeit, außer an vorab kommunizierten Servicefenstern, auf eine Testinstanz des externen Diensts XYZ zugreifen, um automatische Tests durchführen zu können.

Für die Entwickler ist es wichtig, dass es eine CI-Umgebung gibt, die die Tests ausführt:

  • Bei der Entwicklung kann ein Entwickler nach einem Commit die Ausführung eines Integrations-Builds, der eine vollständige Reihe aller automatischen Tests enthält, auf einer Integrationsumgebung nachvollziehen.

Sind Fehler behoben worden, stellt sich die Frage nach der Validierung. Hierfür ist das UAT-System vorgesehen, und es stellt sich die Frage, wie die Softwarepakete auf das System kommen:

  • Ein Testmanager kann nach der Behebung eines Fehlers durch die Entwicklung die UAT-Umgebung selbstständig mit einem neuen Softwarestand bestücken.

Danach können Testingenieure oder das Fach die Validierung vornehmen. Aus dem folgenden Szenario leitet sich die Zugänglichkeit des UAT-Systems ab:

  • Nach der Behebung eines Fehlers im Quelltext kann das Fach die Behebung auf UAT verifizieren.

Je nachdem, wie umfangreich der Qualitätsprozess in Ihrem Projekt ausfallen soll, sollten Sie die Szenarien ergänzen und vervollständigen.

Quality Strategy

In diesem Artikel haben wir die Voraussetzungen der Testbarkeit besprochen: Test Harness, Umgebungen und externe Dienste, Storage State, Integrationstests, statische Qualität und schließlich die Qualitätsszenarien selbst. Abbildung 4 fasst diese Aspekte zusammen. Um sie in Ihrem Projekt umzusetzen, ist es hilfreich, sie in einem Dokument zusammenzufassen. Diese Qualitätsstrategie kann dann im Projekt beschlossen werden. So erhalten Sie Rückendeckung von verschiedenen Stakeholdern und können die Qualität besser planen. Neben den technischen Aspekten sollte die Qualitätsstrategie nämlich auch organisatorische Aspekte beinhalten. Sie sollte dabei die Frage beantworten, wer wann wo was testen kann. Lohn der Mühe ist am Ende ein System mit weniger Fehlern.

Abb. 4: Faktoren der Testbarkeit

Abb. 4: Faktoren der Testbarkeit

Fazit

Die meisten der erwähnten Praktiken und Aspekte sind nicht neu, sondern etablierte professionelle Praxis. Neu ist hingegen, die Testbarkeit als Teil der Qualitätsanforderungen strukturiert im Zuge der initialen Analyse zu erfassen und die benötigten Budgets früh zu verhandeln. Dabei ergeben sich bei der Erstellung der Architektur immer wieder Überraschungen und versteckte Abhängigkeiten, die diese Analyse wertvoll für das Gelingen des Gesamtprojekts machen.

Qualität gibt es nicht gratis. Die vorgestellten Maßnahmen und Aspekte sind teilweise kostenintensiv, lohnen sich aber, wenn die Wartbarkeit lange erhalten bleiben soll und eine hohe funktionale Korrektheit erwünscht ist. Tatsächlich können die Kosten explodieren, wenn die besprochenen Maßnahmen nicht eingeleitet werden. Denken Sie zum Beispiel an manuelle Funktionstests, die bei jedem Release dutzende Tage Aufwand verschlingen. Ein guter Architekt sucht also die Testbarkeit zu vereinfachen, wo es nur geht.

Aufmacherbild: Software Engineer von Shutterstock / Urheberrecht: Danang Setiawan

Verwandte Themen:

Geschrieben von
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: