DevEx (Developer Experience) ist ein Ansatz, um zu messen und zu verbessern, wie Entwickler ihre tägliche Arbeit erleben. Einen greifbaren Zugang dazu bieten die vier DORA-Metriken: Bereitstellungshäufigkeit, Durchlaufzeit für Änderungen, Änderungsfehlerrate und mittlere Wiederherstellungszeit. Die Qualitätssicherung beeinflusst alle vier direkt, von der Testautomatisierung in der Pipeline über Entscheidungen zur Überdeckung bis zu gezielten Experimenten, die Wiederherstellungszeiten senken.
Das Wichtigste in Kürze
- Die Änderungsfehlerrate ist die DORA-Metrik, die am engsten mit der QA-Arbeit verbunden ist, denn Fehler vor der Produktion zu finden, ist der Kern dessen, was Tester tun.
- Eine langsame oder gemeinsam genutzte Testumgebung bremst alle vier DORA-Metriken zugleich; eine eigene, isolierte Testumgebung für jeden Entwickler löst Engpässe bei Durchlaufzeit, Bereitstellungshäufigkeit und Wiederherstellungszeit.
- Metriken ohne Kontext sind nur Zahlen: Welche Fehlerrate oder Bereitstellungshäufigkeit akzeptabel ist, hängt vom Risikoprofil und den geschäftlichen Prioritäten des jeweiligen Unternehmens ab, nicht von einem Branchenstandard.
- Änderungen als kleine Experimente mit festem Überprüfungszeitpunkt einzuführen, macht Teams bereit, sie auszuprobieren, weil ein gescheitertes Experiment kein Makel ist und einfach durch das nächste ersetzt wird.
- Wer in der QA lernt, die eigene Arbeit in DORA-Begriffen auszudrücken, macht den eigenen Beitrag für Product Owner und Fachbereiche sichtbar, die diese Sprache bereits sprechen.
Was DORA und SPACE messen
DORA und SPACE sind zwei Frameworks, mit denen sich messen lässt, wie Softwareteams liefern und wie Entwickler ihre Arbeit erleben. Die DORA-Metriken sind dabei der konkretere Teil. Beide Frameworks gehören zum größeren Thema Developer Experience, kurz DevEx.
Der Begriff DevEx geht auf ein wissenschaftliches Paper aus der Zeit um 2010 bis 2012 zurück. Es stellte eine bekannte Frage aus einem neuen Blickwinkel: Teams reden ständig über die User Experience der Menschen, die ihre Anwendungen nutzen, aber wie steht es um die Erfahrung derer, die die Software bauen? Aus dieser Frage entstand die Arbeit daran, das Erleben mit echten Metriken greifbar zu machen.
DORA steht für DevOps Research and Assessment. Die Initiative setzte früh den Standard, als fast jedes Team in Richtung DevOps und Team-Ownership unterwegs war. Später übernahm Google das Framework und machte die Metriken zum Kern seines jährlichen State of DevOps Report. Dieser Bericht ist bis heute der beste Einstieg, wenn du die Metriken aus erster Hand verstehen willst.
SPACE kam später und aus einer anderen Richtung, entwickelt von Microsoft, einer Universität und einem weiteren Unternehmen. Es steht nicht für ein einzelnes Wort. SPACE schaut stärker auf das subjektive Erleben: Wirst du unterstützt, hast du genug Mandat und Handlungsspielraum in deiner eigenen Arbeit? Das P in SPACE steht für Performance, und diese Dimension deckt sich weitgehend mit den greifbaren DORA-Metriken.
Die beiden Frameworks überschneiden sich stark. DORA ist das konkretere von beiden und deshalb der sinnvollere Einstieg für Tester, die Qualität messbar machen wollen.
Die vier DORA-Metriken im Überblick
DORA reduziert den Zustand der Softwareauslieferung auf vier Messgrößen: Bereitstellungshäufigkeit, Durchlaufzeit für Änderungen, Änderungsfehlerrate und mittlere Wiederherstellungszeit (MTTR).
Die Bereitstellungshäufigkeit fragt, wie schnell ein Team Änderungen ausliefern kann. Daran lässt sich über den Prozess drehen oder über das Tooling, also über CI/CD-Pipelines und Quality Gates. Fast immer findet sich etwas, das die Pipeline schneller oder klüger macht.
Die Durchlaufzeit für Änderungen misst, wie lange es von der Idee bis zu funktionierender Software in Produktion dauert. Oft überspringen Teams den Schritt, die Anforderungen sauber auszuarbeiten, und genau das verlängert später die Implementierung. Pair Programming, kontinuierliches Testen im Paar und testgetriebene Entwicklung verkürzen diese Strecke.
Die Änderungsfehlerrate liegt am nächsten an der Testarbeit, denn Fehler zu finden, ist das, was Tester tun. Sie zählt, wie oft Änderungen scheitern. Für sich genommen sagt die Zahl wenig. Ein Fehler ist eine Information, die du hast, weil jemand hingeschaut hat, so wie ein gefundener Bug noch ein Gespräch darüber braucht, ob er wichtig ist.
Die mittlere Wiederherstellungszeit misst, wie schnell ein Team nach einem Ausfall wieder einen funktionierenden Zustand erreicht. Wenn ein Team in Produktionskorrekturen versinkt, leiden diese Metrik und die Durchlaufzeit gleichzeitig.
Eine Metrik liefert Einsicht, kein Urteil
Eine Metrik ist nur eine Metrik. Sie schafft Transparenz, sie fällt kein Urteil.
Wenn du einen Bug findest, ist damit noch nicht entschieden, ob er wichtig ist. Dafür braucht es weiterhin eine Diskussion. Dasselbe gilt für eine Fehlerrate oder eine Bereitstellungshäufigkeit: Die Zahl taucht auf, weil du misst, aber was sie bedeutet, musst du für dein Produkt und dein Unternehmen festlegen.
Hier lauert eine bekannte Falle. Wer eine Messgröße belohnt, bringt Menschen dazu, die Messgröße mit kleinen Tricks zu optimieren, statt die eigentliche Arbeit zu verbessern. Der Kobra-Effekt ist das warnende Beispiel: Ein Kopfgeld auf Kobras führte dazu, dass Menschen Kobras züchteten. Bevor du einem Zielwert hinterherläufst, leg deshalb fest, was eine akzeptable Änderungsfehlerrate oder eine akzeptable Bereitstellungshäufigkeit für dich überhaupt ist.
Auch beim Tempo solltest du die Obergrenze bewusst wählen. Du könntest die Umgebung so vergolden, dass ein Star-Entwickler eine Idee in zehn Minuten in Produktion bringt. Die eigentliche Frage ist, ob deine Umgebung dafür sicher genug ist, ob du die Quality Gates und die Überdeckung hast, die dein Risikoprofil verlangt. Schneller ist nicht automatisch besser.
Wie Tester die DORA-Metriken beeinflussen
Tester haben direkten, messbaren Einfluss auf alle vier DORA-Metriken. Deshalb sind diese Frameworks ein natürlicher Ort für Qualitätsarbeit.
Testautomatisierung berührt jede der Metriken, jede auf ihre Weise. Wie deine Überdeckung aufgebaut ist, entscheidet darüber, wie schnell du sein kannst. Wenn du dich nur auf langsame UI-Tests stützt, rettet dich auch paralleles Testen nicht, denn eine Testumgebung hochzufahren, kann nie so schnell sein wie Unit-Tests, die im selben Zeitfenster laufen. Erst die richtige Balance über die Automatisierungspyramide hinweg bringt die Bereitstellungshäufigkeit nach oben.
Hier gewinnt ein Tester auch eine andere Art von Relevanz. Qualitätsarbeit ist oft schwer zu sehen, und Sichtbarkeit ist ein Dauerproblem der QA. DORA gibt dir eine Möglichkeit, Testen greifbar und messbar zu machen, in einer Sprache, die andere bereits respektieren, nicht zuletzt durch die Berichte von Google.
Schwieriger ist es, über Wert zu sprechen statt nur über Risiko. Der Bereich mit dem höchsten Risiko ist nicht immer der, den dein Unternehmen am meisten schätzt, also gibt es eine Abwägung. Mehrere Stimmen in der Branche drängen inzwischen auf wertbasiertes Testen: Was trägt Testen tatsächlich bei, statt nur, wo das Risiko liegt? Wenn die QA lernt, über Wert zu sprechen, bleibt sie relevant und sichtbar.
Wie ein DevEx-Coach mit einem Team arbeitet
Ein DevEx-Coach arbeitet eine Zeit lang im Team mit, liest gemeinsam mit den Leuten die Metriken und startet kleine Experimente, um bestimmte Werte zu verbessern. Ziel ist, die Arbeit wieder zu übergeben, nicht dauerhaft zu bleiben.
Umgesetzt wurde das bei rund zwölf bis dreizehn Entwicklungsteams in einer Organisation, gruppiert in Streams wie Frontend, Backend und Logistik. Die Coaches wurden quartalsweise zugeteilt. Das Muster war immer gleich: erst beobachten, fragen, wo es wehtut, dann in Workshops Änderungen erarbeiten. Menschen öffnen sich schnell, wenn jemand mit offener Hand kommt statt mit einer Deadline.
Die Experimente laufen in Zyklen von etwa vier bis sechs Wochen, je nachdem, was verändert wird. Am Ende stehen eine Retro und eine Übergabe, später ein Check-in. Der Rhythmus ist wichtig, weil Metriken Zeit brauchen, bis sich zeigt, ob eine Änderung geholfen hat.
Die Änderungen Experimente zu nennen, ist Absicht. Ein Experiment darf scheitern. Das senkt die Hürde, etwas Neues auszuprobieren, und hält das Team bei der Sache, weil niemand für ein garantiertes Ergebnis geradestehen muss.
Ein Experiment, das funktioniert hat
Ein webbasiertes Team war für das Webportal zuständig und hatte keine eigene Testumgebung. Alle testeten auf einer gemeinsamen Abnahmeumgebung. Wenn ein Team dort etwas kaputt machte, traf es alle, und was die anderen kaputt machten, traf dieses Team.
Die Lösung war einfach: Jeder Entwickler bekam eine persönliche, integrierte Testumgebung. So konnte das Team isoliert testen, Sicherheit gewinnen, bevor es auf die Abnahmeumgebung ging, und schneller werden. Durchlaufzeit und mittlere Wiederherstellungszeit verbesserten sich, weil ein einziges blockierendes Problem verschwunden war.
Wie ein Experiment nicht still versandet
Ehrlich gesagt schlafen Experimente ein, wenn sie nicht klein, zuordenbar und überprüfbar sind. Sobald der Coach geht, zieht die menschliche Natur das Team zurück in seine Sprints.
Halte die Portionen klein. Höchstens zwei Änderungen, am besten in zwei verschiedenen Bereichen oder auf zwei verschiedene Metriken ausgerichtet. Diese Trennung lässt dich nachvollziehen, welche Änderung tatsächlich geholfen hat. Wenn du mehrere Dinge gleichzeitig veränderst, weißt du nicht, was gewirkt hat.
Bewegt eine Änderung die Metrik nicht, obwohl das Team sie durchgehalten hat, dann nenn sie ein gescheitertes Experiment und geh zum nächsten. Das ist kein Rückschlag, so funktioniert die Methode.
Achte auf die kognitive Last des Teams. Ein Team mit einer langen Liste von Beschwerden kann nicht alle auf einmal angehen. Frag, welche einzelne Änderung gerade am meisten bewirken würde, halte die Einstiegshürde niedrig und lass die Karotte sichtbar, damit die Leute motiviert bleiben.
Und dann komm wieder. Der ehrliche Zyklus sieht so aus:
| Phase | Was passiert |
|---|---|
| Coach ist da | Beobachten, Workshops, ein oder zwei Experimente vereinbaren |
| Coach geht | Das Team kehrt zu seinen Sprints zurück, die Änderung beginnt zu bröckeln |
| Check-in (nach etwa drei Monaten) | Die Metriken zeigen, ob sie gehalten hat; falls nicht, noch einmal durchführen |
| Die Änderung bleibt | Nach einem zweiten Anlauf spürt das Team den Nutzen, und die Änderung setzt sich fest |
Wo du anfangen kannst
Fang bei der Quelle an und übertrage sie dann auf deine eigene Arbeit. Lies den State of DevOps Report von Google und versteh, was jede DORA-Metrik bedeutet, bevor du die Interpretationen anderer darüberlegst.
Ein guter erster Schritt ist, die DORA-Grundlagen mit den QA-Praktiken abzugleichen, die du ohnehin schon betreibst. Du machst heute schon Testarbeit. Die Aufgabe ist, sie mit einer Metrik zu verbinden, damit Entwickler, ein Product Owner oder sogar der CEO die Wirkung sehen. Das Argument lässt sich leicht übersetzen: Wenn eine Idee mit kürzerer Durchlaufzeit in Produktion kommt, ist das Unternehmen schneller und die Menschen darin sind zufriedener.
“Wenn wir in der QA lernen, über Wert zu sprechen, ist das für uns enorm wichtig, um relevant und sichtbar zu bleiben, denn genau das ist in der QA typischerweise ein Problem.”
(Martijn Goossens)
Erfahrene Tester können vieles davon selbst zuordnen. Wer neu im Testen ist, braucht klarere Orientierung. Deshalb lohnt es sich, vor dem Start eine Übersicht zu bauen, die DORA mit konkreten Testaktivitäten verbindet.
Häufig gestellte Fragen
Sollten Teams mit DORA oder SPACE beginnen, wenn sie die Entwicklererfahrung messen wollen?
DORA ist das konkretere der beiden und der nützlichere Einstiegspunkt, besonders für Tester, die die Qualität messbar erfassen wollen. Es fasst den Zustand der Bereitstellung in vier Kennzahlen zusammen: Bereitstellungshäufigkeit, Durchlaufzeit für Änderungen, Änderungsfehlerrate und mittlere Wiederherstellungszeit. SPACE, das von Microsoft gemeinsam mit einer Universität und einem weiteren Unternehmen entwickelt wurde, konzentriert sich eher auf die subjektive Erfahrung, auf Unterstützung, Befugnisse und Handlungsspielraum. Seine Leistungsdimensionen lassen sich eng mit den DORA-Metriken abgleichen.
Was treibt die Durchlaufzeit für Änderungen eigentlich in die Höhe?
Übersprungene Anforderungsarbeiten. Die Durchlaufzeit für Änderungen umfasst den Zeitraum von der Idee bis zur funktionsfähigen Software, die in der Produktion läuft, und Teams, die die Anforderungen nie richtig ausarbeiten, zahlen später mit einer längeren Implementierungszeit dafür. Pair-Programming, kontinuierlicher Test innerhalb des Paares und testgetriebene Entwicklung verkürzen diesen Zeitraum. Teams, die sich in Produktionskorrekturen verlieren, sehen, wie sowohl die Durchlaufzeit als auch die mittlere Wiederherstellungszeit darunter leiden.
Ist eine höhere Bereitstellungshäufigkeit immer ein Zeichen für ein gesundes Team?
Nein. Geschwindigkeit hat ihre Grenzen, und du solltest sie bewusst wählen. Du könntest eine Umgebung so aufwendig ausbauen, dass ein Star-Entwickler eine Idee in zehn Minuten in die Produktion bringt, aber die eigentliche Frage ist, ob diese Umgebung sicher genug ist: ob die Quality Gates und die Überdeckung zum Risikoprofil des Produkts passen. Schneller ist nicht automatisch besser.
Was läuft schief, wenn Metriken zu Zielvorgaben werden?
Die Leute fangen an, die Messung statt der Arbeit zu optimieren, meist mit kleinen, provisorischen Kniffen. Ein warnendes Beispiel ist der Kobra-Effekt, bei dem ein Kopfgeld auf Kobras dazu führte, dass Menschen Kobras züchteten. Bevor du einem Ziel hinterherjagst, definiere, was eine akzeptable Änderungsfehlerrate oder eine akzeptable Bereitstellungshäufigkeit für dein eigenes Produkt und dein Unternehmen bedeutet. Eine Metrik verschafft Transparenz, sie ist kein Urteil.
Warum behebt das parallele Ausführen von Tests eine langsame Pipeline nicht?
Weil die Art der Überdeckung die Geschwindigkeit bestimmt. Das Hochfahren einer Testumgebung kann niemals mit Unit-Tests mithalten, die im selben Fenster laufen. Daher bleibt eine Testsuite, die sich auf langsame UI-Tests stützt, langsam, egal, wie viel Parallelisierung du hinzufügst. Erst die richtige Balance über die gesamte Automatisierungspyramide hinweg sorgt für eine höhere Bereitstellungshäufigkeit.
Was kostet eine gemeinsam genutzte Testumgebung ein Entwicklungsteam?
Sie koppelt die Probleme aller Teams aneinander: Was ein Team kaputt macht, trifft alle, und was die anderen kaputt machen, trifft dieses Team. In einem Webportal-Team ohne eigene Umgebung fanden alle Tests in einer gemeinsam genutzten Abnahmetest-Umgebung statt. Indem jedem Entwickler eine persönliche integrierte Testumgebung zur Verfügung gestellt wurde, waren isolierte Tests und mehr Sicherheit möglich, bevor die Abnahmephase erreicht wurde. Sowohl die Durchlaufzeit für Änderungen als auch die mittlere Wiederherstellungszeit verbesserten sich.
Warum geraten Testprozessverbesserungen ins Stocken, sobald die externe Unterstützung endet?
Die menschliche Natur zieht ein Team direkt zurück in seine Sprints. Die Schlüssel sind Umfang und Zuordnung: höchstens zwei Änderungen gleichzeitig, idealerweise in verschiedenen Bereichen oder auf unterschiedliche Metriken ausgerichtet, damit du nachvollziehen kannst, welche davon geholfen hat. Frag dich, welche einzelne Änderung gerade am meisten helfen würde, halte die Einstiegshürde niedrig und schau dann etwa drei Monate später noch einmal nach. Wenn es nicht gehalten hat, probier es noch einmal.
