Tester-Rolle: vom Spezialisten zum Qualitätscoach

Bei Softwarequalität als Haltung übernehmen alle im Softwareteam, nicht nur die Tester, über den gesamten Entwicklungsprozess aktiv Verantwortung für Qualität. Das betrifft Testmethoden, Testautomatisierung, KI-gestützte Entwicklung, nicht-funktionale Anforderungen wie Security und Usability und die Einstellung des Teams. Keine einzelne Rolle besitzt die Qualität. Sie wird von Anfang an eingebaut und nicht erst am Ende geprüft.

Das Wichtigste in Kürze

• Wird ein ganzes agiles Team ohne weitere Schritte gemeinsam für Qualität verantwortlich erklärt, ist am Ende niemand verantwortlich.
• Die Rolle des Testers hat sich vom getrennten Spezialisten am Ende des Wasserfalls zum Qualitätscoach im Team entwickelt, und in vielen Organisationen ist dieser Wandel noch nicht abgeschlossen.
• KI öffnet die Softwareentwicklung auch für Menschen, die keine Entwickler sind. Dadurch landet mehr ungetestete oder schlecht getestete Software in Produktion.
• Beim Testen von KI-Systemen tragen klassische deterministische Testfälle nicht, weil dieselbe Eingabe jedes Mal ein anderes Ergebnis liefern kann. Gefragt sind statistische Verfahren.
• Nicht-funktionale Anforderungen wie Security und Usability gehören ins ganze Projekt und nicht ans Ende, weil späte Architekturänderungen unverhältnismäßig teuer werden.

Warum Softwarequalität gerade ein neues Denken braucht

Qualität in der Software war nie wichtiger, und die Bedingungen, unter denen Teams sie liefern sollen, verschieben sich laufend. Software steckt in Produktionssystemen, im Alltag und in der Gesellschaft, schlechte Qualität hat echte Folgen. Gleichzeitig ändern drei Kräfte die Spielregeln: KI verändert, wie Software entsteht, DevOps- und agile Transformationen laufen weiter, und der Druck, schneller zu liefern, wächst. Mittendrin wandelt sich die Tester-Rolle, vom Spezialisten zum Qualitätscoach.

Schwierig ist nicht nur, Qualität zu liefern. Schwierig ist die Entscheidung, wie viel Qualität für ein bestimmtes Produkt reicht. Diese Abwägung steht im Zentrum der Arbeit, und mit kürzeren Release-Zyklen wird sie nicht leichter.

Richard Seidl stellt das ganze Thema unter einen Satz: Qualität als Haltung. Der Gedanke stammt aus den frühen Tagen der agilen Bewegung vor rund 25 Jahren. Damals begannen Teams zu argumentieren, dass Qualität nicht auf Testmethoden am Ende des Prozesses beschränkt bleiben darf. Qualität gehört in den gesamten Entwicklungsprozess.

Die Tester-Rolle ist ständig in Bewegung

Die Rolle des Testers war nie festgeschrieben, und das wird sie wohl auch jetzt nicht. In den vergangenen 20 bis 25 Jahren hat sie sich immer wieder verschoben, und die KI-Welle bewegt sie erneut.

Anfangs war der Entwickler oft auch der Tester. Im schlimmsten Fall bekam der schwächste Entwickler das Testen aufgebrummt. Echte Methoden oder Strategien, um Qualität zu prüfen, zu messen oder nachzuweisen, gab es nicht.

Das änderte sich mit Standardisierung, neuen Methoden und dem Anspruch, professionell zu arbeiten. Testmethoden, manche davon inzwischen alt, wurden zur Grundlage für Teststrategie und Testkonzept. Zertifizierungen und Schulungen gaben Testern mehr Gewicht im Team.

Dann bauten Unternehmen eigene Strukturen auf: Testabteilungen, Testcenter, Testfabriken, die das Testen als Dienstleistung in Projekte lieferten. Im Wasserfall übernahm ein separates Testteam am Ende alles. Der Tester saß auf der einen Seite, der Entwickler auf der anderen.

Mit Agilität rückten beide Rollen wieder zusammen. Der Tester wurde eher zum Qualitätscoach im Team: Er hilft Entwicklern, bessere Unit- und Integrationstests zu schreiben, und bringt das Denken in Qualität dorthin, wo der Code entsteht. Das Verhältnis schwingt wie ein Pendel, vom abgetrennten Tester zum Quality Engineer mitten im Team.

