Mein Mentor im Gespräch

Software-Test als eigenständige Disziplin bezeichnet die systematische Prüfung von Programmen durch spezialisierte Tester, getrennt vom Entwicklungsteam. Abgerechnet wird dabei nicht nach Zeit, sondern nach Leistung: Anzahl der Testfälle, erreichter Überdeckungsgrad im Code und nachgewiesene Fehler. Entscheidend bleibt, dass jede Komponente klar definierte Ein- und Ausgaben hat, die messbar geprüft werden können.

Das Wichtigste in Kürze

• Das erste unabhängige Software-Testlabor in Europa entstand 1978, weil Harry Marsh Sneed innerhalb von Siemens keine Mitarbeiter finden konnte, die bereit waren, ausschließlich als Tester zu arbeiten.
• Tester nach Zeit zu bezahlen lehnte Harry Marsh Sneed grundsätzlich ab: Abgerechnet wurde nach Testfall, abgedeckten Programmzweigen und nachgewiesenen Fehlern, was die ungarischen Mitarbeiter direkt motivierte.
• Agile Entwicklung scheitert in der Praxis häufig daran, dass Komponenten zu groß geschnitten werden, um in einem Sprint wirklich fertiggestellt und getestet werden zu können.
• Statische Analyse allein reicht nicht aus, um Software vollständig zu validieren, weil die Spezifikation dafür auf der gleichen semantischen Ebene stehen müsste wie der Code selbst.
• Testaufwand wird von Projektleitern systematisch unterschätzt: Wer den nötigen Testaufwand realistisch benennt, riskiert, aus dem Projekt ausgeschlossen zu werden, wie das Beispiel der elektronischen Gesundheitskarte zeigt.

Warum ein unabhängiges Testlabor 1978 ein Novum war

Das erste unabhängige Software-Testlabor in Europa entstand 1978 aus einer simplen Beobachtung: Tester kosteten mehr Zeit als Entwickler. In einem Siemens-Projekt für eine interaktive Datenbankabfrage brauchte ein Team von fünf Leuten drei bis vier Tage, um Code zu schreiben, und mindestens ebenso lange, um ihn zu testen. Mehr als die Hälfte des Aufwands floss in den Test. Diese Frage, warum Testen so teuer ist, prägte die folgenden Jahrzehnte.

Harry Marsh Sneed baute das Labor auf, weil er für ein Großprojekt der Bundesbahn keine Tester in Deutschland fand. Das Projekt umfasste am Ende rund 200 Module und mehrere hunderttausend Zeilen Code. So etwas ließ sich nicht mehr konventionell wie ein kleines Vorhaben programmieren. Es brauchte eine eigene Organisation für den Test.

Die Lösung kam aus Budapest. Über einen Kontakt auf einer Testtagung in London fand Harry dort mathematisch ausgebildete Programmierer, die bereit waren, ausschließlich zu testen. In Deutschland wollte das damals niemand machen. Der Beruf des reinen Testers existierte praktisch nicht.

Bezahlung nach Leistung statt nach Zeit

Ein Tester sollte für das bezahlt werden, was er leistet, nicht für die Zeit, die er absitzt. Dieses Prinzip trug die gesamte Konstruktion des Labors. Die Abrechnung gegenüber Siemens und gegenüber den ungarischen Instituten lief nicht über Stundensätze, sondern über messbare Ergebnisse.

Vier Parameter definierten die Testleistung:

• Anzahl der Testfälle
• abgedeckte Zweige im Programm (Überdeckungsgrad)
• nachgewiesene, gefundene Fehler

Für die ungarischen Institute war das ungewohnt, weil sie ihre Leute bis dahin auf Stundenbasis an deutsche Firmen verkauft hatten. Am Ende akzeptierten sie das Modell. Die Mitarbeiter selbst bekamen einen Bonus für gefundene Fehler, und das motivierte sie sichtbar.

Diese Motivationsfrage bleibt nach Harrys Einschätzung das Kernproblem des Testens bis heute, egal ob manuell oder werkzeuggestützt getestet wird. Wer Tester an Ergebnissen beteiligt, bekommt bessere Tests.

Was beim Testen über Jahrzehnte gleich bleibt

Jeder Test vergleicht einen Gegenstand gegen einen anderen. Dieser Grundsatz hat sich seit den späten 1970er Jahren nicht verändert, ganz gleich ob das Prüfobjekt ein Batch-Programm auf einem Mainframe oder ein Webservice auf einem Cloud-Server ist.

Voraussetzung für jeden Test ist eine Baseline: eine Beschreibung dessen, was reinkommt und was bei dieser Eingabe rauskommen soll. Ohne diese definierte Soll-Vorgabe gibt es nichts, wogegen man prüfen könnte.

Harrys frühes Werkzeug, der Prüfstand, setzte genau hier an. Er nutzte eine Assertion-Sprache, mit der sich für einen Testfall festlegen ließ: wenn ein bestimmter Zustand herrscht, etwa Alter größer 90, dann muss eine bestimmte Ausgabe folgen. Der Rechner verglich Soll und Ist und zeigte die Abweichungen. Die Tester mussten anschließend herausfinden, warum eine Abweichung auftrat.

