Deine Software hat keine Tests. Und jedes Update ist ein Glücksspiel.

Stell dir vor, du fährst jeden Morgen mit einem Auto zur Arbeit, bei dem niemand jemals die Bremsen geprüft hat. Klingt verrückt? Genau das passierst aber in vielen Unternehmen mit ihrer Software. Es wird verändert, erweitert, aktualisiert. Aber niemand prüft systematisch, ob danach noch alles funktioniert.

Ich erlebe das regelmäßig bei Unternehmen hier in der Region, ob in Neuss, Korschenbroich oder Düsseldorf. Da gibt es eine Individualsoftware oder ein stark angepasstes System. Irgendwann steht ein Update an. Und dann halten alle die Luft an und hoffen, dass nichts kaputtgeht. Das ist kein Plan. Das ist ein Glücksspiel.

Dieser Artikel erklärt dir, warum fehlende Tests dein Unternehmen echtes Geld kosten. Und was du konkret tun kannst, damit Updates und Änderungen nicht mehr zum Zittern führen. Du musst dafür kein Entwickler sein. Du musst nur verstehen, warum das Thema auf deinen Schreibtisch gehört.

Was Software-Tests eigentlich sind. Ganz ohne Fachchinesisch.

Wenn Entwickler von Tests sprechen, meinen sie kleine Programme, die automatisch prüfen, ob die echte Software richtig funktioniert. Stell dir das so vor: Du hast einen Online-Shop. Ein Test würde automatisch prüfen, ob ein Kunde etwas in den Warenkorb legen kann, ob der Preis stimmt und ob die Bestellung durchgeht. Das passiert auf Knopfdruck, in Sekunden, ohne dass ein Mensch klicken muss.

Daneben gibt es manuelle Tests. Das bedeutet, jemand klickt sich durch die Software und schaut, ob alles funktioniert. Das ist besser als nichts. Aber es ist langsam, fehleranfällig und teuer. Menschen übersehen Dinge. Besonders wenn sie zum zehnten Mal die gleiche Funktion prüfen sollen. Automatisierte Tests hingegen werden nie müde und vergessen nichts.

Das Ziel ist nicht Perfektion. Kein System der Welt ist zu 100 Prozent getestet. Aber es gibt einen gewaltigen Unterschied zwischen null Tests und einer soliden Grundabdeckung. Schon mit Tests für die wichtigsten Funktionen deiner Software senkst du das Risiko dramatisch. Du brauchst keinen Vollkasko-Schutz, aber eine Haftpflicht sollte drin sein.

Warum das Thema bei KMU fast immer unter den Tisch fällt.

In großen Konzernen gibt es eigene Teams, die sich nur um Qualitätssicherung kümmern. Bei einem Mittelständler mit 20 oder 50 Mitarbeitern sieht die Welt anders aus. Da wird Software oft unter Zeitdruck gebaut. Der Chef will Ergebnisse sehen. Die Entwickler konzentrieren sich auf neue Funktionen. Tests schreiben? Das machen wir später. Später kommt nie.

Dazu kommt ein psychologisches Problem. Tests sind unsichtbar. Wenn ein Entwickler eine neue Funktion baut, kann man das zeigen. Ein Formular, ein Dashboard, ein neues Feature. Tests dagegen sieht niemand. Sie laufen im Hintergrund. Es gibt keine bunte Oberfläche, die man dem Chef präsentieren kann. Deshalb werden sie als Erstes gestrichen, wenn das Budget knapp wird oder die Deadline drückt.

Viele Unternehmer wissen auch schlicht nicht, dass sie nach Tests fragen sollten. Wenn du ein Haus bauen lässt, fragst du nach Statik und Bauabnahme. Bei Software fragt kaum jemand: Wie wird sichergestellt, dass das alles funktioniert? Nicht heute, sondern auch in sechs Monaten, wenn Änderungen dazukommen. Diese Frage zu stellen ist kein Misstrauen gegenüber dem Entwickler. Es ist gesunder Menschenverstand.

Was passiert, wenn ein Update schiefgeht. Echte Beispiele.

Ein Handwerksbetrieb aus NRW hat mich letztes Jahr kontaktiert. Sie hatten eine Branchensoftware für Auftragsplanung, die von einem externen Dienstleister angepasst worden war. Der Dienstleister hat ein Update eingespielt. Danach wurden Arbeitszeiten falsch berechnet. Nicht offensichtlich falsch, sondern subtil. Mal eine halbe Stunde zu wenig, mal eine Stunde zu viel. Es hat drei Wochen gedauert, bis es jemandem aufgefallen ist. Die falsch berechneten Löhne mussten korrigiert werden. Der Aufwand: mehrere Tausend Euro und viel Ärger mit den Mitarbeitern.

Ein anderer Fall: Ein kleiner Online-Händler hat sein Shopsystem aktualisiert. Nach dem Update hat die Schnittstelle zum Zahlungsanbieter nicht mehr richtig funktioniert. Bestellungen kamen rein, aber die Zahlungen wurden nicht korrekt bestätigt. Kunden bekamen keine Bestätigungsmail. Einige haben doppelt bestellt, andere haben genervt aufgegeben. Der Umsatzverlust an einem einzigen Wochenende lag bei geschätzt 8.000 Euro. Ein einfacher automatisierter Test hätte geprüft, ob die Zahlungsschnittstelle nach dem Update noch antwortet.

