CSMR, eine der großen Konferenzen zum Thema Software Wartung und Reengineering: Firmen wie Samsung, EADS und SAP präsentieren hier, wie Software altert und wie man dem begegnet. Ein Topic fehlt hier allerdings völlig: Testware! Wann immer eine Applikation geändert wird, hat das doch Auswirkungen auf Testware! Wenn das nicht berücksichtigt wird bleibt Reengineering ein unkalkulierbares Unterfangen! Und Testware selbst altert doch auch? Einige Snapshots live von der Konferenz.

Immerhin schon zum 16. mal findet sie statt, die CSMR Konferenz: The European Conference on Software Maintenance and Reengineering. Inhaltlich geht es um die Fragestellung, wie dem Lehmann’schen “Law of increasing Entropy” effektiv und effizient begegnet werden kann. Diesem Gesetz zufolge verliert jedes System immer mehr an Strukturiertheit, je mehr Änderungen es erfährt. Man kennt das: Man ist froh, wenn die Umsetzung einer ursprünglichen Idee direkt funktioniert. Das muß kein IT-Unterfangen sein, das kann auch die Garten-Umgestaltung sein, ein kleines Bauwerk  (z.B. Mauer) oder auch nur eine Eigeninstallation sein (z.B. Ikea-Möbelaufbau). Zuerst wollte man nur eine kleine Gartenbank bauen: Kleiner Entwurf, direkte Umsetzung, fertig. Dann kam noch die Änderung, die Bank möge bitte auch transportierbar sein. Also Rollen dran geschraubt. Und natürlich muß die Bank auch bequem sein, also noch Kissen drauf genagelt. Und ein Sonnenschirm dran wäre auch cool. Dann noch einen Flaschenöffner für’s Bierchen, einen Sektkühler, einen Grill usw.

Und irgendwann sieht man das Ergebnis von Law of increasing entropy: Das, was ursprünglich einfach und übersichtlich gestaltet war, ist ein großes chaotisches Monster. Idee der CSMR-Konferenz ist, Methoden vorzustellen, mit denen man das System umbaut (reengineering). Typische Phänomene, die bekämpft werden, sind

• Duplizierter Code (die Bank hatte nämlich schon einen Bieröffner, aber jetzt existiert auch noch einer am Sonnenschirm).
• Toter Code (wer braucht Räder an einem solchen Moster?)
• Unverstehbarer Code (was soll das regendichte Sitzpolster unter dem Schirm?)

Ich habe ja dazu mit einigen Kollegen vor einigen Jahren sogar ein Buch geschrieben: Heißt Code-Quality-Management und beschreibt 52 solcher Phänomene als Anti-Pattern (gibt’s immer noch bei Amazon).

Ich glaube und hoffe, das Thema ist mittlerweile Best-Practice. Doch ein Thema ist gestern in der Panel-Diskussion, zu der ich als Panel-Redner eingeladen war, hochgekommen: Wie sieht es eigentlich mit Testware aus?

Testware…was ist denn das? Auch hier auf der Konferenz kamen solche Fragezeichen….eine Spontanbefragung der geschätzten 100 Teilnehmer ergab, daß nur eine Handvoll ISTQB-certified sind, das Thema Testen also insgesamt hier nicht noch nicht entsprechend Verbreitung gefunden hat.

Ok, entlang des ISTQB-Glossars ist Testware (in Deutsch als Testmittel bezeichnet) wie folgt definiert:

“Alle Artefakte, die während des Testprozesses erstellt werden und die
erforderlich sind, um die Tests zu planen, zu entwerfen oder
auszuführen. Dazu gehören: Dokumente, Skripte, Eingabedaten, erwartete
Ergebnisse, Prozeduren zum Aufsetzen und Aufräumen von
Testdaten, Dateien, Datenbanken, Umgebungen und weitere
zusätzliche Software- und Dienstprogramme, die für das Testen
verwendet werden”

Was ist denn das Problem jeglichen Reengeerings? Natürlich erst einmal, dass jede Änderung zwangsläuf einen Regressions-test nach sich zieht. Und wenn der nicht systematisch und sogar punktuell automatisiert ist kann das sehr teuer werden.

Aber was doch viel schlimmer sein kann: Ein Reengineering kann bedeuten, daß die Testware verändert werden muß. So können ganze Testobjekte obsolet werden bzw. der Testobjekt-Schnitt angepaßt werden müssen. Das wiederum hat die Anpassung ganzer Testfall-kataloge zur Folge. Und an denen wiederum hängen Testdaten und ggfs. sogar Automatisierungen.

Doch das ist nur eine Facette von Reengeering. Was ist mit der Anwendung des “Law of increasing entropies” für Testware? Auch die Testware verliert über die Zeit immer mehr an Struktur. Wer weiß schon, wieviele Testfall-Duplikate es gibt? Wieviele Testobjekte von Business-Seite her mitttlerweile obsolet sind? Wie effizient die erreichte Testabdeckung ist?

Also, die Diskussion hat mir vor allen Dingen wieder einmal drei Dinge gezeigt:

• Testware ist ein schützenswertes Artefakt. Und wenn durchschnittlich zwischen 20% und 30% des gesamten Projekt-Budgets auf QS und Test-aktivitäten entfallen, dann ist Testware ein nicht unkritischer Wert.
• Testware muß angepaßt werden, wenn das System angepaßt wird. Reengineering beschränkt sich also nie nur auf das System, sondern immer auch auf die Testware.
• Testware verliert an Struktur, d.h. auch hier gelten die üblichen Mechanismen der strukturellen Erosion. Und dagegen müssen flankierende Maßnahmen ebenso aufgesetzt werden, wie sie für Code heute angewendet werden.

Ich würde mir wünschen, daß auf der nächsten CSMR das Thema Testware-Reengineering wenigstens einen eigenen Track erhält. Meinen Beitrag melde ich damit bereits heute an!