Auf Komponentenebene ist Testen damit eine formale Prüfung der Ein- und Ausgabeparameter gegen das zurückgegebene Ergebnis. Anwendungswissen wird hier nicht gebraucht. Das ändert sich erst im Integrationstest, wenn alle Module zusammengelinkt sind und das Endergebnis gegen die fachlichen Anforderungen stehen muss.

Statische Analyse: Fehler finden, ohne das Programm laufen zu lassen

Software validieren, ohne sie auszuführen, war über Jahre Harrys Ziel. Die Idee: Man gibt nur den Quellcode ein, und das Werkzeug meldet, wo Fehler und Widersprüche zur Spezifikation stecken.

Der Prüfstand hatte deshalb zwei Teile. Die dynamische Analyse ließ das Programm laufen. Die statische Analyse parste den Code, dokumentierte die Architektur (wer ruft wen auf, wer gibt welche Daten an wen weiter) und suchte nach Schwachstellen, etwa Regelverletzungen oder schwachen Strukturen.

Vollständige statische Validierung scheitert am Aufwand. Sie verlangt, dass die Spezifikation auf derselben semantischen Ebene liegt wie das Programm. Für jede Schleife, jede Fallentscheidung und jede If-Anweisung müsste man einen eigenen Test beschreiben. Das ist so teuer, dass Harry beim Notieren grober Regelverletzungen blieb.

Ein wiederkehrender Streitpunkt war das GoTo. Bis Ende der 1980er Jahre dachten viele Programmierer in Assembler: einen Zustand prüfen, springen, dazwischen Daten übertragen. Dieses Denken saß tief, und es kostete Harry viel Zeit, gegen GoTo-Konstrukte zu argumentieren.

Warum agile Entwicklung an der Komponentengröße scheitert

Agile Sprints funktionieren nur, wenn die gelieferten Komponenten klein genug sind, um in der Sprintzeit testbar und einsetzbar zu sein. Genau hier hakt es nach Harrys Erfahrung. Teams versuchen, zu große Bausteine in zwei bis vier Wochen fertigzustellen, und wenn die Zeit abläuft, schließen sie ab und übergeben etwas, das längst nicht fertig ist.

Die zentrale Frage lautet: Was bedeutet “done”? Zu welchem Grad muss getestet sein, damit ein Sprintergebnis wirklich fertig ist? Wer diese Frage nicht beantwortet, liefert nur scheinbar ab.

Die Architektur der Software muss zu der agilen Entwicklungstheorie passen.

Harry Marsh Sneed

Harry hat mehrere gescheiterte agile Projekte untersucht, darunter eines für eine Ölfirma in Wien und eines für eine Hörgerätefirma in Graz. Beide überschritten ihr Budget deutlich und wurden nicht fertig. Sein Befund: Sie hatten nicht wirklich agil gearbeitet, sondern Monster-Komponenten in einen einzigen Sprint gepresst.

Seine Forschung an der Universität Dresden ging der Frage nach, wie groß ein Webservice sein darf. Berechnet aus der Zeit, die zum Testen nötig ist, kam er auf etwa 300 bis 400 Anweisungen, je nach Sprache und Komplexität. Größer sollte ein Komponentenmodul nicht werden.

Software vor dem Test vermessen statt erst danach

Bevor du Komponenten testest, lohnt es sich, sie zu messen: Wie groß und wie komplex sind sie? Aus diesen Werten lässt sich ableiten, welche Komponente in welcher Reihenfolge geprüft wird und ob sie überhaupt in einen Sprint passt.

Dieser Ansatz arbeitet bewusst von der konkreten Größe der Bausteine her. Die verbreitete Gegenposition fordert das umgekehrte Vorgehen: oben mit den Zielen beginnen, daraus die Architektur ableiten, und die Bausteingröße ergibt sich aus dem Design. Harry hält dagegen, dass sich Probleme früher erkennen lassen, wenn man die Programme direkt misst.

Die Lehre aus vielen Projekten ist nüchtern. Schnittstellen sauber zu definieren war stets die schwierigste Aufgabe, früher bei Software-Modulen, heute bei REST und Webservices. Die Schnittstelle ist das Ein und Alles.

Wenn zu wenig getestet wird, scheitert das Projekt später

Ein knapp kalkulierter Testaufwand rächt sich. Beim Gesundheitskartenprojekt schätzte Harry einen Aufwand von mehreren tausend Manntagen allein für die Entwicklung der Tests, dazu weitere Tage für die Ausführung. Der Projektleiter warf ihn daraufhin hinaus. Die Zahl war zu groß.

Das Projekt scheiterte am Ende, weil es zu fehlerhaft war und nicht ausreichend getestet wurde. Genau diese Folge hatte Harry vorhergesagt. Der Mechanismus dahinter ist immer derselbe: Manager haben den Termin im Auge, Termin einhalten koste es, was es wolle, und der Test ist der erste Posten, an dem gespart wird.

Wer früh in ordentliche Tests investiert, zahlt einmal. Wer spart, zahlt später teurer, oft mit dem ganzen Projekt.