Burnout beim Softwaretesten: 6 Ursachen & wie man ihn behebt
Ist es möglich, in einem Softwareentwicklungsteam eine Situation zu schaffen, in der ein Tester sehr wahrscheinlich ausbrennt?
Wenn ja, was können Tester aus diesem Gedankenexperiment lernen?
Es stellt sich heraus, dass Burnout unter Fachkräften für Softwaretests in der Softwaretestbranche nicht nur ein Gedankenexperiment ist – es handelt sich um ein reales und weit verbreitetes Problem, von dem viele Entwickler, Ingenieure und Tester betroffen sind.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Ich habe mich eingehend mit dem Thema Burnout beim Softwaretesten beschäftigt und folgende Fragen gestellt:
- Wie äußert sich Burnout in dieser Branche?
- Wie groß ist das Problem?
- Was schafft Systeme, in denen Softwaretester ausbrennen?
- Wie können wir das Burnout-Problem aufschlüsseln – und lösen?
Die Antworten – oder zumindest der Anfang davon – finden Sie in diesem Artikel.
Burnout unter Fachkräften für Softwaretests in der IT
Arbeitsbedingter Stress ist etwas, das viele von uns in der IT-Branche erleben. Ich bin sicher, dass auch Sie Ihren Anteil an Stress haben. In meinem Umfeld ist Burnout leider in den letzten Jahren zu einem immer wichtigeren Thema geworden.
Ist Burnout ein Problem?
Als ich Jonathon Wright fragte: „Wie groß ist Ihrer Meinung nach das Burnout-Problem unter QA-Fachkräften?“, antwortete er:
„Es ist ein massives Problem. Berühmte Worte: Man kann nicht die ganze Zeit sprinten.“
Jonathon Wright, Moderator des Podcasts The QA Lead
Er erklärte weiter:
„Methoden wie Agile und DevOps fördern die Vorstellung, alles noch ‚schneller‘ zu erledigen. Wie kann eine QA-Fachkraft in der Landschaft des schnellen Scheiterns und schnellen Lernens messbaren Mehrwert schaffen?
In einem kürzlich erschienenen Podcast von QALead fiel der Begriff ‚langsamer werden, um schneller voranzukommen‘. Solange Unternehmen Misserfolge nicht feiern (was nur sehr wenige tun), helfen Sie jedes Mal, wenn Sie scheitern, nicht der Geschwindigkeit des restlichen Teams.
Der Hinweis steckt im Titel des überstrapazierten Burndown-Diagramms. Die Gamifizierung der Verpflichtung auf eine bestimmte Anzahl von Story Points erzeugt ungesunden Wettbewerb.
„Man wird gezwungen, mit weniger mehr zu leisten und nach einer unrealistischen Erwartung zu arbeiten, dass Arbeit in zweiwöchigen Sprints geliefert werden kann.“
Jonathon Wright, Moderator des Podcasts The QA Lead
Wie äußert sich Burnout in der QA?
Burnout ist in der Softwarebranche kein Einzelfall – aber wie sieht es aus?
Hier sind Aussagen von Fachkräften für Softwaretests, die zeigen, wie sich Burnout in der QA äußert.
„Wir müssen unseren Wert beweisen. Teams sagen mir, sie seien agil und bräuchten keine Tester.“
„Angst. Für QA-Fachkräfte ist es schwierig, sich vor einer wichtigen Veröffentlichung keine Sorgen zu machen oder sich nicht für die Ergebnisse verantwortlich zu fühlen.“
„Zeitdruck. Tester sind immer die Letzten. Und ich bekomme nie die Zeit, die ich brauche. Außerdem wird sie halbiert, weil die Entwickler ihre Zeit überschreiten.“
„Unrealistische Erwartungen. Ich könnte ewig testen und wäre trotzdem nicht in der Lage, alles zu testen. Sagen Sie das einmal einem Projektleiter. Was nützt ein Tester, der die Fehler nicht findet?!“
„Aus den Backlog-Einträgen herauszufinden, was getestet werden soll, ist fast unmöglich. Und niemand erwähnt Sonderfälle.“
„Die Verschwendung ist frustrierend. Entwickler können einen Fehler nicht reproduzieren, der Backlog-Eintrag ist veraltet oder der Fehler wurde bereits behoben.“
„Viele wollen keinen ehrlichen Bericht und schon gar keine schlechten Nachrichten. Wenn man darauf besteht, kann es persönlich werden.“
Warum kommt es zu Burnout?
In der Fachliteratur werden viele Faktoren genannt, die Stress verursachen und die Wahrscheinlichkeit eines Burnouts erhöhen. Es gibt individuelle Faktoren, zum Beispiel persönliche Antreiber wie „Sei perfekt“, „Beeil dich“, „Streng dich an“, „Sei stark“ oder „Mach es anderen recht“. Weitere Einzelheiten finden Sie in der Transaktionsanalyse.
Außerdem gibt es Stressfaktoren aus dem Arbeitsumfeld. Hohe Arbeitsbelastung, Zeitdruck, unerreichbare Ziele und Erwartungen, fehlende Kontrolle, eskalierte Konflikte, Angst vor dem Verlust des Arbeitsplatzes, Unzufriedenheit mit der Arbeit, Mobbing und vieles mehr. Wir kennen sie.
Vor einiger Zeit begann ich, Burnout aus systemischer Sicht zu betrachten, und erstellte ein Simulationsspiel, in dem Spieler das Schicksal eines Softwareentwicklungsteams beeinflussen können. Sie können die Teammitglieder ausbrennen lassen oder das lohnendste Projekt aller Zeiten schaffen.
Das Herzstück der Simulation ist ein Burnout-System, also ein System, das so aufgebaut ist, dass einige Mitglieder eines Teams letztendlich ausbrennen. Einen Einblick in das Spiel gibt es in meinem Blog.
Dieser systemische Ansatz funktioniert auch für verschiedene Rollen in einem Team. Ich habe dies für Experten für Benutzererfahrung umgesetzt und war überrascht, wie leicht sich diese Menschen in den Brennpunkt eines Burnout-Systems bringen lassen. Besonders wenn sie sich um die Nutzer kümmern, sind sie bereit, einen zusätzlichen Kampf auf sich zu nehmen und dabei unterzugehen.
Im Folgenden werde ich anhand einer Geschichte von Alan, einem QA-Experten, näher auf das Problem von Burnout in der Softwarebranche eingehen und es veranschaulichen.
Anschließend werde ich erläutern, wie Burnout-Systeme entstehen und was wir tun können, um diese Systeme zu verbessern.
Eine persönliche Geschichte über Burnout
Da ich nun überzeugt bin, dass ich ein Burnout-System für QA-Experten konstruieren kann, möchte ich euch Alan und seine Geschichte vorstellen.
Alan verfügt über fast zehn Jahre Erfahrung im Softwaretesten, insbesondere im Leistungstest. Er steht kurz davor, einem Entwicklungsteam beizutreten. Das Team arbeitet seit zehn Entwicklungszyklen an dem Projekt, vier weitere Entwicklungszyklen sind bis zur ersten Veröffentlichung geplant.
Wie war Alans erster Tag im Projekt?
Alan: Für mich gibt es viel zu tun. Die Software ist von geringer Qualität. Ich rechne mit vielen unentdeckten Fehlern und befürchte Schwierigkeiten, wenn ich sie bis zur Veröffentlichung nicht finden kann.
Markus: Die Fehler zu identifizieren, hat also oberste Priorität, um die Qualität zu verbessern?
Alan: Das ist ein Teil davon. Außerdem erwarten wir viele Nutzer. Die Leistungsfähigkeit der Software ist von größter Bedeutung, sobald wir sie für die breite Öffentlichkeit bereitstellen. Das Team ist sehr daran interessiert, von meiner Expertise auf diesem Gebiet zu profitieren.
Bisher ist Alan recht optimistisch, dass die mit dem Team vereinbarten Maßnahmen die Qualität der Software verbessern werden. Doch einen Entwicklungszyklus später, bei noch drei verbleibenden Entwicklungszyklen, wirkt Alan nicht mehr besonders fröhlich.
Was ist los?
Alan: Die zwei Wochen waren intensiv. Ich bin mit meinem Fortschritt nicht zufrieden. Ich wollte einen ersten, einfachen Leistungstest durchführen, bin davon aber noch weit entfernt.
Markus: Was hindert dich daran?
Alan: Ich brauche Unterstützung von den Entwicklern, aber sie sind völlig ausgelastet. Außerdem habe ich viel mehr Zeit als erwartet gebraucht, um die Software kennenzulernen und die von mir gefundenen Fehler zu melden.
Markus: Konntest du die neuen, vom Team gelieferten Anwenderanforderungen testen?
Alan: Nicht wirklich, das Team war damit beschäftigt, sie fertigzustellen. Von den zwei Tagen, die am Ende des Entwicklungszyklus für Tests vorgesehen waren, blieb nur ein halber Tag übrig. Ich bin länger geblieben und habe am Samstag gearbeitet, aber ich bin noch lange nicht fertig.
In der Retrospektive des zwölften Entwicklungszyklus, bei nur noch zwei verbleibenden Entwicklungszyklen, ist das Testen das wichtigste Thema: Der Produktverantwortliche beschwert sich über die Anzahl der von Alan gefundenen Fehler.
Entwickler: Die meisten von Alan gefundenen Fehler sind entweder unbedeutend oder überhaupt keine Fehler. Lasst uns sie erst einmal aussortieren, bevor wir voreilige Schlüsse ziehen.
Alan: Nun, es war für mich schwierig, anhand der Einträge im Arbeitsvorrat zu verstehen, was die Software tun sollte. Eine Spezifikation wäre wirklich hilfreich.
Entwickler: Nicht über meine Leiche! Wir wollen kein Wasserfallmodell. Das meiste ist gesunder Menschenverstand. Komm einfach vorbei und frag uns. Wie läuft der Leistungstest?
Alan: Ich komme nicht weiter. Ich kann das Werkzeug wegen der ganzen Sicherheitsvorkehrungen nicht gegen die Serviceschicht ausführen. Ich brauche Hilfe.
Entwickler: Wir haben im letzten Projekt ein anderes Werkzeug verwendet. Das hat hervorragend funktioniert. Ich schicke dir den Link.
Daraufhin organisiert der PO im nächsten Entwicklungszyklus ein knappes zweistündiges Treffen. Ziel ist es, die Fehler zu überprüfen und zu besprechen, was in den Einträgen im Arbeitsvorrat dokumentiert werden sollte, um es dem Neuling Alan leichter zu machen. Könnt ihr spüren, wie Alans Frustration zunimmt?
Alans fatale Position als Sündenbock wird nach dem dreizehnten Entwicklungszyklus, bei nur noch einem verbleibenden Entwicklungszyklus, immer offensichtlicher. Hier sind die Entscheidungen aus dieser Retrospektive:
- Viele Fehler wurden in Anwenderanforderungen gefunden, die Alan bereits im vorherigen Entwicklungszyklus hätte testen sollen. Keine Anwenderanforderung darf abgeschlossen werden, ohne dass Alan sie getestet hat.
- Immer noch kein Leistungstest. Wir lassen einen Experten darauf schauen. Alan soll ihn einweisen.
- Zwei Anwenderanforderungen konnten nicht abgeschlossen werden. Wir haben zwei Tage damit verloren, nutzlose Fehlerberichte auszusortieren. Alan kennzeichnet jeden Fehler nach seiner Relevanz. Im Zweifelsfall den Produktverantwortlichen fragen.
Haben Sie es bemerkt? Das Team hat zwei User-Storys nicht fertiggestellt und es geschafft, Alan die Schuld dafür zu geben!
Stellen Sie sich den nächsten Sprint vor, in dem User-Storys nicht abgeschlossen werden, weil Alan keine Zeit hatte, sie zu testen! Kein Wunder, dass Alan erschöpft aussieht.
Alan: Nur noch zwei Wochen bis zur Veröffentlichung, und die Qualität ist ein Albtraum. Erzählen Sie das dem Produktverantwortlichen! Und sie haben mir auch noch die Leistungstests entzogen. Das war überhaupt der Grund, warum ich in das Projekt eingestiegen bin. Mein Chef ist unzufrieden. Er wollte, dass ich ein Beispiel dafür gebe, wie man Tester in agile Teams einbindet. Ich werde mich da wohl durchkämpfen müssen, schließlich steht mein Ruf im Unternehmen auf dem Spiel.
Vier Wochen später, zwei Wochen nach der ersten Veröffentlichung für ein ausgewähltes Publikum, ist das Burnout-System vollständig funktionsfähig.
Alans Zusammenfassung seiner bisherigen Erfolge:
- Leistungstests: fehlgeschlagen
- Als Experte für Leistungstests anerkannt werden: fehlgeschlagen
- Neu entwickelte Dinge gründlich testen können: fehlgeschlagen
- Bereits entwickelte Dinge gründlich erneut testen können: fehlgeschlagen
- Tester in agile Teams integrieren: fehlgeschlagen
- Keine kritischen Fehler in der Veröffentlichung: fehlgeschlagen
- Weiterempfohlen werden: fehlgeschlagen
- Hart arbeiten und beschuldigt werden: erreicht
- Angst, den Arbeitsplatz zu verlieren: erreicht
- Ausbrennen: steuert mit voller Geschwindigkeit darauf zu
Dies ist ein klassischer Fall eines Burnout-Systems. Was also erzeugt dieses System, und wie können wir ihm entgegenwirken?
Was erzeugt ein Burnout-System?
Für Alan ist es, könnte man sagen, von Anfang an eine aussichtslose Sache. Und damit hätten Sie recht. Alan befindet sich in einem Burnout-System, das schon seit geraumer Zeit im Team wirkt. Das Burnout-System nimmt Alan wie ein Raubtier sein Opfer ins Visier. Doch was ist dieses Burnout-System, und wie tut es das?
Ein Burnout-System ist eine Konstellation aus Menschen, Triebkräften und Konflikten. Durch einen sich selbst verstärkenden Kreislauf erzeugt es eine Situation, die so voller Stressfaktoren ist, dass einige Menschen schließlich ausbrennen werden. Es ist besonders mächtig, wenn es die Überlebenslogik von Menschen auslösen kann.
1. Energie folgt den Triebkräften
In Alans Geschichte können wir einige Triebkräfte erkennen:
- Ehrgeiz und Begeisterung für das Lieblingsthema Leistungstests bringen Alan dazu, es zu tun.
- Die Angst, für eine fehlgeschlagene Veröffentlichung verantwortlich zu sein, treibt Alan dazu, nach Fehlern zu suchen.
- Etwas bringt die Teammitglieder dazu, vor allem Funktionen zu entwickeln.
Triebkräfte verändern den Handlungsverlauf. Menschen tun sich sehr schwer damit, klar darüber nachzudenken, was sie erreichen wollen und wie sie es erreichen können. Die Energie, die Menschen investieren, folgt der Triebkraft und nicht dem Ort, an dem sie am dringendsten benötigt wird. Alans Team hinterfragt nie, ob es richtig ist, alle Funktionen zu entwickeln. Auch Alan hinterfragt nicht, ob die Suche nach Fehlern angemessen ist.
Das Schwierige für die meisten von uns ist, zu erkennen, dass eine Triebkraft die Kontrolle übernommen hat. Gut für uns, dass Psychologen sie untersucht haben. Bei persönlichen Triebkräften sollten Sie mit der Transaktionsanalyse beginnen. Auf Teamebene ist Gruppendenken ein guter Ausgangspunkt. Dort finden Sie jede Menge Ratschläge.
Im Zusammenhang mit der Angst vor einer Veröffentlichung riet ein erfahrener QA-Fachmann: „Man muss es einfach loslassen und gelassen bleiben“. Mit einer solchen Einstellung von Anfang an würde Alan wahrscheinlich ein anderes Ziel verfolgen als die Jagd nach allen Fehlern und das Einrichten von Leistungstests. Die obersten Prioritäten könnten darin bestehen, dass das Team die kritischen Fehler beseitigt und insgesamt eine höhere Qualität liefert. Eine Möglichkeit, den mit sich wiederholenden Aufgaben verbundenen Stress zu reduzieren, besteht darin, hochwertige Werkzeuge für Softwaretests einzusetzen.
2. Konflikte heizen die Situation an und werden persönlich
Neben den Triebkräften brechen im Team Konflikte aus. Alan benötigt beispielsweise mehr Zeit von den Entwicklern, als diese bereit sind aufzubringen. Das Ergebnis: Alan macht viel Lärm, und die Entwickler versuchen, ihn sich vom Hals zu halten. Da ihm nur wenig Unterstützung bleibt, kann Alan die Erwartungen nicht erfüllen. Er fürchtet um seinen Ruf, verdoppelt seine Anstrengungen und erzeugt noch mehr Lärm.
Das wirklich Schlimme ist, dass Konflikte persönlich werden. Da Alan zehn Jahre als Tester gearbeitet hat, ist er wahrscheinlich durchaus ein Experte. Trotzdem sieht das Team ihn als Versager und verhält sich entsprechend. Je länger dies andauert, desto schlimmer wird es. Das wirkt sich sogar auf Alan aus: Er beginnt, an seiner Kompetenz zu zweifeln.
Wie oft haben Sie jemandem die Schuld gegeben? Wie viele Menschen in Ihrem Umfeld leisten keine gute Arbeit? Jeder solche Gedanke weist auf einen Konflikt hin, der persönlich geworden ist.
Die meisten Teams sind nicht in der Lage, Konflikte zu lösen. Das fällt nicht leicht. Konfliktmanagement ist das Stichwort, unter dem Sie Rat finden können. Die grundlegende Botschaft lautet: Teams brauchen eine Kultur, in der Ideen offen ausgetauscht werden können, abweichende Ansichten als Chancen zur Schaffung neuer Dinge willkommen sind und gegenseitige Unterstützung geschätzt wird. Eine schwierige Sache, wenn man dies mit der Kultur der Geschwindigkeit vergleicht, die ein Interviewpartner beschreibt: „Solange Unternehmen das Scheitern nicht feiern, hilft man jedes Mal, wenn man scheitert, der Teamgeschwindigkeit nicht.“
3. Die Teamstruktur beeinflusst die Teamdynamik
Alans Team reservierte die letzten beiden Tage des Sprints für das Testen, den Abschluss des Sprints und die Vorbereitung des nächsten Sprints. Das Team nahm einfach an, dass Alan dieser Struktur folgt. Er würde die neu implementierten Funktionen am Ende des Sprints testen, im nächsten Sprint ebenfalls einige Nachtests durchführen und das Testen insgesamt verbessern. Klingt doch gar nicht schlecht, oder?
Die Realität sieht anders aus. Die Software ist erst am letzten Tag des Sprints verfügbar. Backlog-Elemente helfen kaum dabei zu verstehen, wie sie genau funktionieren soll. Während das Team die Details dessen bespricht, was es im nächsten Sprint tun wird, versucht Alan herauszufinden, was aus diesem Sprint getestet werden soll. Anschließend stellt er Fragen, kurz bevor die Entwickler gehen, und testet am Wochenende. Gut, dass das Team bespricht, was aufgeschrieben werden soll. Dann kann Alan testen, ohne die Entwickler zu stören. Treffer.
Die Teamstruktur isoliert Alan zunehmend. Das Team sieht nicht, wie er sich abmüht. Es bemerkt nur dumme Fragen und verspätete Ergebnisse mit geringem Nutzen. Was für ein Pechvogel.
Die Spezifikation anhand von Beispielen zeigt sehr schön, wie das Testen und Tester ein integraler Bestandteil eines agilen Teams sein können. Tester nehmen an Verfeinerungen teil, helfen bei der Erstellung einer testbaren Spezifikation, richten die Testaufwände auf die relevanten Bereiche aus, verbessern Teamprozesse, individuelle Fähigkeiten und Werkzeuge und führen sogar einige Tests selbst durch. Getestet wird kontinuierlich, nicht erst am Ende des Sprints.
4. Grundlegende Regeln ignorieren und sich Schwierigkeiten einhandeln
Alans Team ignoriert grundlegende Regeln der Softwareentwicklung.
Hier sind fünf davon:
- Unerwartete Dinge geschehen. Wer für sie nicht genügend Spielraum lässt, verursacht Hektik, Abkürzungen, dumme Fehler, eskalierende Konflikte und damit langfristig langsamere Fortschritte.
- Druck führt zu Verzögerungen. Druck lässt weniger Raum für unerwartete Dinge.
- Qualität entsteht im Prozess. Das Team braucht eine Qualitätskultur. Testen ist nur ein Teil des Puzzles. Und ein einzelnes Teammitglied allein gegen alle anderen scheitert normalerweise.
- Veränderungen im Team bremsen. Vertrauen aufzubauen, Prozesse anzupassen und weitere Konflikte zu lösen: Das Team braucht Zeit und Energie, um neue Teammitglieder zu integrieren. Menschen zu einem verspäteten Projekt hinzuzufügen, macht es noch später.
- Aus Fehlern soll man lernen. Wenn ein Prozess zu viele Fehler hervorbringt, sollte man ihn stoppen, korrigieren und daraus lernen. Keine Schuldzuweisungen und vor allem keine Beschleunigung.
Es gibt noch weitere solche Regeln, und wann immer Menschen sie ignorieren, wird sich die Situation verschlimmern. Und genau das geschah bei Alan.
5. Die Wahrnehmung einer angespannten Situation setzt dies in Gang
Warum ignoriert das Team solche grundlegenden Dinge? Eine einfache Antwort: Das ist typisch für eine angespannte Situation, in der die Vorgaben (Lieferumfang, verfügbare Zeit und Teamgröße) nicht genügend Flexibilität lassen, um mit unerwarteten Ereignissen umzugehen. Das kennt man, das hat man erlebt – ein eindeutiger Fall. Systeme, die zum Ausbrennen führen, schöpfen die einzige Variable in einer angespannten Konstellation aus: wie hart das Team arbeitet, also wie viel Energie die Teammitglieder aus ihren Batterien verbrauchen.
Die entscheidende Frage lautet: Befindet sich Alans Team wirklich in einer angespannten Situation, und ist es tatsächlich der beste Weg, alle Funktionen zu liefern? Wir können nur Vermutungen anstellen. Das Team tat dasselbe und eilte los, um alle Funktionen zu entwickeln.
Entscheidend ist die Wahrnehmung angespannter Situationen. Auslöser für eine solche Wahrnehmung können eine Vertragsklausel, ein Anreiz, eine großartige Marktchance, eine starke Forderung des Vorgesetzten, ein gegebenes Versprechen, der Wunsch eines Kunden oder eine staatliche Vorschrift sein.
Alan erwartet eine große Zahl von Fehlern, und die Angst lässt ihn nach ihnen suchen. Die entscheidende Frage für ihn lautet: Ist das Finden der Fehler in diesem Fall wirklich ein so wichtiger Schritt? Wir können nur spekulieren, und Alan tat dasselbe. Er nahm an, dass dies der Fall sei.
Die Wahrnehmung einer angespannten Situation ist ein wichtiger Hebel, um ein System zum Ausbrennen zu durchbrechen. Dahinter steht eine weitere grundlegende Regel der Softwareentwicklung:
- Zu hohe Erwartungen. Stakeholder – einschließlich der Entwickler selbst – hoffen, erwarten oder verlangen mehr, als ein Softwareteam realistischerweise liefern kann.
Wenn ich auf die letzten 25 Jahre meiner Projekterfahrung zurückblicke, kann ich mich an kein einziges Projekt erinnern, bei dem dies nicht der Fall war. Der Konflikt zwischen dem, was erwartet wird, und dem, was geliefert werden kann, ist der kritische Punkt. Der Erfolg eines Projekts hängt davon ab, wie gut die Beteiligten diesen Konflikt lösen können. Ich würde empfehlen, gute Praktiken zum Stakeholder- und Erwartungsmanagement, Konfliktmanagement, zur Anforderungsermittlung, Agilität und Ähnlichem zu prüfen.
In jedem Fall gilt es, die genaue Art des Konflikts zu verstehen. Wie stark ist er? Was treibt ihn an? Mit wem muss man zusammenarbeiten? Oder wie es einer der befragten QA-Fachleute ausdrückte: „Ich glaube, jedes Unternehmen muss eine bewusste Entscheidung in Bezug auf Qualität, Kosten und Geschwindigkeit treffen.“ Jedes Unternehmen muss an seinen Erwartungen arbeiten.
QA-Fachleute sind normalerweise nicht in der Lage, diese Diskussion zu führen. Sie können versuchen, dazu beizutragen. Es kann jedoch zielführender sein, die Erwartungen zu steuern, mit denen sie persönlich konfrontiert sind. Eine Befragte verriet mir ihr Rezept: „Es ist unmöglich, alles zu testen. Am besten legt man gemeinsam mit dem Product Owner ein Zeitfenster und die Prioritäten fest. Die Prioritäten spiegeln das Risiko wider, das entsteht, wenn nicht getestet wird. Wenn man nicht zufrieden ist, verhandelt man das Zeitfenster und die Prioritäten neu.“
6. Agile Falle
Ein starkes Team, das sich kontinuierlich an die sich verändernden Anforderungen anpasst, eine unbürokratische Art, mit Veränderungen umzugehen, einfache Mittel zur Planung und Fortschrittskontrolle: Die agile Bewegung hat eine Fülle von Innovationen hervorgebracht, von denen Entwicklungsteams gut beraten sind, zu profitieren. Dennoch scheint Agile die Situation weiter anzuheizen.
Es beginnt schon bei der Namensgebung: Sprint bedeutet schnell, Geschwindigkeit bedeutet schnell, man scheitert schnell. Agile Prinzipien stellen den Code an die erste Stelle, vorausschauendes Denken wird leicht als Verschwendung abgetan. Selbst der Begriff Scrum stammt aus dem Rugby, einem Sport, bei dem Athleten mit voller Geschwindigkeit aufeinander losgehen. So fördert Agilität, entgegen ihrer eigenen Überzeugung, Geschwindigkeit auf Kosten der Qualität. „Methoden wie Agile und DevOps fördern die Vorstellung, alles noch schneller zu erledigen“, beklagte sich ein QA-Fachmann.
Die Mechanismen von beispielsweise Scrum sind noch schlimmer als die Namensgebung. Es ist nicht so, dass diejenigen, die Scrum entwickelt haben, Burnout fördern wollten. Aber Scrum führt die Teams auf einen Holzweg.
Einerseits richtet es die Aufmerksamkeit des Teams auf das Backlog. Die Aufgabe des Product Owners besteht darin, Dinge in das Backlog zu stellen. Die Aufgabe eines Teammitglieds besteht darin, sie zu übernehmen und eine nach der anderen zu erledigen. Die Aufgabe des Scrum Masters besteht darin, dafür zu sorgen, dass dies schneller geschieht. Außerdem erfordert die agile Fortschrittskontrolle kleine Backlog-Einträge, die innerhalb weniger Tage erledigt werden können. Experten empfehlen außerdem, die Abnahmekriterien vor dem Sprint genau auszuarbeiten. Teammitglieder erhalten genau definierte und kleine Arbeitspakete zur Lieferung. Sie berichten täglich, wie viel Zeit sie noch benötigen, um sie abzuschließen. Die Geschwindigkeit sagt allen, wie gut sie vorankommen. Mikromanager jubeln und kontrollieren jede Minute: mangelnde Kontrolle, kein kreativer Freiraum, der Druck, schneller zu werden – ein Wettlauf wie im Hamsterrad.
Angesichts dessen: Spielt es in einer scheinbar angespannten Situation eine Rolle, ob das Produkt für die Nutzer großartig ist? Verdammt, nein, das ist die Aufgabe des UX-Teams. Spielt es eine Rolle, ob es sinnvoll ist? Aufgabe des Product Owners. Spielt es eine Rolle, ob die Abnahmekriterien vollständig sind? Wieder die Aufgabe des Product Owners. Ist es wichtig, fehlerfrei zu sein? Aufgabe des Testers, sobald die Abnahmekriterien erfüllt sind. Was zählt? Dass ich meinen Backlog-Eintrag rechtzeitig abschließe. Sehen Sie Alans Position? Scrum führt Teams dazu, alle Funktionen umzusetzen. Qualität ist Alans Aufgabe. Die grundlegende Regel wird verletzt, die Dinge werden schlimmer.
Auch Alans Team hält sich an die Verpflichtung. Sie füllen den Sprint mit so vielen Backlog-Einträgen, wie es die Geschwindigkeit vorgibt. Dann schwören sie, diese zu liefern. Das nächste grundlegende Gesetz trifft sie: Unvorhergesehene Dinge geschehen. Statt den Schwur zu brechen, nimmt das Team Abkürzungen und spart an einigen Teilen des Testens. Rechtzeitig fertig, gut gemacht! Einer der Befragten brachte es ganz klar auf den Punkt: „Die Gamifizierung der Verpflichtung auf eine bestimmte Anzahl von Aufwandspunkten erzeugt ungesunden Wettbewerb.“
Alans Team ist in die agile Falle getappt. Sie wenden Scrum an, ohne agil zu sein. Vergleichen Sie die folgenden beiden Bilder: Das erste zeigt, worum es bei Scrum geht, das zweite, worum es bei Agilität geht.
Bei Scrum geht es um den Prozess, Backlog-Einträge in ein Produkt umzuwandeln.
Bei Agilität geht es darum, mit einem Produkt Wirkung zu erzielen, und um die Interaktionen der beteiligten Personen: derjenigen, die ein Produkt in Auftrag geben, derjenigen, die es nutzen, und derjenigen, die es entwickeln.
Während Scrum ein großartiges Werkzeug für intrinsisch motivierte agile Teams ist, ist es in einer hierarchischen Befehlsstruktur von oben nach unten fatal!
Erkenntnisse
In der Softwarebranche ist es wichtig, Abwehrmechanismen gegen Stress und Burnout unter Fachleuten im Softwaretesten zu entwickeln. In manchen Unternehmen mehr als in anderen. Manche Situationen sind wirklich angespannt, andere werden absichtlich angespannt gemacht. Doch die meisten Situationen scheinen viel angespannter zu sein, als sie tatsächlich sind. Und das führt dazu, dass wir unseren inneren Antreibern folgen, die Konflikte nicht bearbeiten und grundlegende Regeln ignorieren.
Die folgende Tabelle fasst die Zahnräder eines Burnout-Systems zusammen.
Schlüsselelemente eines Burnout-Systems
- Wahrgenommene Anspannung ist die Lücke zwischen dem, was wir als unsere Aufgabe ansehen, und dem, was wir liefern können. Zu erkennen, was wirklich das Beste ist, das erreicht werden kann, kann das Burnout-System auflösen.
- Antreiber bestimmen, wohin die Energie fließt, und hindern uns daran, in einer angespannten Situation klug zu handeln. Wenn wir unsere Antreiber erkennen, kann uns das helfen, weniger Energie aufzuwenden und sie sinnvoller einzusetzen.
- Konflikte heizen die Situation an, machen ein Team weniger effektiv und entziehen Energie. Wir sollten eine Teamkultur schaffen, in der wir Konflikte willkommen heißen und uns gegenseitig unterstützen.
- Grundlegende Regeln werden leicht ignoriert. Zu sehen, dass sie ignoriert werden, ist ein sicheres Zeichen dafür, dass sich die Dinge verschlimmern werden. Wir müssen handeln!
- Teamstrukturen konservieren gute und schlechte Praktiken. Eine Veränderung der Teamstrukturen kann grundlegend verändern, wer was tut und wie Menschen miteinander interagieren. Sie kann die Spielregeln vollständig verändern.
- Teufelskreise entstehen aus dem Zusammenspiel der Akteure innerhalb und außerhalb des Teams und verschlimmern die Situation immer weiter. Können wir die Teufelskreise erkennen, in die wir geraten sind? Wir müssen sie stoppen und beheben!
- Die agile Falle besteht darin, agile Rahmenwerke zu übernehmen, ohne agil zu sein. Das Ergebnis ist ein Wettlauf wie im Hamsterrad. Konzentrieren wir uns auf die Nutzer, die Entwicklung eines großartigen Produkts und darauf, wie wir miteinander interagieren, statt Backlog-Einträge einfach abzuarbeiten.
Als QA-Fachmann sind Sie möglicherweise nicht in der Lage, die Gesamtsituation zum Besseren zu verändern. Aber wahrscheinlich können Sie einen Teil des Stresses reduzieren.
Ich fragte Jonathon Wright: „Wo haben Sie erlebt, dass Unternehmen oder Teams Maßnahmen ergriffen haben, um die psychische Gesundheit von QA-Fachleuten zu fördern? Was funktioniert?“
Er antwortete,
„Nachdem ich das vergangene Jahr damit verbracht hatte, die britische Regierung auf den Brexit vorzubereiten, war ich von der Arbeitsmoral äußerst beeindruckt. Ich nahm an meinem ersten verpflichtenden Achtsamkeitskurs teil, der äußerst hilfreich war. Vor Ort gab es Spezialisten für psychische Gesundheit und sogar Selbsthilfegruppen, die sich wöchentlich trafen.“
Er wies außerdem darauf hin, dass QAs viel tun können, um ihren Stress und ihre Angst auf persönlicher Ebene zu bewältigen:
„Das Leben ist zu kurz, um sich über Kleinigkeiten Sorgen zu machen. Für QA-Fachleute ist es schwierig, sich vor der Veröffentlichung eines neuen Produkts keine Sorgen zu machen oder sich für die Ergebnisse verantwortlich zu fühlen. Aber wie in Episode II mit Parveen musst du manchmal einfach „es loslassen, es loslassen“ und nicht „cool bleiben“.“
Jonathon Wright, Gastgeber des Podcasts Der QA-Leiter
„Als jemand, der während seiner gesamten beruflichen Laufbahn mit Angstzuständen umgegangen ist, habe ich zwar einige Schwierigkeiten und Herausforderungen erlebt, bin aber jedes Mal gestärkt und in einer besseren Position daraus hervorgegangen, um meine Angst besser zu bewältigen – und habe jedes Mal mehr über mich selbst gelernt. Die Branche zieht Menschen an, die sich auf unterschiedlichen Stufen des Spektrums befinden (mich selbst eingeschlossen). Die talentiertesten Menschen, mit denen ich arbeiten durfte, litten jedoch an psychischen Erkrankungen. Deshalb betrachte ich meine psychische Erkrankung als eine Superkraft!“
Wie Jonathon betont hat, kannst du mit etwas Glück und der richtigen Einstellung einen stressigen Beruf in einen erfüllenden verwandeln. Ich möchte dich dazu ermutigen, die Perspektive einzunehmen, die das Konzept eines Burnout-Systems bietet. Lass deine Angst los und bewahre Ruhe. Blicke dann über Gebote, Prozesse und Werkzeuge hinaus. Konzentriere dich auf das, was wirklich zählt: wie du und deine Teamkollegen euch gegenseitig dabei helft, großartige Produkte zu entwickeln.
