Software, die hält – warum sich automatisierte Tests für den Mittelstand rechnen

„Fassen Sie das bloß nicht an – sonst geht wieder woanders etwas kaputt." Diesen Satz habe ich in Unternehmen schon oft gehört. Meistens fällt er halb im Scherz, aber der Kern ist ernst: Die Software läuft, irgendwie. Nur traut sich niemand mehr, etwas zu ändern. Jedes Update wird zum Risiko, jede neue Funktion zur Zitterpartie. Und mit jedem Monat, in dem man lieber nichts anfasst, wächst der Abstand zwischen dem, was das Unternehmen bräuchte, und dem, was die Software leisten kann.

Das ist kein technisches Randthema. Es ist eine betriebswirtschaftliche Frage. Und sie lässt sich beantworten.

Wie verbreitet das Problem wirklich ist

Man könnte meinen, das sei ein Einzelfall schlecht gewarteter Altsysteme. Die Zahlen sagen etwas anderes. Der Quality Transformation Report 2026 des Testspezialisten Tricentis hat dafür weltweit über 2.500 Fach- und Führungskräfte befragt, darunter rund 250 aus Deutschland. Das Ergebnis ist unbequem: Knapp sieben von zehn deutschen Unternehmen bringen Code wissentlich in Produktion, ohne ihn vollständig zu testen. Und fast ein Drittel beziffert den jährlichen Schaden durch mangelhafte Softwarequalität auf über eine Million US-Dollar.

Die Kosten entstehen dabei selten durch spektakuläre Ausfälle. Sie entstehen im Kleinen: durch Fehler, die erst beim Kunden auffallen, durch Nacharbeit, durch Support-Anfragen, durch Vertrauen, das verloren geht, wenn eine Rechnung falsch berechnet oder eine Bestellung nicht ausgelöst wird. Solche Dinge tauchen in keiner Projektkalkulation auf – und summieren sich trotzdem.

Was „testen" eigentlich bedeutet

Wenn ich mit Unternehmern über Tests spreche, denken viele zuerst an einen Mitarbeiter, der die fertige Software durchklickt und schaut, ob alles funktioniert. Das ist manuelles Testen, und es hat seine Berechtigung. Aber es hat zwei Schwächen: Es ist teuer, weil es Menschen bindet, und es ist nicht wiederholbar. Niemand klickt vor jedem noch so kleinen Update wochenlang alle Funktionen erneut durch.

Automatisierte Tests drehen das um. Dabei schreibt man kleine Prüfprogramme, die selbstständig kontrollieren, ob eine bestimmte Funktion das Richtige tut. Ein Test prüft zum Beispiel: Wenn ein Kunde drei Artikel zu je zehn Euro bestellt und einen Rabatt von zehn Prozent erhält, muss am Ende ein Betrag von 27 Euro herauskommen. Dieser Test läuft in Sekundenbruchteilen – und lässt sich beliebig oft wiederholen, bei jeder Änderung, automatisch.

Der entscheidende Punkt: Diese Tests bleiben. Sie sind kein einmaliger Kraftakt, sondern ein wachsendes Sicherheitsnetz. Jede geprüfte Funktion, die einmal abgesichert ist, bleibt abgesichert – auch in zwei Jahren, auch nach hundert weiteren Änderungen.

Test-Driven Development: die Reihenfolge macht den Unterschied

Ich arbeite nach einem Prinzip, das sich Test-Driven Development nennt, kurz TDD. Übersetzt heißt das: testgetriebene Entwicklung. Der Name klingt technisch, das Prinzip dahinter ist einfach – und für das Ergebnis entscheidend.

Klassisch schreibt man erst den Code und prüft danach, ob er funktioniert. Bei TDD drehe ich die Reihenfolge um. Zuerst formuliere ich den Test: Ich lege fest, was die Funktion können soll, und zwar als überprüfbare Bedingung. Erst dann schreibe ich den Code, der diesen Test erfüllt. Solange der Test nicht grün ist, ist die Aufgabe nicht erledigt.

Das hat eine unscheinbare, aber große Wirkung. Ich muss mir vor dem Programmieren klar darüber werden, was eine Funktion eigentlich leisten soll – in konkreten, prüfbaren Begriffen. Missverständnisse fallen dadurch früh auf, nicht erst am Ende. Und weil jede Funktion mit ihrem Test entsteht, wächst das Sicherheitsnetz automatisch mit der Software. Es gibt keine „lästige Testphase" am Schluss, die unter Zeitdruck gerne gestrichen wird.

