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, erreichte Testabdeckung 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 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: Testen kostete mehr Zeit als Entwickeln. 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.
Drei Parameter definierten die Testleistung:
- Anzahl der Testfälle
- abgedeckte Zweige im Programm (Testabdeckung)
- 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.
Häufig gestellte Fragen
Warum kostet das Testen oft mehr als das Programmieren selbst?
Weil der Prüfaufwand mit der Zahl der Kombinationen wächst, während der Code schnell geschrieben ist. In einem Siemens-Projekt für eine interaktive Datenbankabfrage brauchte ein Team von fünf Leuten drei bis vier Tage zum Programmieren und mindestens ebenso lange zum Testen. Mehr als die Hälfte des Gesamtaufwands floss in den Test. Diese Beobachtung führte 1978 zum ersten unabhängigen Testlabor Europas.
Lässt sich Testarbeit anders abrechnen als nach Stunden?
Ja. Harry Marsh Sneed rechnete die Arbeit seines Testlabors nicht über Stundensätze ab, sondern über messbare Ergebnisse: Anzahl der Testfälle, abgedeckte Zweige im Programm und nachgewiesene Fehler. Die ungarischen Institute, die ihre Leute bis dahin auf Stundenbasis vermittelt hatten, akzeptierten das Modell. Die Tester selbst erhielten einen Bonus für gefundene Fehler, was sie sichtbar motivierte.
Was braucht man mindestens, um überhaupt testen zu können?
Eine Baseline: eine Beschreibung dessen, was hineingeht und was bei dieser Eingabe herauskommen soll. Ohne definierte Soll-Vorgabe gibt es nichts, wogegen geprüft werden könnte. Jeder Test vergleicht einen Gegenstand gegen einen anderen, und dieses Prinzip gilt unabhängig davon, ob das Prüfobjekt ein Batch-Programm auf einem Mainframe oder ein Webservice in der Cloud ist.
Brauchen Tester fachliches Anwendungswissen?
Auf Komponentenebene nicht. Dort ist Testen eine formale Prüfung der Ein- und Ausgabeparameter gegen das zurückgegebene Ergebnis, und dafür genügt die technische Spezifikation. Anwendungswissen wird erst im Integrationstest nötig, wenn alle Module zusammengelinkt sind und das Endergebnis gegen die fachlichen Anforderungen gestellt werden muss.
Kann statische Analyse das Ausführen von Programmen ersetzen?
Nein. Eine vollständige statische Validierung verlangt, dass die Spezifikation auf derselben semantischen Ebene liegt wie das Programm: Für jede Schleife, jede Fallentscheidung und jede If-Anweisung müsste ein eigener Test beschrieben werden. Dieser Aufwand ist praktisch nicht zu bezahlen. Sneeds Prüfstand beschränkte die statische Seite deshalb auf Architekturdokumentation und das Notieren grober Regelverletzungen.
Wie groß darf eine Komponente oder ein Webservice sein?
Etwa 300 bis 400 Anweisungen, je nach Sprache und Komplexität. Diese Zahl stammt aus Sneeds Forschung an der Universität Dresden und ist aus der Zeit berechnet, die zum Testen der Komponente nötig ist. Größer sollte ein Komponentenmodul nicht werden, weil es sonst innerhalb einer Sprintzeit nicht mehr fertig getestet werden kann.
Warum scheitern agile Projekte, obwohl sie in Sprints arbeiten?
Weil die Komponenten zu groß geschnitten sind. Läuft die Zeit ab, schließen Teams den Sprint ab und übergeben etwas, das längst nicht fertig ist. Sneed untersuchte mehrere gescheiterte Projekte, darunter eines bei einer Ölfirma in Wien und eines bei einer Hörgerätefirma in Graz: Beide überschritten das Budget deutlich. Sein Befund war, dass Monster-Komponenten in einzelne Sprints gepresst wurden.
Was passiert, wenn der Testaufwand realistisch geschätzt wird?
Er wird häufig als zu hoch abgelehnt. Beim Projekt der elektronischen Gesundheitskarte nannte Sneed mehrere tausend Manntage allein für die Entwicklung der Tests, dazu weitere Tage für deren Ausführung. Der Projektleiter warf ihn daraufhin hinaus. Das Projekt scheiterte später an zu vielen Fehlern. Manager haben den Termin im Auge, und der Test ist der erste Posten, an dem gespart wird.
