Visualizing Quality: End-to-End-Tests sichtbar machen – Erkenntnisse aus „Visualizing Quality“ von Armin Hutzler (NETCONOMY)

Warum Sichtbarkeit über Qualität entscheidet

Wer End-to-End-Tests (E2E) ernst nimmt, erkennt schnell: Stabilität ist das eine – Sichtbarkeit das andere. In seinem Talk „Visualizing Quality“ führt uns Armin Hutzler (NETCONOMY) durch beide Dimensionen. Als Frontend-Entwickler hat er mehrere Monate intensiv an E2E-Tests gearbeitet, Best Practices zusammengetragen und eine schlanke, wirksame Pipeline inklusive Dashboards aufgebaut, die Testergebnisse greifbar machen. Wir von DevJobs.at haben zugehört – und vor allem zugesehen: Wie man E2E-Qualität nicht nur absichert, sondern sichtbar macht.

Der Leitgedanke zieht sich durch den ganzen Vortrag: Wenn E2E-Tests reale Nutzerpfade abbilden, dann brauchen Teams auch reale, direkte Antworten auf Fragen wie: Laufen die Tests heute stabil? Wo sind sie gebrochen? Seit wann? Sind sie flaky? Wer das nur in CI-Logs versteckt, verspielt wertvolles Potenzial – fachlich wie organisatorisch.

E2E im Kontext: Vom Testpyramiden-Grundsatz zur Checkout-Realität

Armin beginnt bei den Basics und erinnert an die Testpyramide:

• Unit-Tests prüfen Komponenten isoliert.
• Integrationstests prüfen das Zusammenspiel mehrerer Komponenten.
• End-to-End-Tests testen die komplette Anwendung inklusive externer Services – sie klicken, navigieren und warten so, wie es ein echter Mensch tun würde.

Im E‑Commerce-Kontext ist das Paradebeispiel klar: der Checkout. Ein E2E-Test läuft durch vom „Produkt in den Warenkorb“ bis hin zum erfolgreichen Abschluss der Bestellung. Genau diese End-to-End-Kette sichert, dass alle Zahnräder ineinandergreifen.

Als gängige Frameworks nennt Armin Selenium, Cypress und Playwright. Wichtig ist weniger die Tool-Frage als die Zielrichtung: E2E-Tests bilden echte Workflows ab und sollen als Frühwarnsystem dienen.

Warum ein stabiles E2E-Setup zählt

Armin benennt die Kernnutzen einer stabilen E2E-Suite:

• Verlässliche Codebasis: Läuft die Suite regelmäßig und konstant durch, steigt das Vertrauen in die Funktionalität.
• Frühe Bug-Detektion: Ein täglicher Lauf deckt auf, was der letzte Merge verändert hat.
• Mut zur Veränderung: Teams können refactoren – die Pipeline bestätigt, ob alles Wesentliche weiterhin funktioniert.
• Release-Sicherheit: Qualitätssicherung nutzt E2E für Regressionstests.
• Kostenvorteile: Früher finden, früher fixen – spart Zeit in QA und vermeidet späte, teure Fehlerkorrekturen.

Diese Vorteile sind nicht abstrakt. Sie zeigen sich konkret im Alltag: Wer morgens nicht von roten Pipelines überrascht wird, kann seinen Arbeitstag verlässlich planen.

Die Schattenseiten: Warum E2E-Tests anspruchsvoll bleiben

Armin spart die Nachteile nicht aus:

• Schreibaufwand: E2E-Tests dauern länger in der Implementierung als Unit-Tests.
• Flakiness: Ein Test fällt heute durch, morgen läuft er. Unzuverlässigkeit schafft zusätzliches Rauschen.
• Wartung: Mit jeder UI-Änderung müssen Tests nachgezogen werden.
• Laufzeit: Während die Unit-Suite in etwa fünf Minuten durch ist, dauern E2E-Läufe über 20 Minuten.
• Debugging-Komplexität: Viele bewegliche Teile machen Fehlersuche schwierig.

Die Quintessenz: E2E-Tests sind wertvoll – aber nicht wartungsfrei. Sie brauchen Sorgfalt in der Konstruktion und Disziplin im Betrieb.

Best Practices: Konsequent pragmatisch

Wie begegnet man den Problemen? Armin teilt einen kompakten, praxisnahen Katalog an Grundsätzen, die in Summe große Wirkung entfalten.

1) Integration in die CI/CD-Pipeline

Tests müssen automatisch und in einer definierten Umgebung laufen. Das sorgt für Konsistenz, Transparenz und frühe Signale. Ein „läuft bei mir lokal“ ist keine valide Metrik für Qualität.

2) Aktuelle Versionen von Test-Frameworks und Browsern

