Zum Inhalt springen

Suchen...

Die sich verändernde Rolle von Software-Testern

Softwarequalität ist nicht mehr nur die Aufgabe eines Testers. Hier erfährst du, warum sich die Rolle, die Werkzeuge und die Denkweise dahinter schnell ändern.

9 Min. Lesezeit
Cover für Die sich verändernde Rolle von Software-Testern

Softwarequalität als Haltung bedeutet, dass jede Person in einem Softwareteam, nicht nur Tester, während des gesamten Entwicklungsprozesses aktiv Verantwortung für die Qualität übernimmt. Dazu gehören Testmethoden, Testautomatisierung, KI-getriebene Entwicklung, nicht-funktionale Anforderungen wie IT-Sicherheit und Gebrauchstauglichkeit sowie die Einstellung des Teams. Keine einzelne Rolle ist für die Qualität verantwortlich; sie wird von Anfang an eingebaut und nicht erst am Ende überprüft.

Das Wichtigste in Kürze

  • Wenn ein ganzes agiles Team ohne weitere Maßnahmen kollektiv für die Qualität verantwortlich gemacht wird, hat das zur Folge, dass niemand wirklich verantwortlich ist.
  • Die Rolle des Testers hat sich von einem separaten Spezialisten am Ende eines Wasserfallprozesses zu einem in das Team eingebetteten Qualitätscoach gewandelt, und diese Entwicklung ist in vielen Unternehmen noch nicht abgeschlossen.
  • KI demokratisiert die Softwareerstellung, so dass auch Nicht-Entwickler/innen Anwendungen erstellen können, was dazu führt, dass immer mehr ungetestete oder schlecht getestete Software in die Produktion gelangt.
  • Das Testen von KI-Systemen kann sich nicht auf klassische deterministische Testfälle stützen, da dieselbe Eingabe jedes Mal eine andere Ausgabe erzeugt. Stattdessen sind statistische oder nicht-deterministische Ansätze erforderlich.
  • Nicht-funktionale Anforderungen wie IT-Sicherheit und Gebrauchstauglichkeit müssen während des gesamten Projekts berücksichtigt werden, nicht erst am Ende, da späte Architekturänderungen unverhältnismäßig teuer sind.

Warum Software Qualität jetzt ein neues Denken braucht

Die Qualität von Software ist wichtiger denn je, und die Bedingungen, unter denen sie geliefert wird, ändern sich ständig unter den Verantwortlichen. Software durchzieht die Produktionssysteme, das tägliche Leben und die Gesellschaft im Allgemeinen, und schlechte Qualität hat reale Konsequenzen. Gleichzeitig verändern drei Kräfte die Spielregeln: KI, die die Art und Weise, wie Software entwickelt wird, neu gestaltet, DevOps und agile Veränderungen und der Druck, schneller zu liefern.

Die Schwierigkeit besteht nicht nur darin, Qualität zu liefern. Es geht darum zu entscheiden, wie viel Qualität für ein bestimmtes Produkt ausreichend ist. Dieser Kompromiss steht im Mittelpunkt der Arbeit und wird nicht einfacher, wenn sich die Veröffentlichungszyklen verkürzen.

Richard Seidl umrahmt das ganze Thema mit einer einzigen Aussage: Qualität als Haltung. Der Begriff stammt aus den Anfängen der agilen Bewegung vor etwa 25 Jahren, als Teams zu argumentieren begannen, dass sich Qualität nicht auf Testmethoden am Ende der Linie beschränken darf. Qualität muss über den gesamten Softwareentwicklungsprozess hinweg betrachtet werden.

Die Rolle des Testers verändert sich

Die Rolle des Testers hat sich nie festgelegt und wird sich wohl auch jetzt nicht festlegen. In den letzten 20 bis 25 Jahren hat sie sich immer wieder verschoben, und die KI-Welle treibt sie erneut an.

In der Anfangszeit war der Entwickler oft der Tester. In der schlimmsten Variante wurde der Entwickler mit den schwächsten Fähigkeiten mit dem Testen betraut. Es gab keine echten Methoden oder Strategien, um die Qualität zu prüfen, zu messen oder zu beweisen.

Das änderte sich mit der Standardisierung, neuen Methoden und dem Streben nach professioneller Praxis. Die zum Teil alten Testmethoden wurden zur Grundlage für die Festlegung einer Teststrategie und eines Testkonzepts. Zertifizierung und Schulung verschafften den Testern mehr Ansehen innerhalb ihrer Teams.

Die Unternehmen bauten spezielle Strukturen auf: Testabteilungen, Testzentren und Testfabriken, die das Testen als Dienstleistung in die Projekte einbrachten. Bei der Wasserfallmethode kümmerte sich ein separates Test-Team um alles, was am Ende anstand. Der Tester saß auf der einen Seite, der Entwickler auf der anderen.