Dieser Wechsel kostet etwas Fachtiefe. Ein spezialisierter Tester kann bei Testmethoden sehr tief gehen. Ein Quality Engineer, der das Gesamtbild im Blick hat, braucht dagegen breites Wissen, und diese Breite geht meist auf Kosten der Tiefe bei reinen Testmethoden.

Die eine richtige Form der Rolle gibt es nicht. Sie hängt von der Organisation ab, von der Reife des Entwicklungsprozesses und von den Mustern, denen ein Team folgt. Frag deshalb immer wieder, was ein Tester in deinem Umfeld tatsächlich tut, statt von einer festen Stellenbeschreibung auszugehen.

Mit Agilität wurde Testautomatisierung Pflicht

Sobald Teams in Sprints arbeiten, ist Testautomatisierung keine Option mehr. Nach ein paar Iterationen lässt sich der manuelle Regressionstest nicht mehr stemmen. Die Menge an wiederholten Prüfungen übersteigt schlicht, was Menschen von Hand schaffen.

Die Antwort war eine Welle an Werkzeugen, vor allem für UI- und End-to-End-Tests. Das löste ein Problem und schuf ein neues: Wenn sich auf mehreren Ebenen automatisieren lässt, muss das Team entscheiden, was es wo testet.

An dieser Frage hängt, ob sich Automatisierung lohnt:

Diese Entscheidung gehört ins Team. Allzu oft findet das Gespräch gar nicht statt, weil Tester auf ihrer Seite arbeiten und Entwickler auf ihrer. Einen besseren Austausch zwischen diesen Rollen herzustellen, ist einer der Hebel, damit Automatisierung gelingt.

Automatisierung reicht außerdem über die Testausführung hinaus. Pipelines, Prozesse und die Erzeugung von Testdaten lassen sich im Testeralltag ebenfalls automatisieren. Das Feld ist größer als die Testskripte allein.

KI-Agenten sind der nächste Wandel, nicht das Ende des Testens

KI wird das Testen in naher Zukunft nicht übernehmen, denn Testen ist im Kern ein Geschäft mit Vertrauen. Wenn eine KI Ergebnisse zurückliefert, entsteht dadurch allein nicht das Vertrauen, das die Stakeholder brauchen.

Trotzdem kommen KI-Agenten, die Aufgaben selbstständig erledigen, auch das Testen von Teilen eines Systems. Realistisch ist Unterstützung, kein Ersatz. KI kann helfen, bessere Testfälle zu erzeugen, und Teile der Testautomatisierung übernehmen. Tester gewinnen so Zeit für Randfälle und für das eigene Urteil.

Testen soll Informationen über ein Testobjekt sammeln und den Stakeholdern ein belastbares Bild der Qualität geben, damit sie entscheiden können, ob die Software gut genug ist. Liefe diese ganze Kette über eine KI, wäre das Vertrauen weg, das die Tätigkeit überhaupt erzeugen soll. Lass die menschliche Rolle dort, wo das Vertrauen herkommen muss.

KI-Systeme testen sprengt das deterministische Testmodell

Ein KI-System zu testen ist etwas anderes, als klassische Software zu testen, und das alte Testfallmodell lässt sich nicht einfach übertragen. Im klassischen Test gibst du eine Eingabe vor und vergleichst das Ergebnis mit dem erwarteten. Ein KI-System kann bei derselben Eingabe jedes Mal etwas anderes liefern.

Dieser Nichtdeterminismus wirft eine andere Frage auf: Was genau testest du? Das Modell, das Training, die Schnittstellen oder bestimmte Qualitätsmerkmale? Jedes Ziel braucht einen eigenen Ansatz.

Deterministische Pass-Fail-Prüfungen weichen statistischen und massenbasierten Verfahren. Neue Techniken zum Testen von KI-Systemen entstehen gerade erst, und für viele in Softwareprojekten ist das Feld noch ein weißer Fleck. Behandle es als Fähigkeit, die du bewusst aufbaust, und nicht als etwas, das sich aus vorhandenem Testwissen improvisieren lässt.

KI öffnet die Softwareentwicklung für alle

KI macht Softwareentwicklung auch für Menschen zugänglich, die keine Entwickler sind. Jahrzehntelang war Software bauen eine Festung, in die nur Entwickler hineinkamen, und die haben ihren Job gut gemacht. Diese Hürde fällt gerade.