Nur wer up-to-date ist, profitiert von Bugfixes, Features und gewährleistet Kompatibilität zu den Browser-Versionen, die Benutzer tatsächlich nutzen. Regelmäßige Updates sind Wartung – und Risikosenkung zugleich.

3) Konsistente Testdaten

Prüfende Aussagen gelingen nur mit stabilen Ausgangsbedingungen. Armin nennt das Beispiel „Produkte“: Wenn Produktdaten zwischen Läufen variieren, wird das Ergebnis unzuverlässig. Konsistenz ist hier die Basis für aussagekräftige Vergleiche über Zeit.

4) Resiliente Selektoren: Datenattribute statt CSS-Klassen

UI ändert sich, Klassen- oder ID-Namen driftet. Armin empfiehlt dedizierte Attribute wie data-Test-IDs. Das macht Selektoren robuster und schafft ein bewusstes Signal in der Entwicklung: Wer an Elementen mit Test-IDs arbeitet, prüft die Auswirkungen auf E2E gleich mit.

5) Auto-Waiting statt expliziter Wartezeiten

Explizite Wartezeiten (z. B. „warte 2 Sekunden“) sind unpräzise und verschwenden Zeit, wenn Elemente früher bereit sind. Besser: Auto-Waiting mit Event- und Zustandsbezug, also „warte bis klickbar, aber maximal X Sekunden“. So beschleunigen sich Läufe ohne Stabilitätsverlust.

6) Synchronisation mit Netzwerk-Requests

Noch präziser ist das Koppeln an die tatsächlichen Datenflüsse. Beispiel: Bevor eine Produktdetailseite interaktiv ist, muss zuerst der entsprechende Backend-Request beantwortet sein. Der Test wartet auf genau diesen Request und fährt dann fort. Ergebnis: weniger Timing-Probleme, mehr Aussagekraft.

7) Nur Oberflächen testen, die man kontrolliert

Externe UIs sind ein bewegliches Ziel – ohne Einfluss auf Änderungen, Anti-Bot-Maßnahmen oder Stabilität. Wenn externe Dienste notwendig sind (z. B. Login), empfiehlt Armin die Nutzung der API. Das reduziert Laufzeit und Instabilität.

8) Fehlgeschlagene Tests gezielt erneut ausführen

Ein einmaliger „Retry“ fängt sporadische Hiccups ab. Wichtig: Das stabilisiert den Gesamteindruck, darf aber echte Flakiness nicht kaschieren. Wer wiederholt retried, ohne die Ursache zu finden, verschiebt das Problem nur nach hinten.

9) Nicht immer ist der Test schuld

Armin bringt ein prägnantes Beispiel: Layout-Shifts. Wenn etwas in der UI „hineinspringt“ und der Test – wie der Mensch – plötzlich daneben klickt, dann liegt der Fehler in der Anwendung. Die E2E-Suite macht Probleme sichtbar, sie verursacht sie nicht.

Diese Perspektive ist wichtig: E2E-Fehler sind oft Symptom – und liefern wertvolle Hinweise auf UX-Problemstellen.

Die Pain Points nach dem Setup: Sichtbarkeit und Vergleichbarkeit

Selbst mit Best Practices bleiben strukturelle Herausforderungen – genau hier setzt Armins Ansatz an.

• Begrenzte Sichtbarkeit: Läufe passieren „irgendwo in der Pipeline“. Viele Stakeholder – gerade aus QA – haben keine einfache Sicht auf Ergebnisse.
• Vergleich über Zeit ist mühsam: Um Flakiness zu erkennen, müsste man viele Pipelines einzeln öffnen, ZIPs herunterladen, XMLs extrahieren und durchforsten.
• „Seit wann ist es rot?“: Das Zurückklicken über viele Läufe, bis man die letzte grüne Pipeline findet, kostet Zeit – und Nerven.

Die Lösung: Testergebnisse dorthin bringen, wo Teams ohnehin kommunizieren – und so aufbereiten, dass Trends und Ausreißer sofort auffallen.

Schritt 1: Slack-Benachrichtigungen als täglicher Taktgeber

Nach jedem Testlauf schickt die CI/CD-Pipeline eine Nachricht in den Slack-Kanal des Teams. Die Vorteile:

• Sofortiger Überblick: „Ist alles grün oder muss jemand ran?“
• Ein Klick zur Pipeline: Ein Link macht den Sprung zum Detail unkompliziert.
• Tägliche Erinnerung: Ein Rhythmus, der Disziplin fördert. Wenn die Nachricht täglich kommt, etabliert sich das Prüfen als Gewohnheit.

Dieser kleine Baustein schafft eine Kultur der Aufmerksamkeit – ohne zusätzlichen manuellen Aufwand.

Schritt 2: Ein Dashboard, das Qualität über Zeit sichtbar macht

