Du hast keine Testdaten. Und dein Team erfindet sie sich selbst.

Stell dir vor, dein Team soll eine neue Funktion in eurer Software prüfen. Vielleicht eine neue Rechnungsstellung, ein geändertes Bestellformular oder eine Schnittstelle zum Steuerberater. Irgendwer muss das testen, bevor es an echte Kunden geht. Soweit klar.

Aber womit wird getestet? In den meisten kleinen und mittleren Unternehmen gibt es darauf keine klare Antwort. Es gibt keinen Satz sauberer Testdaten, keine definierten Testfälle und keinen Prozess, der vorgibt, wie getestet wird. Also macht jeder, was naheliegt. Der eine nimmt echte Kundendaten. Die andere denkt sich Fantasienamen und Phantasiebeträge aus. Und der Dritte testet gar nicht, weil es ihm zu aufwändig ist.

Das Ergebnis: Fehler landen beim Kunden. Rechnungen gehen mit falschen Beträgen raus. Daten werden überschrieben. Und alle wundern sich, warum die Software schon wieder Probleme macht. Dabei liegt das Problem nicht in der Software. Es liegt daran, dass niemand sie ordentlich prüft, bevor sie live geht.

Was passiert, wenn Testdaten fehlen

Ohne Testdaten gibt es kein strukturiertes Testen. Punkt. Denn Testen bedeutet nicht, einmal kurz draufzuklicken und zu schauen, ob die Seite lädt. Testen bedeutet: Funktioniert die Software unter realistischen Bedingungen? Was passiert bei Sonderfällen? Was passiert, wenn ein Feld leer bleibt oder jemand eine Zahl eingibt, wo ein Name stehen soll?

Wenn dein Team keine Testdaten hat, werden genau diese Fälle nicht geprüft. Es wird mit drei Datensätzen getestet statt mit dreihundert. Es werden nur die offensichtlichen Abläufe durchgespielt. Die fiesen Grenzfälle, die in der Praxis ständig vorkommen, fallen unter den Tisch. Das sind genau die Fehler, die dann am Montagmorgen beim Kunden aufschlagen.

Ich habe bei einem Unternehmen in Neuss erlebt, dass eine neue Rechnungssoftware drei Wochen lang falsche Mehrwertsteuer berechnet hat. Warum? Weil beim Testen nur Beträge über 100 Euro geprüft wurden. Die Kleinbeträge unter 10 Euro hatten einen Rundungsfehler. Niemand hatte sie getestet, weil niemand passende Testdaten dafür hatte.

Fantasiedaten sind gefährlich harmlos

Viele Teams greifen aus Bequemlichkeit zu Fantasiedaten. Max Mustermann bestellt 1 Stück Widget für 10 Euro. Test bestanden, alles grün. Aber was hat dieser Test wirklich bewiesen? Nichts. Denn kein echter Kunde heißt Max Mustermann und bestellt einen einzigen Artikel für einen runden Betrag ohne Rabatt, ohne Versandkosten und ohne Sonderwünsche.

Fantasiedaten sind trügerisch, weil sie ein Gefühl von Sicherheit erzeugen. Das Team glaubt, es wurde getestet. Die Chefin glaubt, die Software ist bereit. Aber in Wahrheit wurde nur der allereinfachste Fall geprüft. Die echte Welt ist komplizierter. Kunden haben Umlaute im Namen. Adressen haben Zusatzzeilen. Bestellungen haben Teillieferungen, Retouren, Gutschriften. Nichts davon taucht in Fantasiedaten auf.

Ich sage meinen Kunden immer: Eure Testdaten müssen hässlich sein. Sie müssen die Fälle abbilden, die euch im Alltag Kopfschmerzen machen. Der Kunde mit dem Apostroph im Nachnamen. Die Bestellung, die über zwei Geschäftsjahre läuft. Die Rechnung mit null Euro. Genau das muss getestet werden, nicht der Bilderbuchfall.

Echte Kundendaten sind keine Lösung

Die naheliegende Alternative zu Fantasiedaten sind echte Kundendaten. Einfach die Produktionsdatenbank kopieren und damit testen. Das klingt praktisch und realistisch. Aber es ist ein Minenfeld. Datenschutz ist hier kein Nice-to-have, sondern Gesetz. Seit der DSGVO ist klar: Personenbezogene Daten dürfen nicht einfach zu Testzwecken kopiert werden.

