Die Vordenkerrolle im Softwaretest, oft Thought Leadership genannt, bedeutet, Prozesse aktiv zu gestalten, veraltete Praktiken zu hinterfragen und die Teamkultur zu prägen, statt nur zugewiesene Aufgaben abzuarbeiten. Dazu gehören eine strategische Kommunikation mit Stakeholdern, Coaching über offene Fragen und das Aufbrechen von Wissenssilos. Menschliches Urteil bleibt unverzichtbar, vor allem bei Barrierefreiheit und beim subjektiven Eindruck einer Software, den KI-Tools nicht nachbilden können.
Das Wichtigste in Kürze
- Abgeschottetes Wissen bremst die Lieferung: Halten Teammitglieder Informationen oder Prozesse zurück, wird das ganze Team langsamer, ganz gleich, wie viel Expertise die Einzelnen mitbringen.
- KI-Tools können das Schreiben von Testfällen übernehmen, aber Aussehen, Bedienung und emotionales Erleben muss weiterhin ein Mensch bewerten, gerade beim Testen der Barrierefreiheit, das von echten menschlichen Reaktionen lebt.
- Tester zu coachen heißt, ihnen offene Fragen zu stellen, was sie von ihrer Laufbahn wollen, statt sie auf einen vorgezeichneten Weg zu schicken, denn Karrieren verlaufen unterschiedlich.
- Entwickler, die ihren eigenen Code testen, sind genauso voreingenommen wie KI-Systeme, und Tester bringen ein Querdenken mit, das eine reine Entwicklerrolle nicht ersetzt.
Vordenkerrolle im Testen: Wer Code schreibt, ist Ingenieur
Testen ist Ingenieursarbeit, und wer testet, gehört als vollwertiges Mitglied ins Engineering-Team. Laveena Ramchandani bringt das mit dem Satz eines Direktors aus ihrem Unternehmen auf den Punkt: Wenn du Code schreibst, bist du Ingenieur. Damit ist die Messlatte gesetzt, wie Tester ihre Rolle sehen sollten: nicht als Servicefunktion, die an die Auslieferung angehängt wird, sondern als Teil der Produktentwicklung. Hier setzt die Vordenkerrolle im Testen an.
Von dort aus wächst der Job. Ein Tester im Entwicklungsteam stößt Veränderungen an, verändert Denkweisen und unterstützt die Leute um sich herum mit dem, was sie wirklich brauchen. Der Arbeitstag ist schnell voll, und genau deshalb bleiben die schwierigeren Fragen liegen.
Dabei sind es genau diese Fragen, auf die es ankommt. Funktionieren die Prozesse, die du übernommen hast, noch, oder laufen sie nur aus Gewohnheit weiter? Sagen deine KPIs den Stakeholdern etwas Brauchbares, oder gibt es sie einfach? Wer einen Schritt zurücktritt und so fragt, ist mitten in der Thought Leadership.
Thought Leadership im Softwaretest heißt, mit dem Team zu arbeiten
Ein Titel macht dich nicht zur Führungskraft. Einfluss schon, und Einfluss entsteht, wenn du mit Menschen arbeitest, statt sie aus der Ferne zu dirigieren.
Laveena packt lieber selbst mit an und testet an der Seite ihres Teams, statt von oben zu managen. Das ist eine praktische Entscheidung, keine sentimentale. Wenn eine Managerin mittestet, sieht das Team, wie die Arbeit wirklich gemacht wird, und das bringt mehr als die übliche Managerpose.
Das Ziel ist, alle im Team zu Vordenkern zu machen, statt das tiefere Wissen bei der Führungskraft zu bunkern. Ein häufiger Fehler: Der Manager übernimmt das gesamte strategische Denken, während die Tester in ihren Routineaufgaben versinken. Dieses Denken im Team zu verteilen, ist die eigentliche Führungsarbeit.
Vorleben, wenn Tester wachsen sollen
Das stärkste Lehrmittel ist Zeigen, nicht Erklären. Wenn Tester sehen, wie du mit einer schwierigen Situation umgehst, lernen sie aus dem Beispiel.
Laveena erzählt, wie Tester zu ihr kommen, nachdem sie ihr bei einer Aufgabe zugesehen haben, und fragen, was sie anders gemacht hat. Sie selbst hatten jahrelang dasselbe versucht, ohne Erfolg. Diese Reaktion zeigt, dass das Beispiel angekommen ist. Die Leute schauen zu und lernen daraus, wie du arbeitest.
Die stilleren Teammitglieder zu coachen, ist mühsame Arbeit, die sich auszahlt. Laveena hat erlebt, wie Leute, die sich kaum zu Wort gemeldet haben, mit der Zeit deutlich kommunikativer wurden. Den Unterschied siehst du, wenn du den Tag der Einstellung mit heute vergleichst.
Informationen zu bekommen, braucht Geduld, nicht nur Hartnäckigkeit
Tester sitzen oft mitten in einem Geflecht aus Wissen und müssen ständig Informationen von vielen Leuten einsammeln. Wer erwartet, dass das schnell und reibungslos geht, ist schnell frustriert.
Du wirst viele Leute anschreiben und nachhaken müssen, um an eine einzige Information zu kommen, und vielleicht bekommst du sie trotzdem nicht. Hast du die Hälfte erreicht, ist das schon ein Fortschritt. Von dort arbeitest du weiter.
Manche Stakeholder schlagen dir die Tür vor der Nase zu und sagen, sie hätten kein Interesse. Um diese Tür gibt es Wege herum. Biete ihnen eine Gelegenheit an und stell das Team in den Mittelpunkt, nicht dich. Achte auf deinen Gesprächsstil, denn dieselbe Bitte kommt ganz unterschiedlich an, je nachdem, wie du sie vorbringst.
Bevor du jemanden etwas fragst, solltest du dein Ziel kennen. Worum geht es bei der Frage, und wem nützt die Antwort? Geht es um das Team und nicht um deine eigene KPI-Zeile, verläuft das Gespräch anders.
Silos sind das Problem, das sich zu lösen lohnt
Das größte Hindernis für die Arbeit als Team ist, dass Menschen ihr Wissen abschirmen. In vielen Tech-Unternehmen und weit darüber hinaus horten Einzelne Daten, Informationen und Prozesse.
Laveena räumt ein, dass ein Stück Abschirmung verständlich ist. Die Leute schützen ihr Spezialgebiet und wollen es nicht jedem in die Hand geben. In einem Team, das gemeinsam etwas ausliefern will, arbeitet dieser Reflex aber gegen das Ganze.
Qualität sollte allen im Team wichtig sein, und wer sein Wissen für sich behält, bremst die Gruppe nur aus. Wer offener und hilfsbereiter ist, lässt alle schneller liefern. Horten schützt dich nicht, es behindert die Leute, auf die du angewiesen bist.
Tester mit offenen Fragen coachen
Sagt ein Tester, dass er etwas nicht schafft, ist es Zeit, sein Denken anzustoßen, nicht, die Sache zu übernehmen. Offene Fragen bringen Menschen dazu, selbst nachzudenken.
Laveenas Vorgehen, wenn ein Stakeholder Nein sagt: Sie fragt den Tester, warum er glaubt, dass die Antwort Nein war. So wird aus der Sackgasse ein Lernmoment, und die Person ist beim nächsten Mal besser vorbereitet. Sei Coach, bleib offen und lass sie selbst zur Antwort finden.
Das ist wichtig, weil sonst die Manager dauerhaft das ganze tiefere Wissen festhalten, während die Tester nur ihre Routine abarbeiten. Coaching soll genau diese Lücke schließen.
Wenn eine Person nicht mehr liefert
Manchmal reicht Coaching nicht, und das Team kann sich schlicht nicht darauf verlassen, dass jemand liefert. Dann steht die harte Frage im Raum, ob die richtigen Leute an der richtigen Stelle sitzen.
Laveena hat das in einem Migrationsprojekt mit einem Zulieferer erlebt. Der sagte zuversichtlich zu, die Arbeit zu übernehmen, und zog die Zusage zurück, als der Termin da war. Sie machte daraus eine Chance und testete die Migration selbst, mit dem Wissen aus einem Projekt, das sie zwölf Jahre zuvor gemacht hatte. Das macht nicht jede Führungskraft, und der Frust ist echt.
Sagt jemand Nein und kann das Team deshalb nicht mehr liefern, muss entschieden werden: mehr Leute einstellen oder die Person ersetzen. Solche Entscheidungen sind emotional schwer, denn niemand will einer Karriere schaden.
“Wenn du harte Entscheidungen treffen musst, damit es die richtigen Entscheidungen sind, dann triff sie. Fühl dich nicht schlecht. Du tust das Richtige.”
(Laveena Ramchandani)
Sei als Führungskraft ruhig ein bisschen streng und bau ein Team aus Machern auf, die zu ihren Zusagen stehen.
Führungsstil an die Person anpassen, nicht an ein anderes Team
Für die Führung von Testern gibt es kein Patentrezept, und das Setup eines anderen Teams auf deins zu übertragen, funktioniert nicht. Hör auf, ein Team an ein anderes anzugleichen.
Introvertierte und Extrovertierte bringen beide etwas mit. Laveena erzählt von einem introvertierten Kollegen in ihrem Team, der alles genau dokumentiert. Wissen weiterzugeben heißt bei ihm: ein Dokument verschicken. Auf diese Idee wäre sie selbst nicht gekommen, sagt sie. Extrovertierte wiederum sprechen mit Managern und übernehmen Führung.
Leute mit ähnlich viel Erfahrung wollen ihre Karriere trotzdem unterschiedlich gestalten. Manche haben eine klare Leiter vor Augen, vom Analysten über Senior und Lead bis zum Manager und weiter. Andere gehen einen Zickzackweg, weil sie sich noch orientieren, und das ist in Ordnung.
Als Coach fragst du zuerst, was die Person von ihrer Karriere will, bevor du sie anleitest. Erst zuhören, dann führen. Mit offenen Fragen statt Vorgaben kann sie ihre Richtung selbst benennen.
KI verändert den Job von Testern, sie beendet ihn nicht
KI wird Teile des Testens übernehmen, aber ein großer Teil bleibt eindeutig menschlich. Laveenas Antwort auf diese Sorge: annehmen, was kommt, statt es zu fürchten. Wer sich weigert, es zu lernen, kann damit auch nicht liefern.
Sie hat ihre Teams gebeten, keine Zeit mehr mit dem Schreiben von Testfällen zu verbringen, wo KI-Tools helfen können, auch mit intern verfügbaren Tools. Nutze sie, teste sie und übernimm nicht blind, was das Tool ausspuckt. Prüf mit gesundem Menschenverstand, ob das Ergebnis Sinn ergibt, und setz die Tools gezielt ein. KI lernt noch, also brauchst du weiterhin deinen eigenen Kopf.
Der menschliche Teil ist das Gefühl. KI kann dir nicht sagen, wie sich eine Anwendung anfühlt, ob eine Website einladend oder erschlagend wirkt, ob sie zu viele grelle Bilder hat. Bei der Barrierefreiheit kann nur ein Mensch diesen Eindruck liefern. KI ist in manchen Bereichen stark und stößt an ihre Grenzen, wo menschliches Urteil gefragt ist.
Qualität selbst hängt an diesem menschlichen Eindruck. Qualitätsmerkmale und KPIs münden alle in ein Gefühl guter Qualität, und dieses Gefühl ist menschlich. Deshalb gibt es in den nächsten Jahren reichlich Arbeit für Tester.
Warum Entwickler nicht die einzigen Tester sein sollten
Wer sich darauf verlässt, dass Entwickler ihren eigenen Code testen, holt sich Voreingenommenheit ins Haus, genau die, über die man sich bei KI Sorgen macht. Wer die eigene Arbeit prüft, kann sie nicht neutral sehen.
Laveena plädiert für eine eigene Testkompetenz im Team, auch in Form eines Software Developer in Test, der entwickelt, wenn Entwicklung gebraucht wird, und testet, wenn Tests gebraucht werden. Manche Start-ups sparen sich das und stellen zuerst nur Data Scientists oder KI-Entwickler ein, aber der Bedarf an Qualität und Test verschwindet dadurch nicht.
Tester denken über den Tellerrand hinaus, während Entwickler sich auf das Problem vor ihnen konzentrieren und liefern, was sie bauen sollen. Tester schlagen sich seitlich durchs Gebüsch und versuchen, Dinge kaputtzumachen, und genau daher kommen die unerwarteten Funde. Achte darauf, wen du einstellst, denn ein reines Entwicklungsteam ersetzt die Denkweise des Testens nicht.
Häufig gestellte Fragen
Ist Testing eine ingenieurwissenschaftliche Disziplin oder eine Supportfunktion?
Testen ist ingenieurwissenschaftliche Arbeit, und Tester gehören als vollwertige Mitglieder zum Entwicklerteam. Laveena Ramchandani zitiert einen Direktor ihres Unternehmens: Wenn du Code schreibst, bist du ein Ingenieur. Diese Sichtweise hebt die Rolle aus dem Rahmen einer Dienstleistungsfunktion heraus, die nur an die Entwicklung angehängt ist. Außerdem erweitert sie den Aufgabenbereich darauf, Veränderungen zu beeinflussen und die Denkweise der Menschen um dich herum zu verändern.
Sollte ein Testmanager weiterhin selbst aktiv testen oder aus der Ferne leiten?
Mit dem Team zusammenzuarbeiten ist besser, als es von oben zu leiten. Ein Titel macht noch keine Führungskraft, Einfluss schon. Und das Team sieht, wie die Arbeit tatsächlich gemacht wird, wenn der Manager mit ihnen testet. Ein häufiger Fehler ist, dass ein Manager das gesamte strategische Denken übernimmt, während die Tester sich nur auf Routineaufgaben konzentrieren. Dieses Denken im Team zu verbreiten, ist die eigentliche Führungsarbeit.
Was kannst du tun, wenn ein Stakeholder sich weigert, Informationen weiterzugeben?
Es gibt Wege, eine verschlossene Tür zu umgehen. Biete der Person eine Gelegenheit an und formuliere die Bitte so, dass sie sich auf das Team bezieht und nicht auf dich selbst, und achte auf deinen Sprachstil, denn dieselbe Bitte kommt unterschiedlich an, je nachdem, wie du sie formulierst. Mach dir vor der Frage klar, was dein Endziel ist: Wozu dient die Frage und wem nützt die Antwort? Auch nur die Hälfte zu erreichen, ist schon ein Fortschritt.
Warum ist es ein Problem, wenn Leute ihr Fachwissen für sich behalten?
Das eigene Wissen zu hüten ist das größte Hindernis für den gemeinsamen Erfolg als Team. Der Instinkt ist verständlich, da jeder sein Fachgebiet lieber schützen möchte, anstatt es einfach jedem preiszugeben, aber in einem Team, das gemeinsam an einem Ziel arbeitet, wirkt sich das nachteilig auf das Ganze aus. Qualität geht jeden etwas an, das Horten von Daten, Informationen oder Prozessen bremst die Gruppe also nur aus und behindert die Leute, auf die du angewiesen bist.
Wann ist es die richtige Entscheidung, ein Teammitglied zu ersetzen, anstatt weiter zu coachen?
Wenn eine Person nicht liefert und das Team dadurch lahmgelegt ist, steht man vor der Wahl: entweder mehr Leute einstellen oder die Person ersetzen. Laveena Ramchandani beschreibt einen Lieferanten bei einem Migrationsprojekt, der zunächst zuversichtlich „Ja“ sagte, dann aber seine Antwort änderte, als der Termin näher rückte. Sie testete die Migration selbst und griff dabei auf Arbeit zurück, die sie zwölf Jahre zuvor erledigt hatte. Solche Entscheidungen sind emotional belastend, aber dennoch lohnenswert.
Wird KI Software-Tester ersetzen?
Nein. KI kann Teile der Arbeit übernehmen, zum Beispiel das Schreiben von Testfällen, und Laveena Ramchandani hat ihre Teams gebeten, keine Zeit mehr damit zu verschwenden. Was dem Menschen vorbehalten bleibt, ist das Gefühl: ob eine Anwendung einladend oder überwältigend wirkt, ob eine Website zu viele auffällige Bilder enthält. Die Arbeit an der Zugänglichkeit hängt von dieser gelebten Reaktion ab. Nutze die Tools, aber kopiere ihre Ergebnisse nicht blind.
Können Entwickler ihren eigenen Code testen, anstatt spezielle Tester zu haben?
Wenn Entwickler ihre eigene Arbeit testen, führt das zu Voreingenommenheit, genauso, wie man sich bei KI-Systemen Sorgen um Voreingenommenheit macht. Tester schlagen Umwege ein und versuchen, Dinge zum Absturz zu bringen, während Entwickler dazu neigen, sich darauf zu konzentrieren, das vor ihnen liegende Problem zu lösen. Manche Start-ups stellen zunächst nur Datenwissenschaftler oder KI-Entwickler ein, aber der Bedarf an Qualität verschwindet dadurch nicht.
Wie coacht man Tester, die unterschiedliche Ziele für ihre Karriere verfolgen?
Frag die Person, was sie will, bevor du sie anleitest, und nutze dabei offene Fragen, anstatt sie in eine bestimmte Richtung zu lenken. Manche stellen sich eine klare Karriereleiter vor: vom Analysten über den Senior zum Lead bis hin zum Manager; andere folgen einem Zickzack-Weg, während sie ihren Weg finden. Die Struktur eines anderen Teams einfach auf das eigene zu übertragen, funktioniert nicht. Ein introvertierter Tester dokumentiert alles detailliert: Wissen weiterzugeben bedeutet in diesem Fall also, ein Dokument zu schicken.
