Der Einfluss von Testern ist die Fähigkeit, Qualitätsbemerkungen bei verschiedenen Stakeholdergruppen Gehör zu verschaffen, sie ernst zu nehmen und zu handeln. Dazu muss ein und dasselbe Problem für jede Zielgruppe anders formuliert werden: Entwickler interessieren sich für Kontextwechsel und Bugfixes, Produktverantwortliche für die Akzeptanz von Funktionen und das Marketing für die Konversion. Kleine, kostengünstige Experimente mit sichtbaren Ergebnissen innerhalb von ein oder zwei Wochen schaffen schneller Vertrauen als lange Transformationsprogramme.
Das Wichtigste in Kürze
- Einem Produktverantwortlichen zu sagen, dass eine defekte Schaltfläche einen bestimmten Browser betrifft, der von einem Fünftel aller Nutzer verwendet wird, ist ein Beweis, keine Meinung.
- Kleine, kostengünstige Änderungen, die innerhalb von ein oder zwei Wochen Ergebnisse zeigen, sind leichter durchzusetzen als mehrmonatige Umstellungsprogramme, weil die Leute die Wirkung sehen und die Änderung aufgeben können, wenn sie nicht funktioniert.
- Tester brauchen für jeden Stakeholder eine andere Botschaft, denn ein und derselbe Fehler verursacht bei Entwicklern, Produktverantwortlichen und Marketingteams unterschiedliche Schmerzen, und eine einheitliche Beschwerde erreicht keinen von ihnen.
- Ein 15-Sekunden-Check beim Stand-up, der bestätigt, dass die Anforderungen in einem Ticket vorhanden sind, bevor es in Bearbeitung geht, kann das Hin und Her zwischen Testern, Entwicklern und Product Ownern reduzieren, das einen Sprint in die Länge zieht.
- Der Mini-Wasserfall innerhalb eines Sprints, bei dem alle Stories zwei Tage vor Ende des Sprints in der Testspalte landen, verschwindet, wenn das Testen als Teil der Entwicklungsarbeit behandelt wird und nicht als separate Phase danach.
Einflussnahme ist Teil des Testens, kein Soft Skill on top
Tester können ihre Arbeit nicht gut machen, ohne andere zu beeinflussen. Qualität ist ein zu umfassendes Thema, als dass es nur von einer Person verantwortet werden könnte. Deshalb kommt es darauf an, andere dazu zu bringen, das, was du sagst, ernst zu nehmen und danach zu handeln.
Das gilt für die meisten Rollen in der modernen Softwareentwicklung, aber für Tester ist es besonders wichtig. Du stehst mit mehr Stakeholdern in Kontakt als fast jede andere Rolle im Team. Entwickler, Product Owner, Ops- oder DevOps-Leute, manchmal auch ganze andere Teams. Jeder von ihnen hat einen Anteil daran, was “Qualität” in der Praxis bedeutet.
Kat Obring bezeichnet dies als die Rolle des Testers als Beeinflusser. Dabei geht es nicht um Selbstdarstellung. Es geht darum, sich Gehör zu verschaffen, damit eine Beobachtung über Qualität zu einer Entscheidung und dann zu einer Handlung führt.
Warum “alles kaputt ist” nie ankommt
Wenn du sagst “die Qualität dieser Veröffentlichung ist schrecklich”, haben die Leute nichts mit der Information zu tun. Die Aussage mag sogar richtig sein. Sie misslingt trotzdem, weil sie keine Verbindung zur tatsächlichen Arbeit von jemandem herstellt.
Verschiedene Interessengruppen interessieren sich für verschiedene Versionen desselben Problems. Schlechte Qualität schadet dem Unternehmen, aber sie schadet jeder Person anders. Ein Entwickler empfindet es als Zeitverlust durch Fehlerbehebung und Kontextwechsel. Ein Produktverantwortlicher empfindet es als eine Funktion, die die Benutzer nicht finden oder nicht annehmen wollen. Ein Marketingteam spürt es als Anmeldungen, die unter dem Zielwert bleiben, weil der Anmeldeprozess umständlich ist.
Hinter allen drei Beschwerden können die gleichen Fehler stecken. Was sich ändert, ist die Auswirkung auf die Person, die du vor dir hast. Der erste Schritt ist also nicht, zu reden. Es geht darum, zu verstehen, mit wem du sprichst und was für ihn oder sie im Moment wichtig ist.
Beweise schlagen Meinungen, wenn du Taten willst
Ersetze deine Meinung durch etwas Messbares, und das Gespräch ändert sich. “Der Anmeldefluss ist kaputt” ist eine Meinung. “Diese Schaltfläche funktioniert nicht auf Safari, und ein großer Teil unserer Nutzer/innen nutzt Safari, so dass wir sie jedes Mal verlieren, wenn sie diesen Prozess durchlaufen” ist ein Beweis.
Beweise beseitigen den Streit darüber, ob du Recht hast. Sie lenken die Diskussion direkt darauf, was als Nächstes zu tun ist. Kat baut dies in eine Methode ein, die sie QED nennt: Fragen, Beweise, Entwickeln. Du befundest einen konkreten Punkt, an dem etwas nicht funktioniert, stellst eine gezielte Frage dazu, sammelst Beweise für die tatsächliche Auswirkung und erst dann führst du das Gespräch mit den betreffenden Interessenvertretern.
Das Framing und die Beweise arbeiten zusammen. Wähle den Aspekt des Problems, der für die betreffende Person wichtig ist, und untermauere ihn mit einer Tatsache, die sie nicht wegwischen kann.
Sprich mehr als eine Sprache im Team
Eine gemeinsame Sprache reicht nicht aus, denn jede Rolle legt auf andere Dinge Wert. Du brauchst eine etwas andere Version deiner Botschaft für die Entwickler, für die Product Owner und für die Ops.
Das bedeutet nicht, dass die Sprache unklar ist. Ein Team sollte sich darüber einig sein, was seine Worte bedeuten, auch wenn die Definitionen keinem externen Standard entsprechen. Kat ist es egal, ob die Vorstellung eines Teams von einer “Teststufe” mit den großen Test-Frameworks übereinstimmt. Es ist ihr wichtig, dass alle im Team dasselbe meinen, wenn sie “Integrationstest” sagen
Präzision innerhalb des Teams und maßgeschneidertes Framing für die Stakeholder sind zwei verschiedene Disziplinen. Beides ist wichtig.
Kleine Veränderungen schlagen große Transformationsprogramme
Eine Veränderung, die du innerhalb von ein oder zwei Wochen beurteilen kannst, ist besser als eine sechs-, zwölf- oder achtzehnmonatige Umgestaltung. Die langen Programme sind meist gut gemeint und gut durchdacht. Sie sind aber auch schwer zu unterstützen, weil sie von den Menschen verlangen, blind zu glauben, dass sich die Dinge später verbessern werden, während das Leben jetzt härter wird.
Menschen lassen sich auf etwas ein, das leicht zu tun ist. Sie wehren sich gegen Anstrengungen, deren Ergebnis weit in der Zukunft liegt. Der Hebel ist also nicht das Ausmaß des Plans, sondern die Frage, wie schnell jemand sehen kann, ob die Veränderung funktioniert.
Billige Experimente haben noch einen zweiten Vorteil. Wenn du wenig investiert hast, bleibst du ehrlich, was das Ergebnis angeht. Wenn du zu viel Zeit, Geld oder Gedanken investierst, wirst du mit dem Ergebnis verheiratet. Du willst, dass es gelingt, und dieser Wunsch verstellt dir den Blick auf die Beweise.
“Gute Experimente sind die, bei denen du weißt, was du verändern willst. Du musst also wissen, wie der Erfolg aussieht. Aber sie sind auch einfach und billig genug, dass du, wenn du damit keinen Erfolg hast, sagen kannst: “Na gut, versuchen wir etwas anderes.” - Kat Obring
Ein 15-Sekunden-Check vor dem Aufstehen
Schwache Anforderungen sind ein ständiges Problem, und die üblichen Antworten schießen über das Ziel hinaus. Ein Team schraubt einen umfangreichen Review-Prozess an alles dran: mehr Reviews, mehr Meetings, mehr Workshops. Ein anderes Team schreibt immer detailliertere Anforderungstexte, was auch nicht hilft.
Der kleine Schritt ist anders. Bevor ein Ticket von “fertig” auf “in Arbeit” umgestellt wird, nimmt sich das Team beim Standup etwa fünfzehn Sekunden Zeit, um zu prüfen, ob die Anforderungen tatsächlich im Ticket stehen. Wenn sie fehlen, treffen sich zwei oder drei Leute direkt nach dem Standup und bringen das in Ordnung.
Wenn du das ein oder zwei Wochen lang konsequent machst, wird es zur Gewohnheit. Das zahlt sich aus: weniger Bugs, weniger Ping-Pong zwischen Tester, Entwickler und Product Owner darüber, was ein Button tun soll.
Wenn die Prüfung dein Problem nicht löst, lässt du sie fallen und probierst etwas anderes aus, vielleicht eine Vorlage für die Anforderungen. Dann kommst du in zwei Wochen wieder und schaust es dir erneut an. Bei jedem Zyklus lernt das ganze Team etwas über seine eigenen Anforderungen, was eine Vorlage allein nie schafft.
Hör auf, das Testen als eine Phase nach der Entwicklung zu behandeln
Der Mini-Wasserfall ist eine häufige Falle, besonders für Teams, die neu in Agile oder Scrum sind. Der Sprint beginnt, die Entwickler entwickeln, und zwei Tage vor Ende des Sprints landet jede Story auf einmal in der Spalte Testen. Von den Testern wird dann erwartet, dass sie alles vor der Deadline testen.
Die Lösung ist, das Testen nicht länger von der Entwicklung zu trennen. Testen ist ein Teil der Entwicklungsarbeit, keine Phase, die darauf folgt. Es gibt keine Testphase mehr, also muss das Testen vom Beginn eines Tickets an geplant und gestartet werden.
Ein konkreter erster Schritt: pair earlier. Ein Tester setzt sich zu Beginn eines Tickets mit einem Entwickler zusammen und sie besprechen, wie die Sache getestet werden soll. Der Entwickler baut es dann mit Blick auf die Testbarkeit, was auch bei den Unit Tests hilft. Das ist eine kleine Änderung, keine Umstrukturierung. Fang einfach früher mit dem Pairing an.
Die Ausrede der Introvertierten gilt nicht
Die Vorstellung, dass jeder in der Softwareentwicklung ein introvertierter Mensch ist, der am liebsten mit niemandem reden würde, muss verschwinden. Wenn du nicht im Team arbeiten kannst, wirst du als Tester keinen Erfolg haben. Dieser Teil ist ganz einfach.
Was du tun kannst, ist zu lernen, was für dich und für dein Team funktioniert. Kat, die sich selbst als introvertiert bezeichnet, hat schon früh in ihrer Karriere durch asynchrone, schriftliche Kommunikation ihren eigenen Weg gefunden und in Kalifornien, Deutschland, Großbritannien und Indonesien gearbeitet. Der schriftliche Austausch gab ihr Zeit, was umso wichtiger war, als Englisch nicht ihre Muttersprache ist.
Für Menschen auf dem neurodiversen Spektrum kann eine ständig eingeschaltete Kamera wirklich hart sein. Ein Treffen ohne Kamera ist eine faire Anpassung. Sprich mit deinem Team und deinem Teamleiter, finde die Einrichtung, die funktioniert, und nimm so viele kleine Anpassungen vor, wie du kannst. Das Einzige, was du nicht abstellen kannst, ist das Bedürfnis, überhaupt mit anderen Menschen zu sprechen.
Wie du auswählst, woran du tatsächlich arbeitest
Du hast mehr Einfluss, als du denkst, also wähle Schlachten, die du gewinnen kannst, und fange mit kleinen an. “Nichts funktioniert” mag wahr sein, aber es ist keine nützliche Aussage. Finde stattdessen etwas Konkretes.
Alles, was länger als ein oder zwei Wochen dauert, Geld kostet oder abgezeichnet werden muss, braucht wahrscheinlich die Zustimmung von jemandem über dir. Fang also damit an, was du zusammen mit einem Verbündeten im Team tun kannst, einem Entwickler oder einem Product Owner, der die gleichen Schmerzen hat. Ein Standup, das dreißig Minuten dauert, weil das halbe Team zu spät kommt, ist die Art von konkretem Ziel, das du deinem Teamleiter mitteilen kannst.
Um Prioritäten zu setzen, greift Kat auf die Eisenhower-Matrix zurück, die sich in wenigen Minuten mit einem Whiteboard und Klebezetteln erstellen lässt. Sie mag auch die Methoden der Liberating Structures Familie. Das Werkzeug ist weniger wichtig als die Disziplin, die dahinter steckt: ein konkretes Beispiel, eine Frage, der Nachweis der tatsächlichen Auswirkungen und dann eine schnelle Entscheidung darüber, was zu tun ist.
Das Ziel ist ein schnelles Ergebnis, auf das du reagieren kannst, nicht ein perfektes. Schnelligkeit des Lernens geht vor Perfektion, denn ein billiges Experiment, das fehlgeschlagen ist, kostet dich fast nichts und weist dich auf das nächste hin.
