DevEx (Developer Experience) ist ein Rahmenwerk zur Messung und Verbesserung der Erfahrungen, die Entwickler bei ihrer täglichen Arbeit machen. Es basiert auf vier DORA-Metriken: Einsatzhäufigkeit, Vorlaufzeit für Änderungen, Fehlerwirkung von Änderungen und Mean Time To Failure. Die Qualitätssicherung hat direkten Einfluss auf alle vier Kennzahlen. Die Testautomatisierung wirkt sich auf die Geschwindigkeit der Pipeline aus, Entscheidungen über die Überdeckung beeinflussen die Fehlerwirkung, und gezielte Testexperimente helfen den Teams, die Wiederherstellungszeit zu verkürzen und schneller zu liefern.
Das Wichtigste in Kürze
- Die Ausfallrate von Änderungen ist die DORA-Metrik, die am direktesten mit der QA-Arbeit verbunden ist, denn das Befunden von Fehlern vor der Produktion ist der Kern der Arbeit von Testern.
- Eine langsame oder gemeinsam genutzte Testumgebung blockiert alle vier DORA Metriken auf einmal; wenn jeder Entwickler eine isolierte persönliche Testumgebung hat, werden Engpässe bei der Änderungsvorlaufzeit, der Bereitstellungshäufigkeit und der mittleren Zeit bis zur Wiederherstellung behoben.
- Metriken ohne Kontext sind nur Zahlen: Eine akzeptable Fehlerwirkung oder Einsatzhäufigkeit hängt vom Risikoprofil und den geschäftlichen Prioritäten des jeweiligen Unternehmens ab, nicht von einem Branchenstandard.
- Änderungen als reibungsarme Experimente mit einem festen Review-Fenster einzuführen, erhöht die Bereitschaft der Teams, sie auszuprobieren, denn ein fehlgeschlagenes Experiment trägt kein Stigma und wird einfach durch das nächste ersetzt.
- QA-Fachleute, die lernen, ihre Arbeit in DORA-Begriffen auszudrücken, können ihren Beitrag für Product Owner und Stakeholder sichtbar machen, die diese Sprache bereits sprechen.
Was DORA und SPACE tatsächlich messen
DORA und SPACE sind zwei Rahmenwerke zur Messung der Leistung von Softwareteams und der Erfahrungen von Entwicklern mit ihrer Arbeit. Beide werden unter dem Begriff “Developer Experience” zusammengefasst, der oft mit DevEx abgekürzt wird.
Der Begriff DevEx geht auf eine wissenschaftliche Arbeit aus den Jahren 2010 bis 2012 zurück. Darin wurde eine bekannte Frage aufgeworfen: Teams sprechen ständig über das Benutzererlebnis für die Nutzer ihrer Anwendungen, aber was ist mit den Erfahrungen der Menschen, die die Software entwickeln? Ausgehend von dieser Frage wurde daran gearbeitet, sie mit echten Metriken zu versehen.
DORA steht für die DevOps Research Association. Sie setzte den frühen Standard in der Zeit, als sich fast jedes Team in Richtung DevOps und Teamverantwortung bewegte. Das Framework wurde von Google übernommen, das die Metriken in seinen jährlichen State of DevOps-Bericht aufnahm. Dieser Bericht ist immer noch der beste Ausgangspunkt, wenn du die Metriken von Grund auf verstehen willst.
SPACE wurde später von Microsoft, einer Universität und einem anderen Unternehmen entwickelt. Es steht nicht für ein einziges Wort. SPACE befasst sich mehr mit der gefühlten Erfahrung des Entwicklers: ob du unterstützt wirst, ob du genügend Mandat und Handlungsspielraum bei deiner eigenen Arbeit hast. Das P in SPACE steht für Leistung, und diese Leistungsdimension ist eng mit den greifbaren DORA-Metriken verknüpft.
Die beiden Rahmenwerke überschneiden sich stark. DORA ist der konkretere der beiden Rahmen und deshalb der nützlichere Einstieg für Tester, die Qualität messbar machen wollen.
Die vier DORA Metriken, im Klartext
DORA reduziert den Lieferzustand auf vier Messungen: Einsatzhäufigkeit, Vorlaufzeit für Änderungen, Ausfallrate bei Änderungen und Mean Time To Failure.
Die Bereitstellungshäufigkeit gibt an, wie schnell ein Team Änderungen bereitstellen kann. Du kannst dies sowohl prozess- als auch tooltechnisch durch CI/CD-Pipelines und Quality Gates beeinflussen. Es gibt fast immer etwas, um die Pipeline schneller oder intelligenter zu machen.
Die Durchlaufzeit für Änderungen zeigt, wie lange es dauert, von einer Idee zu einer funktionierenden Software in der Produktion zu kommen. Der Schritt, den Teams oft auslassen, ist die Ausarbeitung der Anforderungen, wodurch sich die Umsetzungszeit später verlängert. Paarweises Programmieren, kontinuierliches Testen in Paaren und testgetriebene Entwicklung verkürzen diese Zeitspanne.
Die Ausfallrate von Änderungen ist die Metrik, die der Arbeit von Testern am nächsten kommt, denn das Befunden von Fehlern ist die Aufgabe von Testern. Sie zählt, wie oft Änderungen fehlgeschlagen sind. Für sich allein genommen sagt die Zahl wenig aus. Eine Fehlerwirkung ist eine Information, die du jetzt hast, weil jemand nachgeschaut hat, genauso wie ein Fehler ein Befund ist, über den man noch reden muss, ob er wichtig ist.
Die mittlere Wiederherstellungszeit misst, wie schnell ein Team nach einer Störung wieder arbeitsfähig ist. Wenn Teams mit Produktionskorrekturen beschäftigt sind, leiden sowohl diese Metrik als auch die Vorlaufzeit darunter.
Eine Metrik ist eine Erkenntnis, kein Urteil
Eine Metrik ist nur eine Metrik. Sie gibt dir einen Einblick, kein Urteil.
Das Befunden eines Fehlers entscheidet nicht darüber, ob der Fehler wichtig ist. Das muss erst noch diskutiert werden. Das Gleiche gilt für eine Fehlerrate oder eine Einsatzhäufigkeit: Die Zahl erscheint, weil du sie misst, aber die Bedeutung muss für dein spezifisches Produkt und dein Unternehmen entschieden werden.
Hier gibt es eine bekannte Falle. Wenn du eine Messung belohnst, fangen die Leute an, die Messung mit kleinen, unbedeutenden Änderungen zu optimieren, anstatt die zugrunde liegende Arbeit zu verbessern. Der Kobra-Effekt, bei dem ein Kopfgeld auf Kobras dazu führte, dass die Menschen Kobras züchteten, ist ein abschreckendes Beispiel dafür. Bevor du also einem Ziel hinterherjagst, solltest du festlegen, was eine akzeptable Fehlerwirkung oder eine akzeptable Einsatzhäufigkeit für dich ist.
Die Geschwindigkeit hat eine Obergrenze, die du bewusst wählen solltest. Du kannst dein Setup so optimieren, dass ein Starentwickler eine Idee in zehn Minuten in die Produktion bringt. Die eigentliche Frage ist, ob deine Einrichtung dafür sicher genug ist, ob du die Quality Gates und die Überdeckung hast, die dein Risikoprofil verlangt. Schneller ist nicht automatisch besser.
Warum Tester in die DevEx-Konversation gehören
Tester haben einen direkten, messbaren Einfluss auf alle vier DORA Metriken, was diese Frameworks zu einer natürlichen Heimat für die Qualitätsarbeit macht.
Die Testautomatisierung wirkt sich auf jede dieser Metriken aus, jede auf ihre eigene Weise. Die Form deiner Überdeckung entscheidet darüber, wie schnell du vorankommen kannst. Wenn du dich nur auf langsame UI-Tests stützt, wird dich das parallele Testen nicht retten, denn das Aufsetzen einer Testumgebung kann niemals mit der Geschwindigkeit von Unit-Tests mithalten, die im selben Fenster laufen. Die richtige Balance in der Automatisierungspyramide ist das, was die Einsatzhäufigkeit freisetzt.
Das ist auch der Punkt, an dem ein Tester eine andere Art von Relevanz erlangt. Qualitätsarbeit ist oft schwer zu erkennen, und die Sichtbarkeit ist ein immer wiederkehrendes Problem für QA. DORA gibt dir die Möglichkeit, Testen greifbar und messbar zu machen, und zwar in einer Sprache, die bereits von anderen respektiert wird und die durch Googles Reporting populär geworden ist.
Die schwierigere Disziplin ist es, über den Wert zu sprechen, nicht nur über das Risiko. Der Bereich mit dem höchsten Risiko ist nicht immer der Bereich, den dein Unternehmen am meisten schätzt, also gilt es, einen Kompromiss zu finden. Viele Gespräche in der Praxis gehen in Richtung risikobasiertes Testen und fragen danach, was das Testen tatsächlich bringt, und nicht, wo das Risiko liegt. Wenn QA lernt, über Werte zu sprechen, bleibt sie relevant und sichtbar.
Wie ein DevEx-Coach mit einem Team arbeitet
Ein DevEx-Coach bettet sich in ein Team ein, liest gemeinsam mit ihm die Metriken und führt kleine Experimente durch, um bestimmte Zahlen zu verbessern. Das Ziel ist es, die Arbeit zurückzugeben, nicht ein fester Bestandteil des Teams zu werden.
Der Ansatz wurde in etwa zwölf bis dreizehn Entwicklungsteams in einem Unternehmen angewandt, die in verschiedene Bereiche wie Frontend, Backend und Logistik eingeteilt waren. Die Coaches wurden quartalsweise eingeteilt. Das Muster war einheitlich: Erst beobachten, fragen, was schmerzt, dann Veränderungen erarbeiten. Die Leute öffnen sich schnell, wenn jemand mit einer offenen Hand ankommt, anstatt mit einer Deadline.
Die Experimente laufen in Zyklen von etwa vier bis sechs Wochen, je nachdem, was verändert werden soll. Am Ende gibt es eine Rückschau und eine Übergabe, und später einen Check-in. Die Kadenz ist wichtig, denn Metriken brauchen Zeit, um sich zu bewegen, bevor man ablesen kann, ob eine Änderung geholfen hat.
Die Änderungen werden absichtlich als Experimente bezeichnet. Ein Experiment darf auch fehlgeschlagen sein. Das senkt die Reibung, etwas Neues auszuprobieren, und sorgt dafür, dass das Team bereit ist, sich zu engagieren, weil niemand ein garantiertes Ergebnis erwarten muss.
Ein konkretes Experiment, das funktioniert hat
Ein webbasiertes Team war Eigentümer des Webportals und hatte keine eigene Testumgebung. Alle testeten in einer gemeinsamen Testumgebung, so dass ein Fehler des einen Teams alle traf und der Fehler des anderen Teams sie selbst traf.
Die Lösung war einfach: Jeder Entwickler bekam eine eigene integrierte Testumgebung. So konnte das Team isoliert testen, Vertrauen aufbauen, bevor es an die Abnahme ging, und schneller vorankommen. Die Vorlaufzeit und die durchschnittliche Zeit bis zur Wiederherstellung wurden verbessert, weil ein einziges blockierendes Problem beseitigt wurde.
Wie man verhindert, dass ein Experiment still und leise stirbt
Die realistische Antwort ist, dass Experimente verblassen, wenn du sie nicht klein, zurechenbar und überprüfbar machst. Es liegt in der menschlichen Natur, dass ein Team in dem Moment, in dem der Coach geht, wieder in seine Sprints zurückkehrt.
Halte die Brocken klein. Höchstens zwei Änderungen, idealerweise in zwei verschiedenen Bereichen oder mit Blick auf zwei verschiedene Metriken. Durch diese Trennung kannst du nachvollziehen, welche Änderung tatsächlich geholfen hat. Wenn du mehrere Dinge auf einmal änderst, kannst du nicht sagen, was funktioniert hat.
Wenn eine Änderung die Metrik nicht verbessert, obwohl das Team daran festgehalten hat, nenne sie ein fehlgeschlagenes Experiment und mache mit dem nächsten weiter. Das ist kein Rückschlag, sondern die Methode hat ihre Aufgabe erfüllt.
Respektiere die kognitive Belastung des Teams. Ein Team, das mit einer langen Liste von Beschwerden konfrontiert ist, kann nicht auf alle reagieren. Frag dich, welche einzelne Veränderung im Moment am meisten bewirken würde, halte die Einstiegshürde niedrig und lass das Zuckerbrot sichtbar, damit die Leute motiviert bleiben.
Dann komm zurück. Der ehrliche Zyklus sieht so aus:
| Phase | Was passiert |
|---|---|
| Coach anwesend | Beobachtung, Workshop, Einigung auf ein oder zwei Experimente |
| Das Team kehrt zu den Sprints zurück und die Veränderung beginnt zu schleichen | |
| Check-in (ca. drei Monate) | Metrik zeigt, ob es gehalten hat; wenn nicht, wiederholen wir es |
| Nach einem zweiten Versuch spürt das Team den Nutzen und die Veränderung festigt sich |
Wo du anfangen kannst, wenn du dies anwenden willst
Beginne mit dem Quellcode und bilde dann deine eigene Arbeit darauf ab. Lies Googles State of DevOps Report und lerne, was die einzelnen DORA Metriken bedeuten, bevor du deine eigene Interpretation darüber legst.
Ein nützlicher erster Schritt ist es, die DORA-Grundlagen mit den QS-Praktiken abzugleichen, die du bereits anwendest. Die Aufgabe besteht darin, die Arbeit des Testens mit einer Metrik zu verbinden, damit die Entwickler, der Product Owner oder sogar der CEO die Wirkung sehen können. Die Botschaft ist klar: Wenn eine Idee mit einer kürzeren Vorlaufzeit für Änderungen in die Produktion gelangt, kommt das Unternehmen schneller voran und die Mitarbeiter/innen sind zufriedener.
Wenn wir lernen, als QA über Werte zu sprechen, ist es meiner Meinung nach super wichtig, dass wir relevant und sichtbar bleiben, denn das ist typischerweise ein Problem, wenn man in der QA arbeitet.
- Martijn Goossens
Erfahrene Tester können einen Großteil dieses Mappings selbst durchführen. Deshalb lohnt es sich, eine Übersicht zu erstellen, die DORA mit den konkreten Aktivitäten des Testens verknüpft, bevor du anfängst.
