Warum diese Phase unterschätzt wird

Testen gilt als die Phase, die kommt, wenn die eigentliche Arbeit getan ist. Der Code steht, das Feature läuft, der Sprint ist abgeschlossen. Was bleibt, ist die Bestätigung, dass alles funktioniert. Oder so ähnlich. Diese Vorstellung ist so verbreitet wie sie folgenreich ist.

In der Realität wird die Testphase in vielen Projekten weniger als eigenständige Disziplin behandelt und mehr als Puffer. Wenn Entwicklung länger dauert als geplant, was fast immer passiert, wird die Zeit woanders genommen. Beim Testen. Schließlich hat das Team während der Entwicklung schon geschaut, ob der Code läuft. Was soll da noch großartig gefunden werden?

Das Imageproblem der Testphase hat eine tiefere Wurzel. Testen wird oft als reaktive Tätigkeit missverstanden, als Prüfung dessen, was andere gebaut haben. Wer das glaubt, behandelt Tester als Qualitätskontrolle am Ende eines Fließbands. Das greift zu kurz. Denn Testen ist im Kern eine erkenntniserzeugende Disziplin. Es geht nicht nur darum, zu bestätigen, dass das System tut, was es soll, sondern herauszufinden, was passiert, wenn es das nicht tut. Dieser Unterschied zwischen Bestätigung und Entdeckung ist der entscheidende.

Was diese Phase wirklich ist

Die Testphase überprüft, ob die Software das leistet, was in Analyse und Design vereinbart wurde und ob sie es unter realen Bedingungen zuverlässig tut. Sie empfängt, was die Entwicklung geliefert hat und gibt es weiter an die Bereitstellung. Aber nur, wenn das System bewiesen hat, dass es diesen nächsten Schritt verdient.

Im Kern beantwortet die Testphase drei Fragen:

• Tut das System das, was es tun soll?

• Tut es das auch dann, wenn unerwartete Eingaben, Lasten oder Umgebungen auftreten?

• Können wir mit ausreichender Sicherheit sagen, dass wir das wissen?

Diese drei Dimensionen sind nicht gleichwertig in ihrer Reihenfolge. Die erste ist die Mindestanforderung. Die zweite ist das, was echte Qualität ausmacht. Die dritte ist die unbequeme. Denn sie zwingt dazu, den eigenen Erkenntnisstand ehrlich einzuschätzen, nicht nur zu hoffen, dass nichts fehlt.

Testen lässt sich in zwei Ebenen denken, die beide notwendig sind.

• Die funktionale Ebene prüft das Verhalten: Stimmt die Logik? Werden Grenzfälle korrekt behandelt? Reagiert das System auf Fehleingaben so, wie es das sollte? Hier geht es um Korrektheit.

• Die nicht-funktionale Ebene prüft die Qualitätseigenschaften: Ist das System schnell genug unter Last? Ist es sicher gegen Angriffsvektoren? Ist es stabil über Zeit? Hier geht es um Verlässlichkeit und genau diese Ebene wird am häufigsten unterschätzt oder auf später verschoben, bis „später" zu spät ist.

Im SDLC nimmt die Testphase eine paradoxe Position ein. Sie ist die Phase, die am direktesten mit der Entwicklung verbunden ist und gleichzeitig die, die am stärksten von allem abhängt, was in den Phasen davor passiert ist. Eine lückenhafte Analyse produziert fehlende Akzeptanzkriterien, die niemanden leiten, was überhaupt getestet werden soll. Ein schwaches Design produziert Systemteile, die sich nur als Ganzes testen lassen, weil Komponenten nicht isolierbar sind. Und eine Entwicklung, die Testbarkeit nicht mitgedacht hat, übergibt Code, bei dem Testen zur Detektivarbeit wird.

Das Verhältnis zu den angrenzenden Phasen:

Menschen, nicht nur Prozesse

