Freitag, 30. Mai 2008

Änderbarkeit - das Hauptkriterium für Software

Der Idealzustand manches Verwalters ist eine kristallklare Welt, in der alle Verträge fristgerecht erfüllt sind, alle Entwicklungsprojekte zum vorgesehenen Zeitpunkt die Gates durchlaufen und sein Cockpit ihm zu jedem Zeitpunkt den Überblick und die Kontrolle über seine Welt verschafft. Alles hat endlich seine Ordnung, es herrscht Planungssicherheit, das Chaos ist aus dem Betrieb verbannt.

Solche Ideale sind zwar schön, aber kraftlos. Denn das Organische siegt immer über die kristallklaren Modelle, die bei all ihrem Glanz doch anorganisch sind, klinisch tot. Wie ist es mit der Starre des Todes in der Natur? Sie dauert nicht lange, und schon beginnen die Kleinstlebewesen, aus dem gewesenen Organismus Verwertbares herauszuziehen: das chaotische Gewimmel und Gewusel setzt sich wieder durch. Die schöne klare Ordnung bestand nur einen winzigen Augenblick, wenn sie nicht überhaupt nur ein Schein ist. Was unumstösslich herrscht, ist das Leben: Die Bewegung, die Veränderung.

Eine ideale Welt des Softwaretests wird von Alexander Hofmann in der "Computerwoche" beschrieben [1]. Ausgehend von der Ist-Situation, dass 60 bis 70 Prozent der IT-Budgets für Wartung und Weiterentwicklung bestritten werden, schlägt er eine kristallklare Lösung vor. Da gibt es Kennzahlen der Software schon in der Blueprintphase. Da werden in den Softwareentwicklungsprozess weitere Abnahmezeitpunkte eingezogen, die sogenannten Q-Gates. An all diesen Konzepten mag etwas sein; aber der Ansatz ist nicht radikal genug, um die aktuellen Probleme der Softwareentwicklung wirklich zu lösen. Hofmanns Vorschläge sind zu altbacken. Weitere Q-Gates bedeuten weitere Abnahmepapiere, Verwaltungsaufwände, grössere Unbeweglichkeit aufgrund weiterer Meilensteine, fester Termine im "Gantt-Diagramm". Die von Hofmann vorgeschlagenen konventionellen Mittel der Planung und Verwaltung sind bereits jetzt überstrapaziert. Es lässt sich kein Saft mehr aus ihnen herausholen. Dennoch ist wahr: Wir brauchen tatsächlich mehr Tests, um die aktuellen Probleme der Softwareentwicklung zu meistern. Aber nicht ein oder zwei in das Gantt-Diagramm hineingeflickte neue Meilensteine, sondern tausende und abertausende von Kontrollschleifen! Die hohen Kosten für Wartung basieren auf einer unflexiblen Arbeitsweise, nicht auf fehlenden Meilensteinen.

Die Änderung der täglichen Arbeitsweise ist der Schlüssel, um von den hohen Kosten und den hohen Arbeitsbelastungen in den IT-Abteilungen herunterzukommen. Was ist ein Test? Ein Test ist eine Rückkopplung: Der Entwicklungsschritt, das Teilprojekt oder das gesamte Projekt wird darauf hin geprüft, ob es die Anforderungen erfüllt. Rückkopplungen dienen der Produktjustierung. Erwartungen können sich, wenn man sie genau formuliert, als undurchdacht erweisen. Umgekehrt zeigt mir die Rückkopplung, ob ich an den Anforderungen vorbeientwickelt habe, zum Beispiel aufgrund eines Missverständnisses. Einen Test gibt es immer: Den Test durch den Endkunden. Ein Produkt nur durch den Endkunden prüfen zu lassen, wäre jedoch katastrophal. Man kann ganz pauschal sagen: Je weniger Tests durchgeführt werden, umso mehr entfernt sich das konkrete Produkt von den Erwartungen. Je mehr Tests durchgeführt werden, desto besser ist es für das Produkt. Und zwar zu jedem Zeitpunkt - unabhängig in welcher Phase des vom Management verwendeten Gantt-Diagramms wir uns gerade befinden. Bereits bei der Erstellung der Anforderungen in der Blueprintphase kann man Anforderungen an das künftige Produkt formulieren. Je konkreter, desto besser.

Wie geschieht das konkret - eine Anforderung erstellen? Eine Anforderung besteht aus drei Teilen: Der Vorbereitung, der Duchführung und der Erwartung. Die Vorbereitung beschreibt das nötige Setup, um die angeforderte Funktion zum Einsatz zu bringen. Es soll beispielsweise ein neues Produkt getestet werden, mit dem Wareneingänge erfasst werden können. Dann kann die Exposition darin bestehen, eine logistische Belegkette von der Auftragserfassung über die Bestellung, die Anlieferung und den Rechnungseingang des Lieferanten vorzubereiten. Danach kommt es zur Durchführung: Alles ist vorbereitet, um die neue Funktion auszuführen, nun muss möglichst genau beschrieben werden, wie die neue Funktion zur Ausführung kommt. Wenn ein Benutzer den Schritt in einer bestehenden Applikation ausführt, so sind die Navigationsschritte - vorhandene und noch nicht vorhandene - zu beschreiben, die ihn zum Wareneingangsdialog und schliesslich zum Buchen der Warenbewegung führen. Dann folgt der dritte Teil der Anforderungsbeschreibung, die Erwartung: In diesem Fall wird beispielsweise erwartet, dass die Warenbewegung im SAP-System verbucht worden ist und daher in der Transaktion MB03 oder in den zuständigen SAP-Tabellen MKPF und MSEG aufgefunden und angezeigt werden kann. Besonderes Augenmerk muss in der Blueprintphase natürlich auf dem mittleren Schritt, der Durchführung liegen. Denn hier werden Funktionen beschrieben, die es noch gar nicht gibt. Ein neuer Button oder ein neues Eingabefeld in einem bereits bestehenden View kann mit Hilfe eines Screenshots visualisiert werden.