Das Herzstück von Armins Ansatz ist ein Dashboard, das E2E-Ergebnisse über mehrere Läufe transparent und vergleichbar macht. Die Architektur ist bewusst leichtgewichtig und greift auf etablierte Bausteine zurück:

• Aus der CI-Pipeline werden die Testergebnisse (XML) in ein Google Cloud Storage Bucket geschrieben.
• Ein Google Cloud Function (Go) wird durch das Bucket-Event automatisch getriggert, parst die XMLs und lädt die Daten in ein BigQuery-Data Warehouse.
• Aus BigQuery werden die Daten in Grafana visualisiert.

Warum BigQuery und nicht eine klassische Datenbank? Armin betont die Stärke bei Lesezugriffen. Ein Data Warehouse eignet sich ideal, wenn es vorrangig um Analyse, Aggregation und Abfragen über große Datenmengen geht – genau das trifft auf Testhistorien zu.

Drei Ebenen der Visualisierung: vom Lauf zur Einzelprobe

Das Dashboard ist in drei Blickwinkel gegliedert – jeweils mit Fokus auf schnelle Erkenntnisse und gezielte Drilldowns.

1) Run Overview:

• Oben: eine kompakte Visualisierung der letzten sieben Läufe mit erfolgreichem und fehlgeschlagenem Anteil.
• Dazu: eine Tabelle mit denselben Informationen, verlinkt zur Pipeline, plus Möglichkeit, auf einzelne Läufe zu drillen.
• Unten: Laufzeitentwicklung – Grundlage, um Optimierungspotenziale zu erkennen.

2) Details pro Testlauf:

• Sichtbar: Wie viele Tests liefen insgesamt? Wie viele erfolgreich, wie viele fehlgeschlagen?
• Liste aller fehlgeschlagenen Tests – ein Sprungbrett für die Ursachenanalyse.

3) Test-Result-Details je Testfall:

• Verlauf: „Wie oft ist dieser Test in der letzten Woche fehlgeschlagen?“
• Erkenntnis zu Flakiness: Wenn ein Test meist grün, aber manchmal rot ist, wird er als flaky identifizierbar.
• Tabelle am unteren Rand: Fehlergründe – die direkte Brücke zur Debugging-Praxis.

Der Wert entsteht durch die Kombination: Schnellüberblick, Drilldown, Ursache – alles in einer konsistenten Oberfläche.

Was das Dashboard konkret verbessert

Armin fasst die Vorteile zusammen – wir haben sie im Live-Kontext bestätigt gesehen:

• Tägliche Erinnerung durch Slack.
• Ein-Klick-Zugang aus der Benachrichtigung direkt ins Dashboard.
• Visueller Vergleich über Läufe: „Seit wann ist der Test rot?“, „Wie ändert sich die Laufzeit?“, „Welche Tests sind flaky?“
• Flaky-Tests werden sichtbar – damit bearbeitbar.

Kurz: Das Dashboard führt die Lebenszeichen der Test-Suite dort zusammen, wo sie Wirkung entfalten: im Teamrhythmus, im Review, in der täglichen Planung.

Was bleibt anspruchsvoll – und wie Teams es handhaben

Armin macht klar: Das Dashboard ist kein „Magic Bullet“. Es schafft Sichtbarkeit, löst aber keine Probleme ohne menschliche Aufmerksamkeit.

• Es braucht eine klare Verantwortlichkeit: Eine Person („Driver“) schaut idealerweise täglich drauf und informiert das Team bei Problemen.
• Pflege bleibt Teamarbeit: Alle sollten wissen, welche E2E-Tests existieren, um sie beim Implementieren neuer Features mitzupflegen.
• In Prozesse integrieren: Wenn Kolleginnen und Kollegen Features gegenseitig testen, sollte das Prüfen der E2E-Pipeline Teil des Rituals sein.

Diese Hinweise sind weniger Technik als Betriebskultur – aber sie entscheiden darüber, ob E2E-Tests tatsächlich ihren Schutzschirm ausspannen.

Praktische Leitlinien zum Mitnehmen

Basierend auf Armins Talk „Visualizing Quality“ ergibt sich ein konkreter Fahrplan für Teams, die ihre E2E-Tests stabilisieren und sichtbar machen wollen:

1) Test-Setup sauber in CI/CD integrieren und täglich laufen lassen.

2) Frameworks und Browser-Versionen aktuell halten.

3) Testdaten stabilisieren und versionieren.

4) Selektoren robust gestalten – data-Attribute verwenden.

5) Auto-Waiting nutzen, besser noch an Netzwerkereignisse koppeln.

6) Externe UIs meiden; falls nötig, APIs verwenden (z. B. für Login).

7) Einmaliges Retry bei Fehlschlag erlauben – echte Flakiness dennoch adressieren.