Stell dir vor, ein Entwickler testet mit echten Kundendaten und schickt versehentlich eine Testemail an 500 echte Kunden. Oder die Testdatenbank wird gehackt, weil sie weniger geschützt ist als das Livesystem. Das sind keine Horrorgeschichten, das passiert regelmäßig. Bei einem Handwerksbetrieb in der Nähe von Düsseldorf wurde genau das zum Problem: Testmails mit echten Namen und Beträgen gingen raus. Die Kunden waren irritiert, der Geschäftsführer hatte tagelang zu tun, das zu erklären.

Die Lösung heißt Anonymisierung oder Pseudonymisierung. Du nimmst die Struktur deiner echten Daten, ersetzt aber alle personenbezogenen Informationen durch künstliche Werte. Namen, Adressen, E-Mails, Telefonnummern, alles wird ersetzt. So hast du realistische Datenmengen und Strukturen, ohne gegen den Datenschutz zu verstoßen. Das erfordert einmalig etwas Aufwand, spart dir aber Ärger für Jahre.

Was gute Testdaten ausmacht

Gute Testdaten sind kein Zufall. Sie sind geplant. Sie bilden alle Fälle ab, die in deinem Geschäftsalltag vorkommen. Und sie bilden die Fälle ab, die selten vorkommen, aber wenn, dann richtig Schaden anrichten. Das ist der entscheidende Unterschied zwischen "wir haben mal kurz geschaut" und "wir haben gründlich getestet".

Ein guter Testdatensatz enthält Standardfälle, Grenzfälle und Fehlerfälle. Standardfälle sind die normalen Bestellungen, Rechnungen, Kundendaten. Grenzfälle sind die Extremwerte: der längste Kundenname, die größte Bestellmenge, der kleinste Betrag. Fehlerfälle sind die Eingaben, die eigentlich nicht vorkommen sollten: leere Pflichtfelder, negative Zahlen, Buchstaben im Datumsfeld.

Außerdem sollten Testdaten in ausreichender Menge vorliegen. Wenn dein Livesystem mit 10.000 Kunden arbeitet, dann teste nicht mit 5. Manche Fehler zeigen sich erst bei großen Datenmengen. Ladezeiten, Sortierungen, Suchfunktionen, all das verhält sich bei 5 Datensätzen völlig anders als bei 10.000. Ein Kollege von mir sagt immer: Teste mit der Datenmenge, die du in zwei Jahren haben wirst, nicht mit der von gestern.

Testdaten sind ein Prozess, kein einmaliger Aufwand

Viele Unternehmer denken: Okay, ich erstelle einmal Testdaten und dann bin ich fertig. Leider stimmt das nicht. Dein Geschäft verändert sich. Neue Produkte kommen dazu, Preise ändern sich, Geschäftsregeln werden angepasst. Deine Testdaten müssen mitwachsen. Sonst testest du in einem Jahr Szenarien, die es längst nicht mehr gibt, und übersiehst die neuen.

Gute Testdaten werden gepflegt. Jemand im Team ist dafür verantwortlich, sie aktuell zu halten. Wenn ein neues Feature entwickelt wird, werden die passenden Testdaten gleich mitgeliefert. Das klingt nach Mehraufwand, und ja, das ist es auch. Aber verglichen mit den Kosten eines Fehlers im Livesystem ist dieser Aufwand lächerlich gering.

Ein Beispiel aus meiner Praxis: Bei einem Kunden im Rhein-Kreis Neuss haben wir Testdaten als festen Bestandteil jedes neuen Features definiert. Kein Feature gilt als fertig, bevor die zugehörigen Testdaten existieren. Seitdem hat sich die Fehlerquote im Livesystem um mehr als 60 Prozent reduziert. Das hat nicht nur Nerven gespart, sondern auch echtes Geld. Weniger Supportanfragen, weniger Nacharbeit, weniger Entschuldigungsmails an Kunden.

Plane einmal pro Quartal ein Review deiner Testdaten ein. Stimmen sie noch mit der Realität überein? Fehlen neue Szenarien? Hat sich an euren Prozessen etwas geändert, das in den Testdaten abgebildet werden muss? Diese halbe Stunde alle drei Monate kann dir Tage an Fehlersuche ersparen.

Die wahren Kosten von fehlendem Testen

