Der Einfluss von Testern ist Einfluss ohne Weisungsbefugnis: die Fähigkeit, dass Hinweise zur Qualität bei ganz unterschiedlichen Stakeholdern Gehör finden, ernst genommen werden und etwas auslösen. Dafür muss dasselbe Problem für jede Zielgruppe anders erzählt werden. Entwickler interessieren sich für Kontextwechsel und Bugfixes, Product Owner dafür, ob ein Feature angenommen wird, das Marketing für die Conversion. Kleine, günstige Experimente, die nach ein bis zwei Wochen sichtbare Ergebnisse liefern, schaffen schneller Vertrauen als lange Transformationsprogramme.
Das Wichtigste in Kürze
- Ein Bug, der an seiner Wirkung fürs Geschäft festgemacht wird, kommt besser an als die Aussage, die Qualität sei schlecht: Wer dem Product Owner sagt, dass ein kaputter Button einen bestimmten Browser betrifft, den ein Fünftel aller Nutzer verwendet, liefert einen Beleg und keine Meinung.
- Kleine, günstige Änderungen, die nach ein bis zwei Wochen Ergebnisse zeigen, lassen sich leichter durchsetzen als monatelange Transformationsprogramme, weil alle die Wirkung sehen und die Änderung wieder fallen lassen können, wenn sie nicht funktioniert.
- Tester brauchen für jeden Stakeholder eine eigene Botschaft: Derselbe Bug tut Entwicklern, Product Ownern und dem Marketing an ganz verschiedenen Stellen weh, und eine pauschale Beschwerde erreicht keinen von ihnen.
- Ein 15-Sekunden-Check im Standup, ob die Anforderungen im Ticket stehen, bevor es auf “In Arbeit” wandert, spart viel Hin und Her zwischen Testern, Entwicklern und Product Ownern, das sonst den Sprint in die Länge zieht.
- Der Mini-Wasserfall im Sprint, bei dem alle Stories zwei Tage vor Sprintende in der Testspalte landen, verschwindet, sobald Testen als Teil der Entwicklungsarbeit gilt und nicht als eigene Phase danach.
Einfluss von Testern gehört zum Job
Ohne andere Menschen zu beeinflussen, können Tester ihre Arbeit nicht gut machen. Der Einfluss von Testern gehört deshalb zum Handwerk: Qualität ist ein zu großes Thema, als dass eine einzelne Rolle sie verantworten könnte. Es kommt also darauf an, dass andere ernst nehmen, was du sagst, und danach handeln.
Das gilt für die meisten Rollen in der modernen Softwareentwicklung, trifft Tester aber besonders. Du hast mit mehr Stakeholdern zu tun als fast jede andere Rolle im Team. Entwickler, Product Owner, Ops- oder DevOps-Leute, manchmal ganze andere Teams. Jeder von ihnen trägt ein Stück dazu bei, was “Qualität” in der Praxis heißt.
Kat Obring beschreibt das als Tester in der Rolle eines Influencers. Um Selbstdarstellung geht es dabei nicht. Es geht darum, gehört zu werden, damit aus einer Beobachtung zur Qualität eine Entscheidung wird und aus der Entscheidung eine Handlung.
Warum “alles ist kaputt” nie ankommt
Wenn du sagst “Die Qualität dieses Releases ist grauenhaft”, kann niemand mit der Information etwas anfangen. Die Aussage mag sogar stimmen. Sie verpufft trotzdem, weil sie mit der tatsächlichen Arbeit von niemandem etwas zu tun hat.
Verschiedene Stakeholder interessieren sich für verschiedene Seiten desselben Problems. Schlechte Qualität schadet dem Unternehmen, aber jedem auf andere Weise. Für Entwickler ist sie Zeit, die in Bugfixes und Kontextwechseln verloren geht. Für Product Owner ist sie ein Feature, das die Nutzer nicht finden oder nicht annehmen. Das Marketing spürt sie an Anmeldezahlen, die unter dem Ziel bleiben, weil der Anmeldeprozess umständlich ist.
Hinter allen drei Beschwerden können dieselben Bugs stecken. Was sich ändert, ist die Wirkung auf die Person, die vor dir sitzt. Der erste Schritt ist also nicht reden, sondern verstehen: Mit wem sprichst du, und was ist für diese Person gerade wichtig?
Belege statt Meinungen: Fehler nach ihrer Wirkung einordnen
Ersetze deine Meinung durch etwas Messbares, und das Gespräch läuft anders. “Die Anmeldung ist kaputt” ist eine Meinung. “Dieser Button funktioniert in Safari nicht, ein Fünftel unserer Nutzer ist mit Safari unterwegs, und die verlieren wir jedes Mal an dieser Stelle” ist ein Beleg.
Belege beenden den Streit darüber, ob du recht hast. Die Diskussion springt direkt zu der Frage, was als Nächstes passiert. Kat hat daraus eine Methode gemacht, die sie QED nennt: Question, Evidence, Developed. Du suchst dir einen konkreten Moment, in dem etwas nicht funktioniert, stellst dazu eine scharfe Frage, sammelst Belege für die tatsächliche Wirkung, und erst dann führst du das Gespräch mit dem betroffenen Stakeholder.
Framing und Belege gehören zusammen. Wähl die Seite des Problems, die für genau diese Person zählt, und untermauere sie mit einer Tatsache, die sich nicht wegwischen lässt.
Im Team mehr als eine Sprache sprechen
Eine gemeinsame Sprache reicht nicht, weil jede Rolle auf andere Dinge Wert legt. Du brauchst eine leicht andere Version deiner Botschaft für die Entwickler, für die Product Owner und für Ops.
Das heißt nicht, dass die Sprache schwammig sein darf. Ein Team sollte sich einig sein, was seine Begriffe bedeuten, auch wenn die Definitionen keinem externen Standard folgen. Ob die Vorstellung eines Teams von einer “Teststufe” zu den großen Test-Frameworks passt, ist Kat egal. Wichtig ist ihr, dass alle im Team dasselbe meinen, wenn sie “Integrationstest” sagen.
Präzision nach innen und passendes Framing für die Stakeholder sind zwei verschiedene Disziplinen. Beide zählen.
Kleine Experimente statt großer Transformationsprogramme
Eine Veränderung, die du nach ein bis zwei Wochen beurteilen kannst, schlägt jede Transformation über sechs, zwölf oder achtzehn Monate. Die langen Programme sind meist gut gemeint und gut durchdacht. Hinter ihnen zu stehen fällt trotzdem schwer, weil sie verlangen, blind darauf zu vertrauen, dass es später besser wird, während der Alltag jetzt erst einmal anstrengender wird.
Menschen machen mit, wenn etwas leicht umzusetzen ist. Mit Aufwand, der sich erst in ferner Zukunft auszahlt, tun sie sich schwer. Der Hebel ist also nicht die Größe des Plans, sondern wie schnell jemand sieht, ob die Veränderung wirkt.
Günstige Experimente haben noch einen zweiten Vorteil: Wer wenig investiert hat, bleibt beim Ergebnis ehrlich. Steckst du zu viel Zeit, Geld oder Gedanken hinein, bist du mit dem Ergebnis verheiratet. Du willst, dass es klappt, und dieser Wunsch färbt unbemerkt, wie du die Belege liest.
“Gute Experimente sind die, bei denen du weißt, was du verändern willst. Du musst also wissen, wie Erfolg aussieht. Sie sind aber auch so einfach und billig, dass du, wenn es nicht klappt, sagen kannst: Na gut, dann probieren wir eben etwas anderes.”
(Kat Obring)
Ein 15-Sekunden-Check im Standup
Schwache Anforderungen sind ein Dauerproblem, und die üblichen Gegenmittel schießen über das Ziel hinaus. Das eine Team schraubt einen schweren Review-Prozess an alles: mehr Reviews, mehr Meetings, mehr Workshops. Das andere schreibt immer ausführlichere Anforderungstexte, was auch nicht hilft.
Der kleine Schritt sieht anders aus. Bevor ein Ticket von “Bereit” auf “In Arbeit” wandert, nimmt sich das Team im Standup etwa fünfzehn Sekunden, um zu prüfen, ob die Anforderungen wirklich im Ticket stehen. Fehlen sie, setzen sich zwei oder drei Leute direkt nach dem Standup zusammen und bringen das in Ordnung.
Wer das ein, zwei Wochen konsequent durchzieht, macht eine Gewohnheit daraus. Der Ertrag zeigt sich am anderen Ende: weniger Bugs, weniger Ping-Pong zwischen Tester, Entwickler und Product Owner darüber, was ein Button eigentlich tun soll.
Bringt der Check dein Problem nicht weiter, lässt du ihn fallen und probierst etwas anderes, vielleicht eine Vorlage für Anforderungen. Nach zwei Wochen schaust du wieder hin. Mit jedem Durchlauf lernt das ganze Team etwas über seine eigenen Anforderungen, und das schafft eine Vorlage allein nie.
Testen ist keine Phase nach der Entwicklung
Der Mini-Wasserfall ist eine häufige Falle, gerade für Teams, die neu in Agile oder Scrum sind. Der Sprint beginnt, die Entwickler entwickeln, und zwei Tage vor Sprintende landet jede Story auf einmal in der Testspalte. Dann sollen die Tester alles bis zur Deadline durchtesten.
Die Lösung: Testen nicht mehr von der Entwicklung trennen. Testen ist Teil der Entwicklungsarbeit, keine Phase, die danach kommt. Eine Testphase gibt es nicht mehr, also muss das Testen ab dem Start eines Tickets geplant und begonnen werden.
Ein konkreter erster Schritt: früher im Pair arbeiten. Zu Beginn eines Tickets setzt sich ein Tester mit einem Entwickler zusammen, und beide besprechen, wie das Ganze getestet werden soll. Der Entwickler baut es dann mit Blick auf die Testbarkeit, was auch den Unit-Tests zugutekommt. Das ist eine kleine Änderung, keine Umorganisation. Fang einfach früher mit dem Pairing an.
Introvertiert sein ist keine Ausrede
Die Vorstellung, in der Softwareentwicklung säßen lauter Introvertierte, die am liebsten mit niemandem reden, gehört abgeschafft. Wer nicht im Team arbeiten kann, wird als Tester keinen Erfolg haben. So einfach ist das.
Was du tun kannst: herausfinden, was für dich und dein Team funktioniert. Kat zählt sich selbst zu den Introvertierten. Früh in ihrer Karriere hat sie über asynchrone, schriftliche Kommunikation ihren Weg gefunden, während sie in Kalifornien, Deutschland, Großbritannien und Indonesien gearbeitet hat. Der schriftliche Austausch gab ihr Zeit, und das war umso wichtiger, weil Englisch nicht ihre Muttersprache ist.
Für neurodivergente Menschen kann eine ständig eingeschaltete Kamera richtig belastend sein. Ein Meeting ohne Kamera ist ein faires Entgegenkommen. Sprich mit deinem Team und deiner Teamleitung, findet das Setup, das funktioniert, und passt so viel im Kleinen an, wie es geht. Das Einzige, was sich nicht wegorganisieren lässt, ist, überhaupt mit anderen Menschen zu reden.
Wie du auswählst, woran du wirklich arbeitest
Du hast mehr Einfluss, als du denkst. Such dir also Kämpfe aus, die du gewinnen kannst, und fang mit kleinen an. “Nichts funktioniert” mag stimmen, hilft aber niemandem weiter. Such stattdessen etwas Konkretes.
Alles, was länger als ein, zwei Wochen dauert, Geld kostet oder abgezeichnet werden muss, braucht wahrscheinlich die Zustimmung von jemandem über dir. Fang also mit dem an, was du gemeinsam mit einem Verbündeten im Team angehen kannst, einem Entwickler oder Product Owner, dem dasselbe wehtut. Ein Standup, das dreißig Minuten dauert, weil das halbe Team zu spät kommt, ist genau die Art konkretes Ziel, mit dem du zu deiner Teamleitung gehen kannst.
Zum Priorisieren greift Kat zu einer schnellen Einschätzung nach Wirkung und Wichtigkeit, der Eisenhower-Matrix, in wenigen Minuten mit Whiteboard und Klebezetteln erledigt. Sie mag außerdem die Methoden aus der Familie der Liberating Structures. Das Werkzeug ist weniger wichtig als die Disziplin dahinter: ein konkretes Beispiel, eine Frage, ein Beleg für die tatsächliche Wirkung und dann eine schnelle Entscheidung, was ihr ausprobiert.
Ziel ist ein schnelles Ergebnis, mit dem du arbeiten kannst, kein perfektes. Schnell lernen schlägt Feinschliff, denn ein billiges Experiment, das scheitert, kostet dich fast nichts und zeigt dir das nächste.
Häufig gestellte Fragen
Müssen Tester Einfluss nehmen können, oder reicht es, Fehler zu finden?
Einfluss zu nehmen gehört zum Job dazu. Qualität ist ein zu weit gefasstes Thema, als dass eine einzige Rolle dafür zuständig sein könnte, daher zählt ein Befund erst dann, wenn jemand anderes ihn ernst nimmt und entsprechend handelt. Tester stehen außerdem mit mehr Beteiligten in Kontakt als fast jede andere Rolle im Team: Entwickler, Product Owner, Ops- oder DevOps-Mitarbeiter, manchmal sogar ganze andere Teams. Jeder von ihnen hat seine eigene Vorstellung davon, was Qualität in der Praxis bedeutet.
Warum hat derselbe Fehler für Entwickler, Product Owner und das Marketing unterschiedliche Bedeutung?
Weil jede Gruppe die Kosten in ihrer eigenen Währung spürt. Ein Entwickler empfindet schlechte Qualität als Zeitverlust durch Fehlerbehebung und Kontextwechsel. Ein Product Owner empfindet sie als eine Funktion, die Nutzer nicht finden oder nicht nutzen werden. Das Marketing empfindet sie als Anmeldungen, die unter dem Ziel bleiben, weil der Ablauf umständlich ist. Hinter allen drei Beschwerden stecken dieselben Fehler, daher erreicht eine pauschale Beschwerde keinen von ihnen.
Wie verwandelt man eine Beobachtung der Qualität in etwas, worauf ein Stakeholder reagiert?
Ersetze die Meinung durch etwas, das eine Messung darstellt. „Der Anmeldeablauf funktioniert nicht“ ist eine Meinung. „Dieser Button funktioniert in Safari nicht, und ein Fünftel unserer Nutzer nutzt Safari, daher verlieren wir sie in diesem Ablauf“ ist ein Beleg. Kat Obring nennt diese Abfolge „QED“: Finde einen konkreten Moment, stelle eine prägnante Frage, sammle Belege für die tatsächlichen Auswirkungen und gestalte dann das Gespräch so, dass es für die Person vor dir Sinn ergibt.
Warum finden mehrmonatige Verbesserungsprogramme so wenig Unterstützung?
Sie verlangen von den Leuten, blind zu glauben, dass sich die Dinge später verbessern werden, während die tägliche Arbeit jetzt schwerer wird. Eine Veränderung, die man innerhalb von ein oder zwei Wochen bewerten kann, lässt sich leichter mittragen, weil der Effekt sichtbar ist und die Veränderung wieder verworfen werden kann. Kostengünstige Experimente halten dich zudem auf dem Boden der Tatsachen: Sobald du Zeit, Geld und Gedanken investiert hast, willst du, dass das Ergebnis gelingt, und dieser Wunsch verzerrt deine Interpretation der Beweise.
Wie kann ein Team schwache Anforderungen beheben, ohne weitere Reviews und Workshops hinzuzufügen?
Mit einer etwa fünfzehnsekündigen Überprüfung beim Standup: Bevor ein Ticket von „bereit“ auf „in Bearbeitung“ wechselt, bestätigt das Team, dass die Anforderungen tatsächlich im Ticket enthalten sind. Fehlen sie, treffen sich zwei oder drei Leute direkt nach dem Standup und beheben das Problem. Wenn man das ein oder zwei Wochen lang durchhält, wird es zur Gewohnheit und verhindert das Hin und Her zwischen Tester, Entwickler und Product Owner darüber, was ein Button eigentlich tun soll.
Warum landen alle User-Stories erst kurz vor Sprintende im Test?
Das ist der Mini-Wasserfall, eine häufige Falle für Teams, die noch neu in Agile oder Scrum sind: Die Entwickler entwickeln, und zwei Tage vor dem Stichtag landen alle User-Stories auf einmal in der Test-Spalte. Das verschwindet, wenn das Testen aufhört, eine Phase nach der Entwicklung zu sein. Ein konkreter erster Schritt ist, früher im Pairing zu arbeiten: Ein Tester setzt sich zu Beginn eines Tickets mit einem Entwickler zusammen, um zu besprechen, wie es getestet werden soll. Das verbessert auch die Testbarkeit und die Unit-Tests.
Kann ein introvertierter Mensch gut in einer Testerrolle arbeiten?
Ja, aber nicht, indem man Menschen aus dem Weg geht. Wenn du nicht im Team arbeiten kannst, wird das Testen nicht funktionieren. Was hilft, ist, deine eigene Arbeitsweise zu finden: Kat Obring zählt sich selbst zu den Introvertierten und setzte zu Beginn ihrer Karriere auf asynchrone, schriftliche Kommunikation, während sie in Kalifornien, Deutschland, Großbritannien und Indonesien tätig war, denn das Schreiben gab ihr Zeit. Für neurodiverse Kollegen ist ein Meeting ohne Kamera eine angemessene Anpassung.
Welche Verbesserungen kann ein Tester umsetzen, ohne das Management zu fragen?
Alles, was länger als ein oder zwei Wochen dauert, Geld kostet oder eine Freigabe erfordert, braucht in der Regel die Zustimmung von oben. Alles, was unterhalb dieser Grenze liegt, kannst du gemeinsam mit einem Verbündeten im Team in Angriff nehmen, der die gleichen Probleme hat, sei es ein Entwickler oder ein Product Owner. Wähle ein konkretes Ziel statt „nichts funktioniert“: zum Beispiel ein Standup, das dreißig Minuten dauert, weil die Hälfte des Teams zu spät kommt.