Testen wirkt von außen wie eine technische Disziplin. Testfälle, Testpläne, Fehlerlisten. Was dabei übersehen wird: Die Testphase ist hochgradig sozial und genau diese Dimension entscheidet oft darüber, ob Testen wirklich etwas findet oder nur den Anschein einer Prüfung erzeugt.

Formell sind in der Testphase Testerinnen und Tester, QA-Engineers, manchmal spezialisierte Sicherheits- oder Performanceexperten sowie Product Owner für die Abnahme beteiligt. Informell entscheidet etwas anderes: Darf ein Tester einen kritischen Fund eskalieren, auch wenn das Release verzögert wird? Wird ein Fehler als „nicht reproduzierbar" abgehakt, weil niemand Zeit hat, ihn tiefer zu verfolgen? Wessen Einschätzung darüber, was „akzeptabel" ist, hat im Zweifelsfall mehr Gewicht - die des Testers oder die der Projektleitung?

Diese Fragen klingen politisch. Sie sind es auch. Und sie bestimmen die tatsächliche Qualität des Testprozesses mehr als jede Testtool-Auswahl.

Besonders kritisch ist das Verhältnis zwischen Entwicklung und Test, wenn diese Gruppen als getrennte, in gewissem Sinne gegnerische Einheiten verstanden werden. Die Entwicklung baut, das Testen findet Fehler, Entwicklung muss sie beheben. Dieses Modell erzeugt eine Dynamik, in der Tester als Bremser gelten und Entwickler Testergebnisse als Kritik empfangen. Die Folge: Findings werden minimiert, Diskussionen über Schweregrade werden zur Verhandlungssache und die eigentliche Frage, ob das System für seine Nutzer funktioniert, geht im Ping-Pong verloren.

Typische Reibungspunkte in dieser Phase:

• Testen ohne Akzeptanzkriterien: Wenn die Analyse keine klaren Akzeptanzkriterien geliefert hat, improvisieren Tester. Sie testen, was sie für relevant halten aber nicht unbedingt das, was der Fachbereich erwartet. Das Ergebnis ist ein System, das technisch getestet und fachlich überraschend ist.

• Reproduzierbare Befunde, die nicht reproduziert werden wollen: Ein Fehler, der kurz vor dem Releasetermin auftaucht, steht unter dem Druck des Zeitplans. Die Versuchung ist groß, ihn als Sonderfall abzutun, wenn er sich nicht sofort reproduzieren lässt. Fehler, die nicht eingestanden werden, verschwinden nicht. Sie tauchen später unter schlechteren Bedingungen wieder auf.

• Testabdeckung als Kennzahl ohne Aussagekraft: 80 % Testabdeckung klingt gut. Sie sagt aber nichts darüber aus, ob die richtigen 80 % getestet wurden. Teams, die Coverage-Ziele verfolgen, ohne zu reflektieren, was die Tests tatsächlich prüfen, kaufen sich Sicherheitsgefühl ohne Sicherheit.

• Regressionstests als Nachgedanke: Wenn neue Features gebaut werden, werden alte oft nicht mitgeprüft. Was gestern funktioniert hat, muss nach einer Änderung nicht mehr funktionieren. Wer das systematisch ignoriert, baut technische Schulden nicht nur im Code auf, sondern auch im Testprozess.

Die wirksamste Gegenmaßnahme ist keine Tool-Entscheidung, sondern eine kulturelle. Testen ist kein Misstrauensbeweis gegenüber der Entwicklung, sondern gemeinsame Verantwortung für ein System, das Menschen nutzen werden. Wer diese Haltung lebt, baut keine Mauer zwischen Entwicklung und QA, sondern einen Dialog.

Woran du erkennst, ob es läuft

Gutes Testen erkennt man nicht daran, dass viele Testfälle durchlaufen werden. Man erkennt es daran, dass gefundene Fehler echte Funde sind, keine Trivialitäten. Man erkennt es daran, dass die Testergebnisse eine ehrliche Aussage über den Systemzustand erlauben, keine Abzeichnung. Und man erkennt es daran, dass nach dem Go-live nicht die Nutzer die Tester ersetzen.