Lass uns über Geld reden. Ein Fehler, der in der Entwicklung gefunden wird, kostet fast nichts zu beheben. Ein Fehler, der beim internen Testen auffällt, kostet etwas mehr, weil er gemeldet, analysiert und behoben werden muss. Ein Fehler, der beim Kunden landet, kostet ein Vielfaches. Studien zeigen: Die Kosten steigen mit jeder Phase um den Faktor 5 bis 10.

Rechnen wir das für ein kleines Unternehmen durch. Ein Fehler in der Rechnungsstellung, der drei Tage unbemerkt bleibt. Vielleicht werden 50 falsche Rechnungen verschickt. Du brauchst jemanden, der das korrigiert, Stornos erstellt, neue Rechnungen schreibt. Kunden rufen an, wollen Erklärungen. Dein Team ist zwei Tage damit beschäftigt, das Chaos aufzuräumen, statt produktiv zu arbeiten. Konservativ geschätzt: 2.000 bis 5.000 Euro Schaden. Für einen einzigen Fehler, den gute Testdaten verhindert hätten.

Dazu kommt der Vertrauensverlust. Kunden, die eine falsche Rechnung bekommen, fragen sich: Was läuft da noch schief? Kann ich denen vertrauen? Das lässt sich nicht in Euro beziffern, aber es ist real. Gerade für KMU, die von persönlichen Beziehungen und Mundpropaganda leben, ist das Gift. Ein Handwerksmeister aus Korschenbroich hat mir das mal so gesagt: Einen neuen Kunden zu gewinnen dauert Monate. Ihn zu verlieren dauert eine falsche Rechnung.

So fängst du an, ohne alles umzukrempeln

Du musst nicht morgen eine perfekte Testdatenbank haben. Fang klein an. Setz dich mit deinem Team zusammen und fragt euch: Was sind die zehn häufigsten Vorgänge in unserem System? Bestellung, Rechnung, Kundenanlage, Retoure, was auch immer bei euch dazugehört. Für jeden dieser Vorgänge erstellt ihr drei Testfälle: einen normalen, einen schwierigen und einen, der eigentlich schiefgehen sollte.

Das ergibt 30 Testdatensätze. Das ist kein riesiger Aufwand, aber es ist ein Anfang. Schreibt sie in eine einfache Tabelle oder ein Dokument. Wer, was, welche Werte, was soll passieren. Keine Raketenwissenschaft, sondern gesunder Menschenverstand auf Papier gebracht.

Dann testet einmal damit. Und ich garantiere dir: Ihr werdet Fehler finden. Nicht vielleicht, sondern sicher. Jedes Mal, wenn ich das mit einem Kunden zum ersten Mal mache, kommen Dinge ans Licht, von denen alle dachten, sie funktionieren. Das ist kein Zeichen von schlechter Arbeit. Das ist der Normalzustand, wenn nicht systematisch getestet wird. Der erste Test ist immer der augenöffnendste.

Testdaten als Teil eurer Unternehmenskultur

Das klingt vielleicht groß für ein kleines Unternehmen. Aber im Kern geht es um etwas Einfaches: Qualitätsbewusstsein. Wenn dein Team weiß, dass jede Änderung getestet wird, bevor sie live geht, dann denkt es anders über seine Arbeit nach. Es entsteht ein Bewusstsein dafür, dass Software nicht einfach fertig ist, sondern geprüft werden muss.

Das verändert auch die Kommunikation mit externen Entwicklern oder Dienstleistern. Wenn du einen Freelancer oder eine Agentur beauftragst, kannst du fragen: Welche Testdaten habt ihr verwendet? Wie habt ihr getestet? Welche Grenzfälle habt ihr abgedeckt? Wenn die Antwort vage ist, weißt du, dass die Qualität wahrscheinlich auch vage ist.

Ich erlebe es bei meinen Kunden in der Region immer wieder: Die Unternehmen, die Testen ernst nehmen, haben weniger Stress, weniger Supportanfragen und zufriedenere Kunden. Nicht weil ihre Software perfekt ist. Sondern weil Fehler gefunden werden, bevor sie Schaden anrichten. Das ist kein Luxus für Großkonzerne. Das ist Handwerk. Und gutes Handwerk hat in NRW Tradition. Es gibt keinen Grund, warum das bei Software anders sein sollte.