Beiträge

Warum Testing die häufigste Retro-Beschwerde ist (und es nicht an flaky Tests liegt)

Stilisierte flache Illustration einer riesigen Lupe, die über einer Wand voller bunter Haftnotizen schwebt, wobei einige Notizen leuchten und kleine Figuren sie untersuchen
Matt Lewandowski

Matt Lewandowski

Zuletzt aktualisiert am 19/07/20267 Min. Lesezeit

Als wir Anfang dieses Monats eine Million Retro-Karten analysiert haben, überraschte ein Ergebnis alle: Testing und QA ist die mit Abstand häufigste Beschwerde in Software-Teams und taucht mehr als fünfmal so oft auf wie Kommunikation. Dieser Beitrag nimmt genau diesen Befund unter die Lupe. Worüber beschweren sich Teams konkret, wenn sie sich über Testing beschweren? Gleiche Methode wie beim letzten Mal: aggregierte Analyse von Retrospektiven, die auf Kollabe durchgeführt wurden, Spalten anhand ihrer Namen als positiv oder negativ klassifiziert, Themen per Keyword-Matching in Kategorien eingeteilt. Keine einzelne Karte wird zitiert oder ist identifizierbar, und da Keyword-Matching englischzentriert und konservativ ist, ist jede Zahl unten eine Untergrenze. Das ergibt 29.015 testingbezogene Beschwerdekarten von insgesamt 269.372 Beschwerden, geschrieben zwischen Oktober 2023 und Juli 2026.
29,015

Testing- & QA-Beschwerdekarten

1 in 5

Retros enthalten eine Testing-Beschwerde

0.9%

davon erwähnen flaky Tests

Was tatsächlich in einer Testing-Beschwerde steckt

Fast jede fünfte Retrospektive (18,6 %) enthält mindestens eine Testing-Beschwerde. So verteilen sich die 29.015 Karten nach Unterthema. Die Kategorien überlappen sich, da eine Karte sowohl QA als auch Automatisierung erwähnen kann:

QA als Funktion (Kapazität, Übergaben)

23.9%

Automatisierungs- und Abdeckungslücken

8.5%

Testumgebungen und Testdaten

8.3%

Bugs, die in die Produktion gelangen

4.9%

Regressionstests

4.3%

Langsame Tests und CI

3.0%

Keine Zeit zum Testen

1.6%

Aufwand für manuelles Testen

1.4%

Flaky Tests

0.9%

Die Schlagzeile: Die Lieblings-Testing-Beschwerde des Internets existiert in Retro-Räumen kaum. Engineering-Blogs und Konferenzvorträge sind voller Kriegsgeschichten über flaky Tests, doch nur 257 von 29.015 Testing-Beschwerden (0,9 %) erwähnen Flakiness, Instabilität oder sporadische Fehler. Worüber Teams tatsächlich schreiben, sind Menschen und Prozesse. Die mit Abstand größte Kategorie ist QA als Funktion: Fast ein Viertel aller Testing-Beschwerden erwähnt QA direkt. Und wenn wir uns ansehen, was neben dem Wort QA auftaucht, dreht sich das Muster um den Ablauf, nicht um Kompetenz: Der Zeitpunkt der Übergabe ("Arbeit erreicht QA zu spät im Sprint") liegt knapp vor der Kapazität ("Warten auf QA", "QA ist überlastet"), gefolgt von unklaren Anforderungen und Akzeptanzkriterien. Teams beschweren sich nicht über ihre Tester. Sie beschweren sich darüber, wie und wann die Arbeit bei ihnen ankommt.

Seltene Beschwerden bekommen die Stimmen

Das Volumen sagt dir, was häufig ist. Die Stimmen sagen dir, was wehtut. Über alle Beschwerdekarten hinweg liegt der Durchschnitt bei 0,65 Stimmen pro Karte, und die großen Testing-Kategorien liegen darunter: QA-Funktions-Karten bekommen im Schnitt 0,59 Stimmen, Automatisierung und Abdeckung 0,58. Nun schau dir die seltenen an:
  • Flaky Tests: 1,18 Stimmen pro Karte. Das seltenste Unterthema bekommt die meisten Stimmen, fast doppelt so viele wie der Durchschnitt. Wenn endlich jemand die Flaky-Test-Karte schreibt, steigt der ganze Raum mit ein.
  • Aufwand für manuelles Testen: 0,85. Wenige Karten, starke Zustimmung.
  • Bugs, die in die Produktion gelangen: 0,71. Über dem Durchschnitt, aus naheliegenden Gründen.
Das Muster spiegelt wider, was wir in der ursprünglichen Analyse bei Arbeitslast und technischen Schulden gefunden haben: Die Beschwerden, die Teams am häufigsten schreiben, und die Beschwerden, hinter denen sich Teams versammeln, sind zwei verschiedene Listen. Ein Moderator, der nur das Volumen liest, verbringt die Retro mit QA-Übergaben. Die Stimmen sagen, dass die eigentliche Energie des Raums dort ist, wo die Flaky-Test- und Manual-Regression-Karten liegen.