Es ist wichtig festzuhalten, dass sich jeder Blueprint, und sei er noch so komplex, als eine Sammlung solcher Anforderungen formulieren lässt. Ein Blueprint ist, ebenso wie die daraus hervorgehenden Change Requests und Entwicklungsanträge, nichts anderes als eine Menge von Anforderungen in diesem Sinne. Ein komplexes Problem ist in der Informatik nach der "cartesischen Methode" in eine Reihe von einfacheren Teilproblemen zerlegbar. Jedes Teilproblem ist für sich einfach darstellbar und formulierbar, und zwar als Anforderung. Blueprint, Change Request und Entwicklungsantrag unterschieden sich nur dadurch, dass die Anforderungen zunehmend näher am System formuliert werden können.

Wenn dieser Dreischritt - Vorbereitung, Ausführung, Erwartung - in einem geeigneten Qualitäts-Tool festgehalten wird, ist die Anforderung bereits die Grundlage des - zunächst manuellen - Testfalls. Die Zeit, um die Anforderung zu beschreiben, wurde zukunftsorientiert investiert. Die Anforderung steht nicht nur in einem Dokument, in das nach Abnahme niemand mehr hereinschaut, sondern sie ist bereits ein erster Bestandteil des zu erstellenden Produkts geworden. Das ist ein wesentlicher Unterschied zum herkömmlichen Vorgehen. Die Anforderung wird sich, sobald ein erster Code vorhanden ist, in einen Testfall verwandeln. Im Qualitäts-Tool findet man den Test an derselben Stelle, wo die Anforderung stand (und vielleicht immer noch steht, wenn sie nicht umgewandelt wird), und er ist zugleich in der Sitemap der Geschäftsprozesse korrekt klassifiziert, so dass er leicht aufgefunden werden kann.

In diesem Sinne können Anforderungen auch als Sonderfall von Tests gesehen werden. Es sind gewissermassen Testkeime. Mit Anforderungen werden die Absichten, der Kurs des Projekts im Vorhinein festgelegt. Die Entwicklungsschritte werden an den Anforderungen ausgerichtet. Dabei verwandeln sich die Anforderungen dann in reale Tests.

Tests sind der Rückkopplungsschritt im Entwicklungsprozess. Verschiedene Rückkopplungsschritte hat jeder Entwickler wie selbstverständlich in seinem Repertoire. Beispielsweise ist der Syntaxcheck eine Micro-Iteration. Nach einigen Codezeilen wird mit dem Button "Aktivieren" geprüft, ob der Code den Syntaxregeln entspricht. Wenn ja, wird er Teil des im System aktiven Codes. Der nächste Schritt sind die Unit Tests. Sie können ebenso schnell und an denselben Orten ausgeführt werden wie die Syntaxchecks und definieren die Erwartungen des Entwicklers an seinen Code. Nach längerer Arbeit an einem Problem empfehlen sich schliesslich die Funktionstests, bei denen nicht nur eine Einheit, sondern das Zusammenspiel mehrerer Einheiten in einer Anwendungssituation getestet wird. Funktionstests können in Zusammenarbeit von Beratern und Entwicklern entstehen. Unit Tests sind immer automatisch ausführbar. Funktionstests sollten es in der Regel auch sein; es kann sein, dass ein Test zuerst als manuell festgelegt wurde und erst später automatisiert wird.

Tests gehören zum produktiven Code dazu, ohne Tests ist der Code unvollständig. Eine Sammlung von Tests ist daher ein mächtiges Kapital, um den Bestand einer Anwendung zu definieren und sicherzustellen. Es kostet einen gewissen Aufwand, diese Tests auch bei Weiterentwicklungen des Systems stets aktuell zu halten. Aber dieser Aufwand zahlt sich aus. Wenn die Suite der automatischen Tests sich als zuverlässiger Gradmesser der Qualität etabliert hat, reduzieren sich die Aufwände massiv. Die Suite validiert Komponenten oder Prozesse auf Knopfdruck. Bei Änderungen zeigt sie Verletzungen bestehender Testerwartungen auf. Aber es ist auch ein geringer, aber regelmässiger Aufwand nötig, um den Betrieb der Testsuite zu gewährleisten. Und es gibt Initialaufwände, um im Team die neuen Arbeitsweise zum automatischen Testen zu erlernen und in der Verwendung des Testtools sicher zu werden. Aber nur so haben wir eine Chance, unser Tagesgeschäft beweglich zu halten und können zu jedem Zeitpunkt flexibel und mit kurzen Antwortzeiten auf Änderungen reagieren.

Machen wir die Veränderung zum Zentrum unserer Planung!

[1] Alexander Hofmann: Wie sich Softwarequalität steuern lässt. Computerwoche 20/2008, Seite 20-21.

Keine Kommentare :