Schlechtes Testen erkennt man an seinen Symptomen. An den Fehlern, die in der ersten Produktionswoche auftauchen; an den Grenzfällen, die im Tagesgeschäft erscheinen, weil sie im Test nie in Betracht gezogen wurden und an den nicht-funktionalen Problemen, die sich unter echter Last erst zeigen.

Messbar wird Qualität beim Testen dort, wo es nicht nur ausgeführt, sondern reflektiert wird:

• Rückverfolgbar: Jeder Testfall lässt sich auf eine konkrete Anforderung oder ein Akzeptanzkriterium zurückführen. Was nicht anforderbar war, ist auch nicht testbar.

• Reproduzierbar: Ein gefundener Fehler kann zuverlässig reproduziert werden. Was nicht reproduzierbar ist, ist nicht bearbeitbar.

• Dokumentiert: Testergebnisse sind lesbar und eindeutig. Nicht nur das Ergebnis, also bestanden oder fehlgeschlagen, sondern das Warum und unter welchen Bedingungen.

• Risikogewichtet: Nicht jeder Testfall ist gleich wichtig. Kritische Pfade, sicherheitsrelevante Bereiche und häufig genutzte Funktionen erhalten mehr Tiefe als seltene Sonderfälle.

• Unabhängig: Das Testen kann von der Entwicklung unabhängig durchgeführt werden. Eine Testumgebung, die immer erst vom Entwicklungsteam vorbereitet werden muss, ist keine Testumgebung, sondern ein Engpass.

Die weichen Warnsignale sind hier besonders aufschlussreich. Wenn Tester sagen, sie wissen nicht, was als „korrekt" gilt, fehlen Akzeptanzkriterien. Wenn Bugs aus dem Test regelmäßig als „kein Bug, sondern Feature" zurückkommen, fehlt ein gemeinsames Verständnis von Qualität. Und wenn die Testphase in jedem Projekt kürzer wird, weil Entwicklung länger dauert, ist das kein Zeitproblem, sondern ein Planungsproblem, das beim Testen sichtbar wird aber woanders entschieden wurde.

Die Übergabe in die Bereitstellungsphase ist der nächste Belastungstest. Was diese Phase konkret liefern sollte:

Entscheidungen, die morgen noch gelten

Das Besondere an Entscheidungen in der Testphase ist, dass viele von ihnen eigentlich schon früher hätten getroffen werden müssen. Wie testbar ist die Architektur? Gibt es klare Akzeptanzkriterien? Sind Tests Bestandteil der Definition of Done? Diese Fragen sind im Grunde Planungs-, Analyse- und Designfragen, die in der Testphase nur sichtbar werden.

Was die Testphase selbst entscheidet, ist trotzdem nicht trivial. Die wichtigste Frage lautet: Was ist gut genug? Diese Frage klingt nach Kompromiss. Sie ist aber die ehrlichste Frage, die man stellen kann. Kein System wird jemals vollständig getestet sein. Jede Entscheidung zur Freigabe ist eine Risikoabwägung. Wer das nicht ausspricht, tut es trotzdem, nur ohne dass alle Beteiligten es wissen.

Nachhaltige Testarbeit bedeutet nicht, alles zu testen. Das wäre nicht nur unmöglich, sondern aktiv kontraproduktiv, weil es Ressourcen dort bindet, wo der Gewinn gering ist. Nachhaltige Testarbeit bedeutet, die richtigen Dinge mit der richtigen Tiefe zu testen und die Entscheidungen darüber transparent zu machen.

• Risikoorientiertes Testen statt Vollständigkeit: Nicht jeder Bereich des Systems hat das gleiche Fehlerpotenzial. Wer Testaufwand nach Risiko verteilt, erzielt mehr Sicherheit mit demselben Budget als wer flächendeckend aber seicht testet.

