Auch genannt: Softwaretesting; englisch: software testing
Ein Softwaretest ist eine geplante Untersuchung von Software und zugehörigen Arbeitsergebnissen. Er soll Informationen darüber liefern, ob ein System, eine Komponente oder eine Änderung die festgelegten Erwartungen erfüllt und welche Qualitätsrisiken noch bestehen. Testen ist damit mehr als das bloße Finden von Fehlern: Es hilft, Qualität zu bewerten und Entscheidungen über Weiterentwicklung oder Auslieferung nachvollziehbar zu treffen. Das ISTQB-Glossar fasst Testing als Prozess im Softwareentwicklungslebenszyklus auf, der Qualität von Komponenten, Systemen und Arbeitsergebnissen bewertet.
Software verhält sich nur dann zuverlässig, wenn sie unter den relevanten Bedingungen geprüft wird. Ein Test stellt deshalb eine Frage und vergleicht ein beobachtetes Ergebnis mit einer Erwartung. Die Frage kann lauten: Wird eine Rechnung korrekt berechnet? Lässt sich ein Konto nur mit gültigen Zugangsdaten öffnen? Bleibt eine Anwendung bei vielen gleichzeitigen Anfragen bedienbar? Das Ergebnis eines Tests ist zunächst eine Beobachtung; ob daraus ein Fehler, ein Änderungsbedarf oder akzeptiertes Verhalten folgt, hängt von Anforderungen und Risiko ab.
Tests schaffen keine mathematische Garantie, dass ein Programm fehlerfrei ist. Für reale Systeme sind Eingaben, Zustände, Geräte, Netzwerke und Nutzungssituationen zu vielfältig, um jede Kombination vollständig auszuprobieren. Sinnvoll ist daher eine begründete Auswahl: Besonders wichtige Funktionen, bekannte Risikobereiche und typische wie auch ungewöhnliche Eingaben werden gezielt geprüft. Ein grüner Testlauf bedeutet somit, dass die geprüften Erwartungen erfüllt wurden – nicht, dass alle denkbaren Erwartungen abgedeckt sind.
Am Anfang steht ein überprüfbares Qualitätsziel. Daraus lassen sich Testfälle ableiten: Ausgangslage herstellen, Eingabe oder Aktion ausführen, erwartetes Ergebnis festhalten und tatsächliches Ergebnis bewerten. Ein guter Testfall beschreibt nicht nur den Klick oder den Funktionsaufruf, sondern auch die Voraussetzung und das erwartete Verhalten. So lässt sich später verstehen, was der Test tatsächlich aussagt.
Tests können auf unterschiedlichen Ebenen stattfinden. Ein Unit-Test prüft einen kleinen, abgegrenzten Teil des Programms. Integrationstests prüfen das Zusammenspiel mehrerer Teile, etwa Anwendung und Datenbank oder eine Anwendung und eine externe Schnittstelle. System- und End-to-End-Tests betrachten größere Abläufe aus Sicht der Nutzung. Daneben stehen Qualitätsmerkmale wie Sicherheit, Leistung, Zuverlässigkeit oder Bedienbarkeit. Diese Ebenen ersetzen einander nicht: Ein isoliert korrekt getesteter Baustein beweist noch nicht, dass der vollständige Bestellvorgang funktioniert.
Viele Tests werden automatisiert ausgeführt, besonders wenn sie bei jeder Änderung wiederholt werden sollen. Automatisierung macht Tests reproduzierbar und schnell ausführbar, entscheidet aber nicht selbst, ob die richtige Erwartung gewählt wurde. Exploratives, manuelles Testen bleibt etwa dort hilfreich, wo Menschen neue Nutzungspfade entdecken, Verständlichkeit beurteilen oder auffällige Ergebnisse einordnen. Nach dem Testlauf werden Abweichungen so beschrieben, dass sie nachvollziehbar reproduziert und priorisiert werden können.
Testen muss außerdem nicht bis kurz vor die Veröffentlichung warten. IBM beschreibt es als Praxis, die bereits in der Entwurfsplanung beginnt und nach der Bereitstellung fortgesetzt werden kann. Frühe Tests geben Rückmeldung zu Anforderungen und Entwurf; Beobachtung und Validierung nach einer Auslieferung können zeigen, ob sich das System in seiner tatsächlichen Umgebung wie erwartet verhält. IBM ordnet diese kontinuierliche Perspektive in moderne Entwicklungsprozesse ein.
Eine Kommune erweitert ein Online-Formular zur Beantragung eines Bewohnerparkausweises. Für die neue Adressprüfung wird zunächst getestet, ob vollständige Adressen akzeptiert und unvollständige Eingaben verständlich zurückgewiesen werden. Anschließend prüft ein Integrationstest, ob die validierten Daten korrekt an das Fachverfahren weitergegeben werden. Ein End-to-End-Test bildet den Ablauf im Browser nach: Formular öffnen, Daten eingeben, Antrag absenden und eine Bestätigung erhalten.
Zusätzlich werden Grenzfälle festgelegt: Sonderzeichen im Namen, eine sehr lange Hausnummernergänzung oder ein temporär nicht erreichbarer Dienst. Der Test liefert dann nicht nur „bestanden“ oder „fehlgeschlagen“, sondern Hinweise darauf, welche Bedingung verletzt wurde. Erst mit solchen Erwartungen lässt sich beurteilen, ob ein Fehler in der Eingabeprüfung, an der Schnittstelle oder in der Darstellung liegt.
Softwaretests begleiten neue Funktionen, Fehlerbehebungen, Sicherheitsänderungen und technische Modernisierungen. Sie dienen Teams als Rückmeldung, bevor Änderungen zusammengeführt oder ausgeliefert werden. In Verbindung mit Versionsverwaltung können automatisierte Tests beispielsweise an Änderungen eines gemeinsamen Codebestands geknüpft werden; die Versionsverwaltung selbst ersetzt die Qualitätsprüfung jedoch nicht.
Auch nach einer Auslieferung bleibt Testen relevant. Updates von Betriebssystemen, Browsern, Bibliotheken oder angebundenen Diensten können bestehende Annahmen verändern. Deshalb prüfen Teams wichtige Funktionen wiederholt und ergänzen Testfälle, wenn ein Fehler oder ein neues Risiko sichtbar wird. Für Nutzerinnen und Nutzer ist das Ergebnis idealerweise nicht ein sichtbarer Test, sondern eine Anwendung, die ihre Aufgaben unter den vorgesehenen Bedingungen verlässlich erledigt.
Ein häufiger Irrtum lautet: Viele automatisierte Tests bedeuten automatisch hohe Qualität. Die Anzahl sagt ohne Kontext wenig aus. Tests können wichtige Fälle übersehen, falsche Erwartungen festschreiben oder nur die intern bekannte Implementierung prüfen. Besonders problematisch wird es, wenn Code nur auf sichtbare Testbedingungen zugeschnitten wird. Das Digital-Magazin zeigt am Beispiel von KI-Coding-Benchmarks, warum ein Ergebnis, das eine Testumgebung ausnutzt, keine verlässliche Aussage über die tatsächliche Problemlösung liefert. Der Beitrag „GPT-5.6 Sol schummelt: Was Softwaretests jetzt lernen müssen“ ist als Kontextquelle für diese Grenze aufgenommen.
Softwaretest ist auch nicht gleichbedeutend mit Debugging. Debugging sucht und beseitigt Ursachen eines Fehlverhaltens; ein Test soll Verhalten bewerten und Abweichungen sichtbar machen. Ebenso ist Testen nicht identisch mit Qualitätssicherung im gesamten Sinn. Qualitätssicherung umfasst je nach Organisation weitere Maßnahmen, etwa Anforderungen prüfen, Entwicklungsprozesse gestalten oder Lieferanten bewerten. Tests liefern dafür wichtige Evidenz, aber nicht die gesamte Antwort.
Debugging beginnt häufig nach einem auffälligen Testergebnis: Es untersucht, warum eine Abweichung entsteht, und führt zu einer Korrektur. Der Softwaretest stellt die Abweichung fest oder bestätigt erwartetes Verhalten.
Testautomatisierung ist eine Ausführungsform von Tests, nicht deren Zweck. Automatisierte Skripte können Testfälle wiederholen; Auswahl, Erwartungen und Bewertung der Risiken müssen dennoch fachlich begründet sein.
Qualitätssicherung ist weiter gefasst als Softwaretest. Sie organisiert und verbessert Qualitätsaktivitäten im Entwicklungsprozess, während Softwaretests konkrete Informationen über Software und zugehörige Arbeitsergebnisse liefern.