Eine zentrale Realität in der Softwareentwicklung wird gerne verdrängt: Pro tausend Zeilen Code entstehen im Durchschnitt 1 bis 50 Fehler.
Pro tausend Zeilen Code treten im Durchschnitt etwa 1 bis 50 Fehler auf. Praktisch fehlerfreie Software gibt es nicht.
Genau deshalb stellt sich beim Testen nicht nur die Frage, ob getestet wird, sondern vor allem wie intensiv, mit welchem Ziel und mit welchem Anspruch.
Muss wirklich jeder Fehler gefunden werden? Oder wird – bewusst oder unbewusst – unterschiedlich intensiv gesucht, beispielsweise in den Kategorien Absturz, fehlerhafte Berechnung, fehlerhafte Datenverarbeitung oder Layout?
Diese Frage ist nicht nur organisatorisch relevant. Sie ist unmittelbar eine Frage der Verantwortung im Projekt.
Unzureichendes Testen führt nicht nur zu Fehlern, sondern regelmäßig zu Mehrkosten, Projektverzögerungen und Vertrauensverlust beim Auftraggeber.
Ein häufiger Fehler im Projektalltag besteht darin, ein System entlang der eigenen Entwicklungslogik zu testen. Dann prüft man vor allem, ob die Entwickler ihren eigenen Gedankengang reproduzieren können.
Genau so darf professioneller Softwaretest nicht aufgebaut sein.
Stattdessen muss vom fachlichen Soll ausgegangen werden:
- Ein Berechnungsfall wird fachlich modelliert,
- das erwartete Ergebnis wird vorab bestimmt,
- ein Report oder eine Auswertung wird vorher skizziert,
- erst danach wird verglichen, was das IT-System tatsächlich liefert.
Nur so lässt sich sauber beurteilen, ob das System fachlich korrekt arbeitet – und nicht nur technisch irgendwie reagiert.
In vielen Projekten wird zu oberflächlich geprüft. Dann heißt es: „Das Diagramm ist doch da.“
Ja – das Diagramm ist sichtbar. Aber vielleicht mit falschen Farben, falschen Werten, falscher Skalierung oder einer fachlich irreführenden Aussage.
Genau solche Fehler werden erstaunlich oft übersehen, wenn Tester nicht vorher ein klares Soll-Ergebnis erarbeitet haben oder erhalten.
Wer nur prüft, ob etwas angezeigt wird, testet zu wenig. Geprüft werden muss auch, ob Inhalt, Aussage und Darstellung fachlich richtig sind.
Künstliche Intelligenz kann inzwischen durchaus brauchbaren Code erzeugen – vor allem dann, wenn eine gute modulare Struktur vorgegeben wird und die Aufgabe in kleinere, klar abgegrenzte Blöcke zerlegt ist.
Im Grunde gilt hier dasselbe wie in einem guten Entwicklungsteam: Klare Struktur, saubere Schnittstellen und überschaubare Aufgaben verbessern die Qualität.
Aber auch gut erzeugter Code – ob von Menschen oder mit KI-Unterstützung – muss konsequent getestet werden. Denn die entscheidende Frage lautet nicht nur, ob Code erzeugt wurde, sondern ob das System unter realen Bedingungen zuverlässig die fachliche Erwartung erfüllt.
Fehler entstehen nicht nur im Code, sondern vor allem im fachlichen Verständnis – und genau dort setzt Testen an
Automatisierte Testszenarien sind sinnvoll und unverzichtbar. Sie helfen insbesondere bei Regressionstests, bei standardisierten Prüfschritten und bei der schnellen Rückmeldung nach Änderungen.
Trotzdem reichen sie bei weitem nicht aus.
Der Grund ist einfach: Nutzer verhalten sich nicht wie Testskripte.
Nutzer klicken unerwartet auf Schaltflächen, schließen versehentlich den Browser, verwenden den Zurück-Button, laden Seiten neu oder kombinieren Bedienfolgen, die in keinem Standardszenario vorgesehen waren.
Gerade browsergesteuerte Systeme sind deshalb anspruchsvoll zu testen. Die Kreativität realer Nutzer lässt sich technisch nur begrenzt steuern. Genau deshalb braucht es zusätzlich manuelle, erfahrungsgeleitete Tests mit Blick auf reales Verhalten.
Testen ist nicht nur eine technische Aufgabe. Es ist auch eine Verantwortungsfrage. Denn mit dem Testumfang wird faktisch entschieden, welche Risiken ein Projekt bewusst tragen will – und welche nicht.
Wer Testtiefe reduziert, spart nicht einfach Aufwand. Er verschiebt Risiken in die Produktivphase, zu den Anwendern oder zum Auftraggeber. Genau deshalb müssen Verantwortlichkeiten, Testschwerpunkte und Abnahmekriterien vorab klar festgelegt werden.
Besonders kritisch ist dies überall dort, wo Berechnungen, rechtlich relevante Daten, Abrechnungen, Steuerungen oder sicherheitsnahe Funktionen betroffen sind. In solchen Fällen ist unzureichendes Testen nicht nur ein Qualitätsproblem, sondern schnell auch ein Haftungs- und Führungsproblem.
In vielen Projekten wird der Aufwand für das Testen systematisch unterschätzt. Codieren und Testen stehen nicht in einem einfachen Verhältnis von „erst bauen, dann kurz prüfen“.
Je nach Kritikalität, Komplexität und Integrationsgrad kann der Testaufwand einen erheblichen Anteil des Gesamtaufwands erreichen – teilweise in einer Größenordnung, die an den eigentlichen Implementierungsaufwand heranreicht oder ihn bei komplexen Szenarien sogar übersteigt.
Wer sauber entwickeln will, muss daher von Anfang an akzeptieren: Code ist erst dann belastbar, wenn auch sein Verhalten belastbar geprüft wurde.
Anders formuliert: Nicht die Anzahl geschriebener Codezeilen entscheidet über Projektqualität, sondern die Qualität des nachweisbar richtig arbeitenden Systems.
Nicht jeder Fehler ist gleich kritisch. Ein Layoutfehler kann störend sein. Ein Berechnungsfehler kann wirtschaftlich oder rechtlich gravierende Folgen haben. Ein Absturz kann die Nutzbarkeit des gesamten Systems infrage stellen.
Professionelles Testen braucht deshalb eine bewusste Priorisierung:
- Welche Fehlerklassen sind besonders kritisch?
- Welche Funktionen sind geschäftskritisch?
- Wo ist besonders hohe Testtiefe erforderlich?
- Welche Restrisiken sind akzeptabel – und welche nicht?
Ohne diese Klärung bleibt Testen oft unscharf, ineffizient und lückenhaft.
Softwaretest ist keine Pflichtübung am Ende eines Projekts, sondern ein zentraler Teil der Qualitäts- und Führungsverantwortung.
Wer hier spart, entscheidet sich nicht für Effizienz – sondern für spätere Probleme.
Professionelles Testen bedeutet, nicht entlang der Entwicklerlogik zu prüfen, sondern gegen fachlich definierte Soll-Ergebnisse. Es bedeutet außerdem, automatisierte und manuelle Tests sinnvoll zu kombinieren, kritische Fehlerklassen bewusst zu priorisieren und reales Nutzerverhalten ernst zu nehmen.
Wer Testen nur als technische Kontrolle versteht, testet zu wenig. Wer Testen als Absicherung fachlicher Verantwortung begreift, schützt Projekte, Ergebnisse und Vertrauen.