• Testergebnisse als Systeminformation, nicht als Urteil: Ein Fehler ist kein Versagen der Entwicklung. Er ist eine Information über das System. Teams, die diese Haltung leben, nutzen Testergebnisse als Lernquelle, nicht als Anlass für Schuldzuweisungen.

• Automatisierung dort, wo sie trägt: Automatisierte Tests sind kein Selbstzweck. Regressionstests, Smoke Tests und Integrationstests lassen sich oft gut automatisieren und geben dem Team schnelles Feedback. Explorative Tests, die Unbekanntes aufdecken sollen, brauchen menschliche Neugier. Beides hat seinen Platz.

• Freigabe als explizite Entscheidung: Das Ende der Testphase ist kein technisches Ereignis, sondern eine bewusste Entscheidung. Wer freigibt, akzeptiert die bekannten Risiken und trägt dafür Verantwortung. Diese Verantwortung sollte klar bei einer Person oder Gruppe liegen, nicht in einer Reihe konkludenter Schweigen verteilt sein.

Das häufigste nachhaltige Problem der Testphase ist nicht der übersehene Fehler, so schmerzhaft der im Einzelfall auch sein mag. Es ist die schleichende Normalisierung von Abkürzungen. Tests, die nicht mehr aktualisiert werden, wenn sich Anforderungen ändern. Fehlermeldungen, die als Warnungen klassifiziert werden, damit sie das Release nicht blockieren. Testphasen, die auf dem Papier stehen und in der Realität nie die Zeit bekommen, die sie bräuchten. Jedes dieser Details ist für sich erklärbar. In Summe beschreiben sie einen Prozess, dem niemand mehr wirklich vertraut.

Am Ende der Testphase lohnt sich deshalb eine ehrliche Rückfrage:

Wenn wir morgen einen Fehler in der Produktion finden, der im Test hätte auffallen müssen: Was hätte uns daran gehindert, ihn zu finden?

Wenn die Antwort einfach ist, war die Testphase wahrscheinlich nicht fertig.

Weiterdenken

Testen ist die Phase im SDLC, in der Vertrauen zu Evidenz wird. Alles, was vorher entstanden ist, wird hier auf Wirklichkeit geprüft: Annahmen aus der Analyse, Entscheidungen aus dem Design, Implementierungsentscheidungen aus der Entwicklung. Wer diese Phase als notwendigen Abschluss behandelt, verschenkt ihr eigentliches Potenzial. Die Möglichkeit, durch systematisches Hinterfragen ein System an die Oberfläche zu bringen, das nicht nur gebaut wurde, sondern auch wirklich funktioniert.

Das Interessanteste an der Testphase ist nicht die Frage, welche Tools das Team einsetzt oder wie viel Testabdeckung erreicht wird. Es ist die Frage, welche Haltung das Team gegenüber Fehlern hat. Wer Fehler als Zeichen für Schwäche behandelt, findet weniger. Wer Fehler als Information behandelt, findet mehr und baut damit zuverlässigere Software.

Nimm dir etwas Zeit und reflektiere die folgenden Fragen:

• Wann wurde in eurem letzten Projekt die Testphase verkürzt, weil die Entwicklung länger gedauert hat als geplant? Was hat das konkret bedeutet?

• Gibt es in eurem Team klare Akzeptanzkriterien, die die Tests leiten oder entscheiden Tester selbst, was „gut genug" bedeutet?

• Wie viele eurer automatisierten Tests prüfen tatsächlich das Verhalten des Systems und wie viele prüfen nur, dass der Code so läuft wie er geschrieben wurde?

• Wer trifft in eurem Team die Entscheidung zur Freigabe und auf welcher Grundlage?

Die nächste Phase, die Bereitstellung, baut direkt auf dem auf, was der Test geliefert hat. Dort wird getestete Software nutzbar für die Anwender. Wie reibungslos und sicher dieser Übergang gelingt, hängt unmittelbar davon ab, wie vollständig und ehrlich die Testphase war. Was im Test unklar bleibt, klärt sich spätestens dort unter deutlich ungünstigeren Bedingungen.