Ansätze, die mal Vibe Coding, mal KI-gestützte Programmierung heißen, lassen fast jeden eine App, eine Website oder eine Anwendung bauen. Die Spanne reicht von KI als Hilfsmittel bis zur komplett generierten Anwendung. Wir stehen am Anfang, und die Menge an Software, die so entsteht, wird weiter wachsen.

Offen ist, wer beurteilt, ob diese Software gut ist. Viel neue Software kommt von Menschen außerhalb des Entwicklerberufs. Die Qualität kann solide sein, sie kann aber auch Fallstricke und Sicherheitslücken verbergen. Testen muss sie jemand.

Für Testteams folgen daraus praktische Entscheidungen. Wie unterstützt du deine Test-Frameworks mit KI? Ersetzt du manche Tests durch KI-gestützte Tests, oder lenkst du die menschliche Arbeit auf Randfälle? Eine feste Antwort gibt es noch nicht, weil alle gerade erst lernen, mit der Technologie zu arbeiten.

Qualität gehört dem Team, oder niemandem

Sagt man einem agilen Team, alle seien für Qualität verantwortlich, ist es meistens niemand. Geteilte Verantwortung funktioniert nur, wenn die Haltung aktiv verankert wird, statt einmal ausgerufen und dann sich selbst überlassen.

Oft sind es die Qualitätsleute, die diesen Wandel antreiben. Sie holen UX-Designer, Business-Analystin, Entwickler und jemanden aus dem Betrieb in eine Arbeitsweise, in der jede Rolle einen echten Teil der Qualitätssicherung und der eingebauten Qualität trägt. Qualität ist dann nicht mehr die Privatsache des Testers.

Viele Teams und Projekte tun sich mit diesem Wandel schwer, auch weil die Transformation selbst schlecht gemacht ist. Ein Tester, der den gesamten Engineering-Prozess versteht und die Rollen miteinander verbinden kann, hat echten Einfluss darauf, dass es besser läuft.

Nicht-funktionale Anforderungen gehören ins ganze Projekt

Security, Usability und ähnliche nicht-funktionale Themen lassen sich nicht mehr am Ende anflanschen. In Europa drängt die Regulierung Teams dazu, sie von Beginn an und durchgehend anzugehen, statt mit einem einzelnen Penetrationstest oder einem späten Review.

Der Grund sind die Kosten. Wer spät im Projekt die Architektur ändern muss, um eine Security- oder Usability-Lücke zu schließen, zahlt viel. Security by Design und Usability by Design, früh entschieden, ersparen diese teure Nacharbeit.

Das bringt zusätzliche Arbeit in einen ohnehin vollen Alltag, und sie trifft das ganze Team. Entwickler, Architektin, Tester und Testautomatisierer müssen diese Themen in ihre Arbeit einbeziehen. Die Herausforderung ist, das in die bestehende Last einzubauen, nicht nur anzuerkennen, dass es wichtig ist.

Wer sich weiterentwickelt, bleibt gefragt

In einem Umfeld, das immer stärker von KI geprägt ist, entscheiden deine Fähigkeiten, deine Haltung und deine Werkzeuge darüber, ob du relevant bleibst. Welches Tool du konkret nutzt, zählt weniger als die Werte, Methoden und Strategien, mit denen du jedes Tool einsetzen kannst.

Das gilt nicht nur für Tester. Qualitätsbewusste Entwickler, UX-Fachleute, Business-Analysten und Projektleiter stehen vor derselben Frage: Welche Fähigkeiten brauche ich, welche Haltung, welche Werkzeuge? Diese Frage stellt sich immer wieder, nicht nur einmal.

Qualität als Haltung klingt einfach und ist es nicht. In Qualität zu denken und sie gleichzeitig gegen Zeitdruck und schnelle Release-Zyklen abzuwägen, ist wirklich schwer. Der Weg dahin: alte Überzeugungen immer wieder hinterfragen, neue Stärken aufbauen und bewusst entscheiden, wohin sich die eigene Rolle entwickeln soll.

Häufig gestellte Fragen

Wie entscheidest du, wie viel Qualität ein Produkt tatsächlich braucht?

Dieser Kompromiss ist der schwierigere Teil der Arbeit. Qualität zu liefern ist eine Sache; zu entscheiden, wie viel für ein bestimmtes Produkt ausreicht, steht im Mittelpunkt der Arbeit, und kürzere Release-Zyklen machen diese Entscheidung nicht einfacher. Drei Faktoren verändern ständig die Rahmenbedingungen: KI, die die Art und Weise verändert, wie Software entwickelt wird, die fortschreitende DevOps- und Agile-Transformation sowie der Druck, schneller zu veröffentlichen.