Das sind keine Extremfälle. Das sind Alltagssituationen. Jedes Mal, wenn Software verändert wird, ohne dass jemand prüft, ob die bestehenden Funktionen noch laufen, entsteht ein Risiko. Und je länger ein Fehler unentdeckt bleibt, desto teurer wird er. Ein Bug, der am selben Tag gefunden wird, kostet vielleicht eine Stunde Entwicklerzeit. Ein Bug, der drei Monate unentdeckt bleibt, kann fünfstellige Folgekosten verursachen.

Die versteckten Kosten von fehlenden Tests.

Die offensichtlichste Konsequenz sind Fehler, die Kunden oder Mitarbeiter treffen. Aber es gibt Kosten, die du auf keiner Rechnung siehst. Zum Beispiel die Angst vor Veränderung. Wenn jedes Update ein Risiko ist, wird irgendwann niemand mehr updates machen wollen. Dein System bleibt stehen. Sicherheitslücken werden nicht geschlossen. Neue Funktionen werden nicht eingebaut. Die Software veraltet, weil alle Angst haben, sie anzufassen.

Dann gibt es den Zeitaufwand für manuelles Testen. Irgendjemand muss ja prüfen, ob alles noch geht. Oft sind das deine Mitarbeiter. Die klicken sich nach jedem Update durch zehn Masken und prüfen, ob Rechnungen noch stimmen, ob Kunden angelegt werden können und ob der Export funktioniert. Das dauert Stunden. Manchmal einen ganzen Tag. Und sie finden trotzdem nicht alles, weil sie nicht jede Ecke der Software kennen.

Der dritte versteckte Kostenfaktor: Entwickler, die ohne Tests arbeiten, brauchen länger für Änderungen. Das klingt widersprüchlich, weil Tests ja zusätzliche Arbeit sind. Aber in der Praxis ist es genau andersherum. Ohne Tests muss ein Entwickler bei jeder Änderung manuell nachvollziehen, ob er etwas kaputt gemacht hat. Er traut sich weniger, Code zu verbessern. Er baut lieber drumherum, statt sauber zu lösen. Das führt zu immer komplexerem, schwerer wartbarem Code. Und das kostet dich Geld, bei jeder weiteren Änderung mehr.

Was gute Testabdeckung für dein Unternehmen konkret bedeutet.

Wenn deine Software eine solide Testbasis hat, ändert sich die Dynamik komplett. Ein Entwickler kann eine Änderung machen und innerhalb von Minuten sehen, ob er etwas kaputt gemacht hat. Nicht nach drei Wochen, wenn die Buchhaltung sich meldet. Nicht nach einem Wochenende, an dem Kunden keine Bestellungen aufgeben konnten. Sondern sofort, auf seinem Rechner, bevor der Code jemals auf eurem echten System landet.

Für dich als Unternehmer bedeutet das: Updates werden planbar. Du kannst neue Funktionen schneller einführen, weil das Risiko überschaubar ist. Deine Mitarbeiter müssen nicht mehr halbe Tage mit manuellem Testen verbringen. Und wenn doch mal ein Fehler durchrutscht, ist die Wahrscheinlichkeit höher, dass er in einem unkritischen Bereich liegt, weil die wichtigen Funktionen abgesichert sind.

Gute Tests geben dir auch Verhandlungsmacht gegenüber Dienstleistern. Wenn du den Entwickler wechseln willst oder musst, sind Tests eine Form von Dokumentation. Sie beschreiben, was die Software tun soll. Ein neuer Entwickler kann sich anhand der Tests einarbeiten und versteht schneller, wie das System funktioniert. Ohne Tests bist du komplett davon abhängig, dass der bisherige Entwickler alles im Kopf hat. Und wenn der nicht mehr verfügbar ist, stehst du vor einer Blackbox.

Was du als Nicht-Techniker konkret verlangen kannst.

Du musst keine Tests schreiben können. Aber du musst wissen, was du verlangen kannst. Punkt eins: Mach Tests zum Bestandteil jedes Auftrags. Wenn du Software entwickeln lässt, gehört in den Vertrag, dass die Kernfunktionen durch automatisierte Tests abgedeckt werden. Das ist keine Sonderleistung, das ist Handwerk. Genau wie ein Elektriker seine Leitungen nach der Installation prüft.

Punkt zwei: Lass dir zeigen, dass Tests existieren und funktionieren. Ein guter Entwickler kann dir in fünf Minuten demonstrieren, wie die Tests laufen. Du siehst dann eine Ausgabe, die sagt: 47 Tests gelaufen, alle bestanden. Oder: 47 Tests gelaufen, 2 fehlgeschlagen. Das verstehst du, auch ohne Programmierkenntnisse. Wenn ein Entwickler das nicht zeigen kann oder will, ist das ein Warnsignal.