Mit Agile wurden die beiden Rollen wieder zusammengeführt. Der Tester wurde mehr zu einem Qualitätscoach im Team, der den Entwicklern hilft, bessere Unit- und Integrationstests zu schreiben und den Qualitätsgedanken dort zu verankern, wo der Code geschrieben wird. Die Beziehung schwingt wie ein Pendel, von einem separaten Tester zu einem in das Team eingebetteten Qualitätsingenieur.

Diese Verschiebung bringt einen Kompromiss in Bezug auf das Fachwissen mit sich. Ein spezialisierter Tester kann sehr tief in die Testmethoden einsteigen. Ein Qualitätsingenieur, der das gesamte Spektrum abdeckt, braucht stattdessen ein breites Wissen, und diese Breite geht in der Regel auf Kosten der Tiefe der reinen Testmethoden.

Es gibt keine einzig richtige Version der Rolle. Sie hängt von der Organisation, der Reife des Entwicklungsprozesses und den Mustern ab, für die sich ein Team entscheidet. Du musst dich immer wieder fragen, was ein Tester in deinem speziellen Umfeld tatsächlich tut, anstatt von einer festen Stellenbeschreibung auszugehen.

Testautomatisierung ist mit Agile nicht mehr verhandelbar

Die Testautomatisierung wurde von einer optionalen zu einer obligatorischen Anforderung, als die Teams anfingen, in Sprints zu arbeiten. Nach ein paar Iterationen sind manuelle Regressionstests nicht mehr möglich. Der Umfang der wiederholten Prüfungen übersteigt einfach das, was Menschen von Hand erledigen können.

Die Antwort darauf war eine Welle von Tools, insbesondere für die UI- und End-to-End-Ebene. Das löste ein Problem und eröffnete ein weiteres. Da die Automatisierung auf mehreren Ebenen möglich ist, müssen die Teams jetzt entscheiden, wo sie was testen wollen.

Das ist die Frage, die darüber entscheidet, ob sich die Automatisierung auszahlt:

TeststufeTypischer Schwerpunkt
Einheit und IntegrationLogik und Verhalten der Komponenten, schnelle Rückmeldung
SystemDie gesamte Anwendung
UI und End-to-EndBenutzerorientierte Abläufe
API und vertragsbasiertSchnittstellen zwischen Diensten

Die Entscheidung über die Platzierung gehört ins Team. Allzu oft findet dieses Gespräch nicht statt, weil die Tester auf ihrer Seite und die Entwickler auf ihrer Seite arbeiten. Die Verbesserung des Austauschs zwischen diesen Rollen ist einer der Hebel, um die Automatisierung richtig zu machen.

Die Automatisierung geht auch über die Testdurchführung hinaus. Pipelines, Prozesse und die Erzeugung von Testdaten sind allesamt Kandidaten für die Automatisierung der täglichen Arbeit eines Testers. Der Umfang dessen, was automatisiert werden kann, ist größer als die Testskripte allein.

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

KI wird das Testen in naher Zukunft nicht übernehmen, denn beim Testen geht es im Wesentlichen um Vertrauen. Eine KI, die Ergebnisse liefert, schafft allein nicht das Vertrauen, das die Beteiligten brauchen.

KI-Agenten, die eigenständig Aufgaben übernehmen und auch Teile eines Systems testen, sind jedoch auf dem Vormarsch. Die realistische Erwartung ist Unterstützung, nicht Ersatz. KI kann dabei helfen, bessere Testfälle zu generieren und Teile der Testautomatisierung zu übernehmen, so dass sich die Tester auf die Randfälle und die Beurteilung konzentrieren können.

Testen ist dazu da, Informationen über ein 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. Wenn eine KI diese gesamte Kette steuern würde, wäre das Vertrauen, das diese Tätigkeit erzeugen soll, dahin. Behalte die menschliche Rolle, von der das Vertrauen kommen muss.

Das Testen von KI-Systemen bricht das deterministische Spielbuch

Das Testen eines KI-Systems ist nicht dasselbe wie das Testen klassischer Software, und das alte Testfall-Modell lässt sich nicht übertragen. Bei einem klassischen Test gibst du eine Eingabe ein und vergleichst sie mit einem erwarteten Ergebnis. Wenn du ein KI-System mit derselben Eingabe fütterst, kann es sein, dass du jedes Mal ein anderes Ergebnis erhältst.

Diese Unbestimmtheit zwingt zu einer anderen Frage: Was genau testest du? Das Modell, das Training, die Schnittstellen oder bestimmte Qualitätsmerkmale. Jedes Ziel braucht seinen eigenen Ansatz.

Deterministische Pass-Fail-Prüfungen weichen statistischen und massenbasierten Methoden. Neue Testverfahren zum Testen von KI-Systemen werden gerade entwickelt, und für viele Menschen in Softwareprojekten ist dieser Bereich noch ein weißer Fleck. Betrachte es als eine Fähigkeit, die du bewusst aufbauen musst, und nicht als etwas, das du aus vorhandenem Test-Wissen improvisieren kannst.

KI demokratisiert die Software-Entwicklung