Teams loben Testing fast so oft, wie sie sich darüber beschweren

Testing ist keine verhasste Tätigkeit; es ist eine beobachtete. 23.056 positive Karten erwähnen ebenfalls Testing — auf jede fünf Testing-Beschwerden kommen vier Testing-Komplimente. Teams feiern Verbesserungen bei der Abdeckung, erfolgreiche Release-Tests und QA, die Dinge erwischt, bevor Kunden es tun. Kein anderes Thema in der Delivery-Pipeline wird in beide Richtungen so genau verfolgt.

Die KI-Ära hat noch nichts bewegt (bislang)

Wir hatten erwartet, dass Testing-Beschwerden zunehmen würden, während KI-Coding-Assistenten mehr Code durch denselben menschlichen Verifikationstrichter schieben. Die Daten sagen nein, oder zumindest noch nicht: Der Anteil von Testing an allen Beschwerdekarten liegt seit Anfang 2024 in jedem Quartal konstant zwischen 10 % und 12 % — also im gesamten Zeitraum, in dem KI-gestütztes Coding zum Mainstream wurde. Interessanterweise gilt dasselbe nicht für Code Review, den anderen menschlichen Kontrollpunkt in der Pipeline: Review-Beschwerden sind im selben Zeitfenster um rund 30 % gewachsen. Das haben wir separat in dem Code-Review-Engpass untersucht.

Was du am Dienstag damit anfängst

Flache Illustration eines Teams, das Haftnotizen aus einem chaotischen Stapel in drei ordentlich beschriftete Bahnen auf einem Board verschiebt, wobei eine Figur ein kleines Fähnchen hält Wenn Testing immer wieder auf deinem Retro-Board auftaucht, zeigen die Unterthemen-Daten, wo du zuerst hinschauen solltest:
  1. Behebe, wann die Arbeit bei QA ankommt, nicht QA selbst. Der Zeitpunkt der Übergabe ist das, was am häufigsten neben QA steht. Tester ins Refinement zu holen und das Testdesign parallel zur Entwicklung zu beginnen, greift die eigentliche Beschwerde an. Unser Leitfaden zum Schreiben von Akzeptanzkriterien deckt die Klarheits-Hälfte dieses Problems ab.
  2. Behandle die Flaky-Test-Karte als Alarm. Sie ist selten, und wenn sie auftaucht, stimmt der Raum für sie. Das ist das Profil eines Problems, das viel zu lange stillschweigend geduldet wurde. Gib ihr noch am selben Tag einen Verantwortlichen und ein Datum; Action Items mit einem Verantwortlichen werden 2,7-mal häufiger abgeschlossen.
  3. Lass Abdeckungs-Beschwerden nicht an Gewohnheit sterben. Automatisierungslücken werden ständig geschrieben und selten hochgevotet — das klassische Profil erlernter Hilflosigkeit. Wenn dieselbe Abdeckungs-Karte in drei Retros hintereinander aufgetaucht ist, war sie kein Feedback mehr, sondern ist zu einem Projekt geworden.
Wenn du sehen willst, wie dein eigenes Board im Vergleich abschneidet, findest du die vollständigen aggregierten Zahlen auf unserer Retrospektiven-Statistik-Seite, die quartalsweise aktualisiert wird.

QA-Kapazität und Übergaben. Fast 24 % der 29.015 analysierten Testing-Beschwerden erwähnen QA als Funktion, und die Worte drumherum drehen sich darum, dass Arbeit zu spät ankommt oder in der Warteschlange festhängt — nicht um die Tester selbst.

Viel seltener, als der Diskurs vermuten lässt: 0,9 % der Testing-Beschwerden. Aber sie ziehen 1,18 Stimmen pro Karte an, fast das Doppelte des Durchschnitts, was sie zum meistgevoteten Testing-Unterthema in unseren Daten macht.

Bislang nicht. Der Anteil von Testing an den Retro-Beschwerden liegt seit Anfang 2024 in jedem Quartal zwischen 10 % und 12 %. Code-Review-Beschwerden hingegen stiegen im selben Zeitraum um rund 30 %.

Aggregierte, anonymisierte Analyse von 1.081.076 Karten aus 87.719 Sprint-Retrospektiven, die zwischen Oktober 2023 und Juli 2026 auf Kollabe durchgeführt wurden. Spalten wurden nach Namen klassifiziert, Themen durch konservatives Keyword-Matching, und keine einzelne Karte wird zitiert oder ist identifizierbar. Abfrage vom 19. Juli 2026; die ursprüngliche Analyse nutzte einen Stand vom 14. Juli, daher sind ihre Gesamtzahlen etwas kleiner.