Was das im Alltag konkret verändert

Der spürbarste Unterschied zeigt sich beim nächsten Update. Wenn jede wichtige Funktion durch Tests abgesichert ist, kann ich eine Änderung vornehmen und in Sekunden prüfen, ob dadurch irgendwo anders etwas kaputtgegangen ist. Die Software meldet sich selbst, bevor der Kunde es tut.

Damit verschiebt sich der Zeitpunkt, an dem Fehler auffallen – und das ist der eigentliche Hebel. Ein Fehler, der beim Entwickeln entdeckt wird, ist in Minuten behoben. Derselbe Fehler, der erst in der laufenden Anwendung beim Kunden auftritt, kostet ein Vielfaches: Fehlersuche unter Druck, Nacharbeit, Kommunikation, im schlimmsten Fall ein handfester Schaden. Je später ein Fehler entdeckt wird, desto teurer wird er. Automatisierte Tests sorgen dafür, dass „später" meistens gar nicht erst eintritt.

Für das Unternehmen bedeutet das vor allem eines: Handlungsfähigkeit. Software, die abgesichert ist, kann man weiterentwickeln, ohne bei jedem Schritt den Atem anzuhalten. Aus dem Risiko „bloß nichts anfassen" wird die Möglichkeit, die Software mit dem Betrieb mitwachsen zu lassen.

Kostet das nicht erst einmal mehr?

Diese Frage ist berechtigt, und ich beantworte sie ehrlich. Ja, Tests zu schreiben ist zunächst zusätzlicher Aufwand. Eine Funktion samt Test zu entwickeln dauert länger, als sie nur schnell hinzuschreiben. In meiner Erfahrung liegt der Mehraufwand grob bei zwanzig bis dreißig Prozent in der ersten Entwicklung.

Nur ist das die halbe Rechnung. Dem Mehraufwand am Anfang steht eine deutlich geringere Belastung über die gesamte Lebensdauer der Software gegenüber – und die ist bei Geschäftsanwendungen lang. Weniger Fehler im Betrieb, weniger Support, schnellere und gefahrlosere Erweiterungen, keine teuren Notfalleinsätze. Noch viel schlimmer sind Sicherheitsprobleme, die erst nach Jahren auffallen und bereits einen möglichen immensen Schaden angerichtet haben. Der Aufwand fällt einmal an, der Nutzen jede Woche aufs Neue. Bei Software, die ein Unternehmen über Jahre trägt, ist die Frage deshalb nicht, ob man sich Tests leisten kann, sondern ob man sich das Fehlen von Tests leisten will.

Wie KI dabei ins Spiel kommt

Ein verbreitetes Missverständnis möchte ich noch ausräumen. Gerade weil KI-Werkzeuge das Programmieren heute beschleunigen, könnte man meinen, Tests würden dadurch überflüssig. Das Gegenteil ist der Fall. Wenn Code schneller entsteht, entstehen auch potenzielle Fehler schneller. Ohne Sicherheitsnetz wächst dann vor allem das Risiko.

Ich nutze KI intensiv – auch, um Tests zu schreiben. Das nimmt mir einen Teil der Fleißarbeit ab und macht das Absichern günstiger als je zuvor. Aber die Entscheidung, was geprüft werden muss und welche Fälle wirklich kritisch sind, bleibt meine. KI ist ein hervorragender Umsetzer. Der Maßstab für Qualität kommt aus Erfahrung.

Fazit

Zuverlässige Software ist keine Frage des Glücks und kein technischer Luxus. Sie ist das Ergebnis einer Arbeitsweise, bei der Qualität von Anfang an eingebaut wird, statt am Ende gehofft zu werden. Automatisierte Tests und Test-Driven Development sind dafür kein Selbstzweck – sie sind der Grund, warum eine Anwendung auch nach Jahren noch änderbar, verlässlich und damit ein echtes Werkzeug bleibt, statt zum Risiko zu werden.

Wenn Sie eine Software planen, die Sie über Jahre tragen soll – oder wenn Sie eine bestehende Lösung haben, bei der sich niemand mehr Änderungen traut: Sprechen Sie mich an. Das erste Gespräch kostet nichts. Mehr über meine Arbeitsweise finden Sie auf jacomeit.de.