KI öffnet die Softwareentwicklung für Menschen, die keine Softwareentwickler sind. Jahrzehntelang war die Entwicklung von Software eine Festung, die nur Entwicklerinnen und Entwickler betreten durften, und sie haben ihre Arbeit gut gemacht. Diese Barriere fällt jetzt.

Mit Ansätzen, die manchmal als Vibe Coding oder KI-gesteuerte Programmierung bezeichnet werden, kann fast jeder eine App, eine Website oder eine Anwendung erstellen. Die Bandbreite reicht von der Nutzung von KI als Hilfsmittel bis hin zur Erstellung einer ganzen Anwendung. Wir befinden uns noch im Anfangsstadium, und die Menge der auf diese Weise produzierten Software wird weiter wachsen.

Die offene Frage ist, wer beurteilt, ob diese Software gut ist. Ein großer Teil der neuen Software kommt von Leuten, die nicht aus der Entwicklerbranche kommen. Die Qualität kann solide sein, aber sie kann auch Fallstricke und IT-Sicherheitslücken verbergen. Irgendjemand muss sie testen.

Das stellt die Test-Teams vor praktische Entscheidungen. Wie unterstützt du deine Test-Frameworks mit KI? Ersetzt du einige Tests durch KI-gesteuerte Tests oder lenkst du den menschlichen Aufwand auf Randfälle um? Darauf gibt es noch keine eindeutige Antwort, weil alle noch lernen, wie man mit der Technologie arbeitet.

Qualität ist Sache des Teams oder von niemandem

Einem agilen Team zu sagen, dass jeder für die Qualität verantwortlich ist, bedeutet in der Regel, dass es niemand ist. Gemeinsame Verantwortung funktioniert nur, wenn die Einstellung aktiv eingebaut wird und nicht nur einmal erklärt und dann allein gelassen wird.

Oft sind es die Qualitätsbeauftragten, die diese Veränderung vorantreiben. Sie bringen den UX-Designer, den Business-Analysten, den Entwickler und jemanden aus dem Betrieb in eine Arbeitsweise ein, bei der jede Rolle einen echten Anteil an der Qualitätssicherung und der eingebaute Qualität hat. Qualität ist nicht länger die Aufgabe des Testers.

Viele Teams und Projekte tun sich immer noch schwer mit dieser Umstellung, zum Teil weil die Umstellung selbst schlecht gehandhabt wird. Ein Tester, der den gesamten Entwicklungsprozess versteht und die Verbindungsfähigkeit zwischen den einzelnen Rollen herstellen kann, hat echten Einfluss darauf, dass er besser funktioniert.

Nicht-funktionale Anforderungen müssen sich durch das ganze Projekt ziehen

IT-Sicherheit, Gebrauchstauglichkeit und ähnliche nichtfunktionale Belange können nicht mehr am Ende des Projekts angehängt werden. In Europa zwingen die Vorschriften die Teams dazu, sich im Vorfeld und während des gesamten Projekts mit diesen Fragen zu befassen, anstatt sie nur in einem einzigen Test oder einem späten Review zu prüfen.

Der Grund dafür sind die Kosten. Eine späte Änderung der Architektur, um eine Lücke in der IT-Sicherheit oder Gebrauchstauglichkeit zu schließen, ist teuer. Eine frühzeitige Entscheidung für IT-Sicherheit und Gebrauchstauglichkeit vermeidet diese kostspieligen Nachbesserungen.

Das bedeutet zusätzliche Arbeit an einem ohnehin schon vollen Tag, die das ganze Team belastet. Entwickler, Architekten, Tester und Automatisierungsingenieure müssen diese Aspekte bei ihrer Arbeit berücksichtigen. Die Herausforderung besteht darin, sie in die bestehenden Arbeitsabläufe einzubauen und nicht nur anzuerkennen, dass sie wichtig sind.

Persönliche Entwicklung ist das, was dich beschäftigungsfähig hält

In einem zunehmend KI-gesteuerten Umfeld entscheiden die Fähigkeiten, die Denkweise und die Werkzeuge, die du kultivierst, darüber, ob du relevant bleibst. Es kommt weniger darauf an, welches Werkzeug du benutzt, als darauf, dass du die Werte, Methoden und Strategien hast, um jedes Werkzeug anzuwenden.

Das gilt nicht nur für Tester. Qualitätsbewusste Entwickler/innen, UX-Expert/innen, Business-Analyst/innen und Projektmanager/innen stehen alle vor der gleichen Frage: Welche Fähigkeiten brauche ich, welche Denkweise und welche Tools kann ich einsetzen. Behandle diese Frage als ständige Aufgabe, nicht als einmalige Entscheidung.

Qualität als Einstellung klingt einfach, ist es aber nicht. Es ist wirklich schwer, Qualität mit Zeitdruck und schnellen Veröffentlichungszyklen in Einklang zu bringen. Der Weg dorthin besteht darin, alte Überzeugungen immer wieder zu hinterfragen, neue Stärken aufzubauen und bewusst zu entscheiden, wohin deine Rolle gehen soll.

Diese Seite teilen