Punkt drei: Priorisiere. Nicht alles muss getestet werden. Aber die Dinge, die dein Geld verdienen, sollten es unbedingt sein. Zahlungsprozesse, Auftragsabwicklung, Kundenkommunikation, Datenexporte für die Buchhaltung. Wenn diese Bereiche getestet sind, bist du für den Alltag gut aufgestellt. Frag deinen Entwickler: Was sind die kritischsten Funktionen, und wie sind sie abgesichert? Das ist eine Frage, die jeder Unternehmer stellen sollte.

Aber Tests kosten doch extra? Ja. Und sie sparen mehr.

Das ist der häufigste Einwand, den ich höre. Tests schreiben kostet Zeit, und Zeit kostet Geld. Das stimmt. Für ein typisches Projekt erhöhen Tests den initialen Entwicklungsaufwand um etwa 15 bis 30 Prozent. Bei einem Projekt, das 20.000 Euro kostet, reden wir also von 3.000 bis 6.000 Euro mehr. Das klingt erst mal nach viel.

Aber jetzt die Gegenseite: Ein einziger schwerer Bug in der Produktion kann dich schnell 5.000 bis 20.000 Euro kosten. Entgangene Umsätze, Fehlersuche, Hotfixes am Wochenende zum Notfall-Stundensatz, verärgerte Kunden, die nicht wiederkommen. Und das ist nur ein Vorfall. Über die Lebensdauer einer Software kommen Updates, Anpassungen, neue Anforderungen. Jedes Mal ohne Netz und doppelten Boden unterwegs zu sein, summiert sich.

Ich vergleiche es gerne mit einer Versicherung. Niemand zahlt gerne Versicherungsbeiträge. Aber wenn der Schaden da ist, bist du froh, dass du eine hast. Tests sind deine Versicherung gegen den Moment, in dem jemand 'nur mal schnell was ändert' und danach drei Tage Feuerwehr gespielt wird. Langfristig sparst du mit Tests Geld. Das ist keine Theorie, das ist die Erfahrung aus hunderten von Projekten in der gesamten Branche.

Wie du mit bestehender Software anfängst, die keine Tests hat.

Vielleicht denkst du jetzt: Schön und gut, aber meine Software gibt es seit fünf Jahren und hat null Tests. Muss ich jetzt alles neu machen? Nein. Das wäre weder wirtschaftlich noch nötig. Der beste Ansatz ist, dort anzufangen, wo es am meisten wehtut. Welche Funktionen sind am wichtigsten? Wo gab es in der Vergangenheit die meisten Fehler? Dort setzt du zuerst an.

In der Praxis sieht das so aus: Dein Entwickler identifiziert die zehn kritischsten Abläufe in der Software. Auftragsanlage, Rechnungserstellung, Kundendaten-Export, was auch immer bei dir das Kerngeschäft abbildet. Für diese zehn Abläufe werden Tests geschrieben. Das dauert je nach Komplexität ein paar Tage bis wenige Wochen. Danach hast du ein Sicherheitsnetz für die wichtigsten Bereiche. Alles andere kann Stück für Stück ergänzt werden, immer wenn sowieso etwas geändert wird.

Diese Strategie nennt man in der Entwicklung 'nachträgliches Testen' oder 'Retrofit'. Es ist nicht ideal, aber es ist realistisch. Und es ist tausendmal besser als der Status quo. Jeder Test, der heute geschrieben wird, schützt dich ab morgen. Nach einem halben Jahr hat deine Software plötzlich eine brauchbare Testbasis, und Updates fühlen sich nicht mehr an wie russisches Roulette.

Tests als Investition in deine Unabhängigkeit.

Ich habe es weiter oben schon angedeutet, aber dieser Punkt ist mir so wichtig, dass er einen eigenen Abschnitt verdient. Gut getestete Software macht dich unabhängig. Unabhängig vom aktuellen Entwickler, unabhängig vom Dienstleister, unabhängig vom Mitarbeiter, der das System kennt. Tests beschreiben in maschinenlesbarer Form, was deine Software tun soll. Das ist Wissen, das im System steckt, nicht in einem einzelnen Kopf.

Ich habe Projekte übernommen, bei denen es Tests gab. Und ich habe Projekte übernommen, bei denen es keine gab. Der Unterschied ist gewaltig. Mit Tests kann ich innerhalb von Tagen produktiv mitarbeiten, weil ich sehe, was erwartet wird. Ohne Tests taste ich mich wochenlang durch fremden Code und hoffe, nichts kaputtzumachen. Ratet mal, welches Szenario für den Kunden billiger ist.

Wenn du als Unternehmer langfristig denkst, und das solltest du, dann sind Tests ein Stück Infrastruktur. Genau wie ein sauberer Serveraufbau, eine ordentliche Dokumentation oder ein gepflegtes Backup. Es ist nichts Glamouröses. Aber es ist das, was den Unterschied macht zwischen einem System, das dich zehn Jahre begleiten kann, und einem, das in drei Jahren so fragil ist, dass niemand es mehr anfassen will.