8) Fehlerbilder im Test ernst nehmen – sie weisen oft auf Probleme in der Anwendung hin (z. B. Layout-Shifts).

9) Slack-Benachrichtigung nach jedem Lauf etablieren.

10) Dashboard aufsetzen: Ergebnisse aus der Pipeline extrahieren, in ein Data Warehouse schreiben (z. B. BigQuery), mit Grafana visualisieren.

11) Verantwortlichkeit klären („Driver“), Team einbinden, E2E in Prozesse verankern.

Diese Schritte sind bewusst pragmatisch – wenig „Raketenwissenschaft“, aber in Summe ein großer Hebel.

Warum diese Architektur überzeugt

Die Stärke des gezeigten Ansatzes liegt in der Einfachheit:

• Events aus der CI-Pipeline sind ohnehin vorhanden – sie werden nur weiterverwendet.
• XML-Ergebnisse werden nicht „weggeschrieben“, sondern nutzbar gemacht.
• Der Einsatz von Google Cloud Storage, Cloud Functions und BigQuery nutzt saubere Triggers, serverlose Ausführung und performante Abfragen.
• Grafana als Visualisierung senkt die Eintrittshürde: Teams können schnell Diagramme, Verläufe und Drilldowns bauen, ohne ein BI-Großprojekt aufzusetzen.

So entsteht eine schlanke Daten-Pipeline, die genau das leistet, was im Alltag zählt: Antwortgeschwindigkeit erhöhen, Muster sichtbar machen, Entscheidungen beschleunigen.

Ein Wort zur Laufzeit und zum Debugging

Armin nennt klare Größenordnungen: Unit-Tests in etwa fünf Minuten, E2E-Läufe über 20 Minuten. Das ist kein Defizit, sondern inhärent – E2E testen Wege, nicht nur Funktionen. Mit Auto-Waiting, Synchronisation auf Requests und gezieltem Retry lässt sich die effektive Wartezeit dennoch reduzieren.

Beim Debugging helfen drei Bausteine aus dem Dashboard besonders:

• Der Sprung von Rot zu Grund: Drilldown aus dem Run Overview bis zum einzelnen Testfall.
• Verläufe über Zeit: Flakiness von „gefühlt“ zu „belegt“.
• Fehlergründe in Tabellenform: schnelle Hypothesenbildung für die Ursachenanalyse.

Diese Kombination unterstützt genau dort, wo E2E ansonsten weh tut: bei der Eingrenzung von Fehlern über viele beteiligte Komponenten hinweg.

Zitatwürdige Erinnerungen aus dem Talk

Einige Aussagen von Armin bleiben im Gedächtnis – wir geben sie hier sinngemäß wieder:

• E2E-Tests sind das Abbild realer Nutzerflüsse.
• Flaky bedeutet: heute rot, morgen grün – und umgekehrt.
• Explizite Wartezeiten kosten Zeit; Auto-Waiting spart, ohne Risiko einzugehen.
• „Testet nur, was ihr kontrolliert“ – externe UIs sind eine Fehlerquelle, APIs der pragmatische Ausweg.
• Manchmal ist nicht die Suite, sondern die Anwendung das Problem – Beispiel Layout-Shift.
• Sichtbarkeit ist ein Prozess: Slack erinnert, das Dashboard erklärt, das Team handelt.

Fazit: Qualität sichtbar machen – und damit steuerbar

„Visualizing Quality“ von Armin Hutzler (NETCONOMY) zeigt einen reifen, praxistauglichen Weg, E2E-Tests nicht nur zu bauen, sondern in den Arbeitsalltag zu integrieren. Die Kombination aus Best Practices, Slack-Benachrichtigung und einem schlanken Dashboard über BigQuery und Grafana liefert genau das, was Teams brauchen: Frühwarnung, Kontext und Handlungsfähigkeit.

Am Ende steht das, was Armin als Ziel formuliert: Vertrauen. Refactorings, die Pipeline bleibt grün, keine Alarmrufe am Morgen – und die Gewissheit, „nichts Wichtiges kaputt gemacht zu haben“. Sichtbarkeit ist hier kein „nice to have“, sondern der Unterschied zwischen gefühlter und belegter Qualität.

Session-Kontext

• Title: Visualizing Quality
• Speaker: Armin Hutzler
• Company: NETCONOMY

Wir nehmen aus dieser Session mit: Stabilität ist eine Seite von Qualität. Sichtbarkeit ist die andere. Wer beides zusammenführt, testet nicht nur – er entwickelt verlässlich.

• 

  

  Load Performance in Single Page Applications

  Christian Oberhamberger von NETCONOMY erläutert in seinem devjobs.at TechTalk die Dos and Don'ts von Load Performance in Single Page Applications.

  Jetzt ansehen