Worauf verzichtest du, wenn aus einem spezialisierten Tester ein eingebetteter Qualitätsingenieur wird?

Tiefgang bei den Testmethoden. Ein spezialisierter Tester kann hier sehr tief in die Materie einsteigen, während ein Qualitätsingenieur, der das Gesamtbild im Blick hat, breites Wissen benötigt und diese Breite meist mit einem gewissen Verlust an Tiefe erkauft. Keine der beiden Varianten ist die einzig richtige. Die passende Lösung hängt von der Organisation, der Reife des Entwicklungsprozesses und den Mustern ab, denen ein Team folgt.

Kann manuelles Regressionstesten mit der sprintbasierten Entwicklung Schritt halten?

Nein. Nach einigen Iterationen übersteigt das Volumen der wiederholten Prüfungen das, was Menschen von Hand bewältigen können. Deshalb ist Automatisierung kein optionales Extra mehr, sobald Teams in Sprints arbeiten. Der Umfang geht über Testskripte hinaus: Pipelines, Prozesse und die Generierung von Testdaten kommen ebenfalls in Frage. Die Entscheidung, die darüber entscheidet, ob sich Automatisierung lohnt, ist die Frage: Was wird wo getestet?

Wird KI das Softwaretesten übernehmen?

Nicht in naher Zukunft, denn Testen ist im Grunde eine Vertrauenssache. Sein Zweck ist es, Informationen von einem Testobjekt zu sammeln und den Beteiligten ein fundiertes Bild der Qualität zu vermitteln, damit sie entscheiden können, ob die Software gut genug ist. Ergebnisse, die von einer KI zurückgegeben werden, schaffen dieses Vertrauen nicht. Rechne stattdessen mit Unterstützung: generierte Testfälle, Teile der Automatisierung, Menschen bei Randfällen.

Warum funktionieren klassische Testfälle bei KI-Systemen nicht?

Da dieselbe Eingabe jedes Mal ein anderes Ergebnis liefern kann, lässt sich das Modell „Eingabe und erwartetes Ergebnis“ nicht übertragen. Der Nichtdeterminismus wirft eine grundlegende Frage auf: Testest du das Modell, das Training, die Schnittstellen oder bestimmte Qualitätsmerkmale? Jedes Ziel erfordert einen eigenen Ansatz, und deterministische Pass-Fail-Prüfungen weichen statistischen, massenbasierten Methoden. Betrachte dies als eine Fähigkeit, die du bewusst aufbauen musst.

Welche Risiken gehen damit einher, wenn Nicht-Entwickler Anwendungen mithilfe von KI erstellen?

Die Menge an ungetesteter oder nur unzureichend getesteter Software, die in die Produktion gelangt, wächst. Ansätze, die manchmal als „Vibe-Coding“ bezeichnet werden, ermöglichen es fast jedem, eine App oder eine Website zu erstellen. Das Ergebnis kann solide sein, aber es können auch Fallstricke und Sicherheitslücken darin verborgen sein. Jemand muss es trotzdem testen, und die offene Frage ist, wer beurteilt, ob diese Software gut ist.

Funktioniert geteilte Verantwortung für Qualität in einem agilen Team?

Nur, wenn diese Denkweise aktiv verankert wird. Zu erklären, dass jeder für die Qualität verantwortlich ist, bedeutet in der Regel, dass niemand verantwortlich ist. Es funktioniert, wenn jede Rolle einen konkreten Teil der Qualitätssicherung übernimmt: der UX-Designer, der Business-Analyst, der Entwickler, jemand aus dem Betrieb. Oft sind es die Verantwortlichen für die Qualität, die diesen Wandel vorantreiben, und viele Transformationen scheitern daran, dass die Transformation selbst schlecht gehandhabt wird.

Wann sollten Sicherheit und Gebrauchstauglichkeit in einem Projekt berücksichtigt werden?

Während des gesamten Projekts, nicht erst am Ende. Eine Sicherheits- oder Gebrauchstauglichkeitslücke erst spät zu beheben, bedeutet normalerweise, die Architektur zu ändern, was unverhältnismäßig teuer ist. „Security by Design“ und „Usability by Design“ vermeiden also diese Nacharbeit. In Europa treiben Vorschriften die Teams in dieselbe Richtung: weg von einem einzelnen Penetrationstest oder einer späten Review. Die Arbeit liegt gleichermaßen bei Entwicklern, Architekten, Testern und Testautomatisierungsentwicklern.