RUBICON IT GmbH

Etablierte Firma

Capture Screenshots with Playwright & SpecFlow

Hannes Etl von RUBICON IT spricht in seinem devjobs.at TechTalk über die Aufgabe, mit Playwright und SpecFlow eine große Zahl an Screenshots automatisiert zu erstellen und zu verwalten.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In Capture Screenshots with Playwright & SpecFlow zeigt Hannes Etl (RUBICON IT GmbH), wie sein Team die Erstellung hunderter Doku-Screenshots für das Produkt Document Partner mit Playwright und SpecFlow automatisiert. Er stellt eine Drei-Schichten-Architektur vor (Gherkin-Feature-Files, C#-Step-Definitions und Page Objects via CSS/XPath), erläutert das kinderleichte Setup mit C#-Projekt, Dependencies und PowerShell-Browser-Install, Auto-Waiting in Playwright, SpecFlow-Hooks sowie den Bildvergleich mit Pixelmatch samt Threshold; das Beispiel-Szenario vergibt Admin-Rechte im Repository Manager und erzeugt anschließend den Screenshot. Das Ergebnis sind verständliche, wartbare Szenarien und deutlich schnellere, stabilere Läufe (522 Screenshots pro Sprache, rund 109 Feature-Files, fast 400 Szenarien; Laufzeit von ca. 23 auf 12 Minuten), was sich direkt für dokumentationsrelevante Screenshots übernehmen lässt.

Automatisierte Screenshots für Benutzerhandbücher mit Playwright und SpecFlow: Ein Praxisbericht aus „Capture Screenshots with Playwright & SpecFlow“ (Hannes Etl, RUBICON IT GmbH)

Warum Screenshots plötzlich zum Skalierungsproblem werden

Wer technische Dokumentation in Produktqualität liefert, kennt den Schmerz: Screenshots sind unverzichtbar – und zugleich einer der aufwendigsten Bestandteile einer Dokumentationspipeline. In der Session „Capture Screenshots with Playwright & SpecFlow“ von Hannes Etl (RUBICON IT GmbH) wurde sehr klar, warum dieses Thema alles andere als eine Nebensächlichkeit ist.

RUBICON entwickelt mehrere Softwareprodukte. Eines davon ist „Document Partner“, mit dem es um Dokumente geht – von der Erstellung und Verteilung bis zur elektronischen Signatur. Unterstützt werden diverse Formate, angefangen bei klassischen Office-Formaten (Word, Excel, PowerPoint) über PDF bis hin zu PDF/A. Für ein solches Produkt braucht es ein umfangreiches Benutzerhandbuch. Dieses Handbuch umfasst inzwischen rund 500 Seiten – mit ungefähr ebenso vielen Screenshots. Und das ist nur eine Sprache. Insgesamt werden zwei Sprachen (Deutsch und Englisch) gepflegt. Summiert bedeutet das etwa 1.000 Seiten und 1.000 Screenshots.

Jede:r, der oder die schon einmal Dokumentationen in dieser Größenordnung betreut hat, weiß: Manuelles Screenshot-Management skaliert nicht. Es braucht Automatisierung – idealerweise so, dass sie robust ist, mit der Dokumentation mitwächst und auch von Teams genutzt werden kann, die nicht täglich programmieren. RUBICON hatte eine solche Lösung seit Langem im Einsatz, aber die bisherige Technologie wurde nicht mehr weiter gewartet. Der Anlass für einen klaren Schnitt: eine neue, zukunftsfähige Implementierung.

Die Entscheidung: Playwright und SpecFlow kombinieren – ein Web-Testing-Framework (von Microsoft) trifft auf ein BDD-Framework (Behavior-Driven Development). Hannes Etl brachte es auf den Punkt: Die beiden Technologien wurden „miteinander verheiratet“ – und das Ergebnis ermöglicht es, Screenshot-Szenarien in einer nicht-technischen Sprache zu formulieren. Das eröffnet die Mitarbeit auch für Kolleg:innen, die weniger programmieraffin sind, etwa aus Support oder Technical Writing.

Die Ausgangslage: „Document Partner“ und der Repository Manager

„Document Partner“ besteht aus mehreren Komponenten. Eine davon ist eine Web-Anwendung, der „Repository Manager“. Diese Anwendung dient dazu, Dokumente bzw. Dokumentvorlagen zu verwalten. Das Beispiel aus der Session war bewusst alltagsnah gewählt: Einem Benutzer werden Administrator-Rechte zugewiesen. In der Oberfläche bedeutet das, einen Benutzer zu selektieren, eine Checkbox zu aktivieren – und anschließend einen Screenshot zu erzeugen. Genau diese Abfolge – also ein reales Bedienmuster – wird mit der neuen Lösung als Szenario beschrieben und automatisiert umgesetzt.

Die Stärke des Ansatzes liegt darin, dass solche Szenarien in einer klaren, lesbaren, standardisierten Syntax erfasst werden – so, dass sie fachlich beschrieben und technisch ausgeführt werden können.

Die Architektur: Drei Schichten, klare Verantwortlichkeiten

RUBICON setzt für die Automatisierung auf eine Drei-Schicht-Architektur:

Feature-Schicht: Hier entstehen die Szenarien in einer nicht-technischen Sprache. Verwendet wird die Gherkin-Syntax mit den Schlüsselwörtern Given, When, Then. Diese Ebene ist bewusst leserlich und kompakt gehalten – das ist zentral, damit auch Nicht-Programmierer:innen Szenarien schreiben oder reviewen können.
Step-Definition-Schicht: Hier erfolgt das Mapping der Sätze aus der Feature-Schicht auf Code. Zum Einsatz kommt C#. Formulierte Sätze werden über Attribute den jeweiligen Methoden zugeordnet. So entsteht die Verbindung zwischen der fachlichen Beschreibung und der technischen Ausführung.
Page-Object-Schicht: Hier wird auf konkrete Web-Elemente zugegriffen – Buttons, Labels, Dropdowns usw. Selektiert wird in der Regel über CSS-Selektoren (Klassen, IDs), alternativ kann XPath eingesetzt werden. Diese Schicht entspricht dem Page-Object-Pattern und kapselt die UI-Details.

Die Trennung ist bewusst: oben menschenlesbare Szenarien, in der Mitte die Übersetzung in C#-Methoden, unten die robuste Kapselung der UI-Lokatoren. Das sorgt für klare Zuständigkeiten, erleichtert Wartung und ermöglicht verlässliche Wiederverwendung.

BDD in der Praxis: Szenarien, die Fachlichkeit und Technik verbinden

Die Feature-Schicht nutzt Gherkin. Das Prinzip ist bekannt: Given (Ausgangszustand), When (Aktion), Then (Erwartung). Hannes Etl zeigte exemplarisch, wie ein Feature-File aussehen kann. Wichtig ist weniger die konkrete Zeile als der Eindruck: Die Skripte sind „de facto wirklich sehr leserlich“ und „sehr kompakt“. Genau darum geht es bei BDD – Spezifikation, Test und Dokumentation rücken zusammen. In diesem Fall dient die BDD-Beschreibung dazu, reproduzierbare Screenshots zu erzeugen, die für ein Handbuch gebraucht werden.

Warum ist das so wertvoll? Weil damit Kolleg:innen aus Support und Technical Writing Situationen in Words ausdrücken können, die später als Automatisierung in einem Browser ausgeführt werden. Das reduziert Reibungsverluste: fachliche Beschreibung und technische Umsetzung decken sich durch die Step-Definitionen.

Step-Definitionen: Die Brücke von Gherkin zu C#

Die Step-Definition-Schicht bildet einzelne Sätze auf C#-Methoden ab. Diese Zuordnung erfolgt über Attribute, die direkt oberhalb der Methodenköpfe stehen. Enthält ein Feature-Satz eine Formulierung, die in einem Attribut hinterlegt ist, wird beim Ausführen der passende Methodenrumpf aufgerufen.

Der Effekt: Fachliche Sätze sind nicht bloß Prosa, sondern ausführbare Beschreibungen. Dadurch bekommt die Feature-Schicht echte Traktion – sie ist kein Beiwerk, sondern der Startpunkt des automatisierten Ablaufs.

Page Objects: Wo UI-Elemente leben

Die Page-Object-Schicht kapselt die technischen Details des Benutzer-Interfaces. Gesucht und angesprochen werden Elemente über CSS-Selektoren (Klassen, IDs), alternativ über XPath. Dadurch bleiben die Feature-Skripte frei von Selektoren, und die Step-Definitionen fokussieren auf die fachlichen Schritte. Ändert sich die UI, müssen nur die Page Objects angepasst werden – die Feature-Szenarien bleiben im Idealfall unverändert lesbar.

Diese Kapselung folgt dem etablierten Page-Object-Pattern. In der Praxis sorgt sie für Stabilität und reduziert die Kopplung zwischen fachlichen Beschreibungen und technischen Details der Oberfläche.

Setup und Installation: „Kinderleicht“ bis zum ersten Szenario

Ein Vorteil des Stacks, den Hannes Etl hervorhob, ist der Weg vom leeren Projekt bis zum ersten laufenden Szenario. Die Schritte:

Ein C#-Projekt anlegen – als SpecFlow- oder NUnit-Projekt.
Einige Dependencies hinzufügen – „drei oder vier“.
Ein PowerShell-Skript ausführen, um die benötigten Browser zu installieren (notwendig, um Screenshots von einer Web-Anwendung machen zu können).
Die drei Schichten (Feature, Step-Definition, Page Object) anlegen.
Szenarien im Visual Studio Test Explorer ausführen – analog zu Unit Tests.

Die zentrale Botschaft: Die Grundinstallation ist „kinderleicht“. Sobald die Browser installiert sind, können die Feature-Files geschrieben, die Step-Definitionen ergänzt und die Page Objects mit den UI-Elementen gefüllt werden. Dann lässt sich die Pipeline einfach über den Test Explorer starten.

Playwright im Einsatz: Auto-Waiting gegen Timing-Issues

Web-Tests kämpfen notorisch mit Timing-Problemen: Ein Button ist noch nicht sichtbar, ein Element noch nicht interaktiv – und schon bricht die Automatisierung. Playwright bringt hier ein zentrales Feature „out of the box“ mit: Auto-Waiting.

Hannes Etl betonte, dass sich Teams damit um viele Timing-Fragen schlicht nicht mehr kümmern müssen. In seinen Worten: Das funktioniert standardmäßig – „zugegebenermaßen, in 95 % der Fälle“. Einzelfälle können Nachkorrekturen erfordern, aber die breite Masse der Interaktionen profitiert von automatischen Warte-Mechanismen. Für stabiles Screenshotting – also für zuverlässige, reproduzierbare UI-Zustände – ist das ein erheblicher Gewinn.

SpecFlow Hooks: Gezielt Code zu definierten Zeitpunkten ausführen

Ein zweiter Baustein, den die Session hervorhob, sind Hooks. Damit lassen sich Codefragmente an definierten Zeitpunkten ausführen. Ein typischer Anwendungsfall ist das Einspielen von Test- oder Demodaten. In SpecFlow wird dafür ebenfalls mit Attributen gearbeitet – zum Beispiel, um einen Codeabschnitt „vor einem Feature einmalig“ laufen zu lassen.

Für Screenshot-Prozesse ist das relevant, weil sich so Vorbedingungen herstellen lassen: Daten, Benutzerrechte, initiale Konfigurationen – alles, was ein Szenario konsistent benötigt, kann an den richtigen Lifecycle-Hook gebunden werden. So entsteht eine robuste Ausführungsumgebung, die die Stabilität der Screenshots weiter erhöht.

Qualitätssicherung der Bilder: Referenzvergleich mit Pixelmatch

Ein Screenshot allein sagt noch nichts darüber aus, ob er „richtig“ ist. In der Session wurde daher ein visueller Vergleich erwähnt: Die erzeugten Screenshots werden mit Referenzbildern verglichen. Zum Einsatz kommt die Pixelmatch-Library. Deren Vorteil: ein konfigurierbarer Threshold-Parameter. Über einen Prozentsatz wird definiert, ab wann zwei Bilder als „gleich“ gelten.

Diese Schwelle ist in der Praxis entscheidend, um geringfügige Unterschiede (z. B. minimale Rendering-Variationen) zu tolerieren, ohne echte Abweichungen zu übersehen. Für Dokumentationen, die konsistent über Sprachen und Versionen hinweg sein müssen, ist dieser Pixelvergleich ein Schlüsselfaktor, um Verlässlichkeit zu schaffen.

Ein konkretes UI-Muster: Rechte vergeben und Screenshot erstellen

Das in der Session skizzierte Beispiel war bewusst einfach – und gerade deshalb aussagekräftig: In der Web-Anwendung „Repository Manager“ wird einem Benutzer Administrator-Rechte vergeben. Bedienungsschritte:

Benutzer auswählen.
Checkbox zur Rechtevergabe aktivieren.
Screenshot aufnehmen.

In der Feature-Schicht landet dieses Muster als lesbares Szenario. Die Step-Definition ordnet den Sätzen die C#-Methoden zu, die die UI-Steps ausführen. Die Page Objects identifizieren die betreffenden UI-Elemente. Das Ergebnis sind reproduzierbare Screenshots, die den Zustand nach der Rechtevergabe zeigen – in allen benötigten Sprachen.

Laufzeiten, Umfang, Skalierung: Zahlen, die überzeugen

Zum Abschluss teilte Hannes Etl konkrete Kennzahlen der laufenden Lösung:

Rund 500 Screenshots pro Sprache – exakt 522.
Zwei Sprachen (Deutsch und Englisch).
109 Feature-Files.
Fast 400 Szenarien.
Laufzeit halbiert: von knapp 23 Minuten auf ungefähr 12 Minuten.

Gerade die Laufzeitverbesserung ist für Dokumentationspipelines relevant. Kürzere Durchläufe bedeuten schnellere Iteration, häufigere Aktualisierungsmöglichkeiten und geringere Reibung zwischen Entwicklung, QA und Dokumentation.

Was wir als Engineering-Praxis mitnehmen

Aus der Session lassen sich klare Handlungsprinzipien ableiten – alle eng an das Gezeigte und Gesagte angelehnt:

Szenarien in Alltagssprache formulieren: Die Feature-Schicht mit Gherkin schafft Lesbarkeit und Zugänglichkeit. Das ist kein Nice-to-have, sondern der Hebel, um Nicht-Programmierer:innen einzubinden.
Klare Architektur mit Page Objects: Die Trennung hilft bei Wartung und sorgt dafür, dass UI-Änderungen nicht die fachlichen Szenarien zerreißen. CSS-Selektoren (Klassen, IDs) als Standard, XPath als Alternative – so bleibt der Zugriff auf Elemente konsistent.
Stabilität zuerst denken: Auto-Waiting in Playwright reduziert Timing-Issues „out of the box“. In den wenigen Ausnahmen lässt sich nachsteuern, aber die Default-Stabilität ist ein Gewinn für jede Web-Automatisierung.
Konsistenz herstellen: Mit SpecFlow Hooks können Test- oder Demo-Daten gezielt geladen werden – etwa per „BeforeFeature“. So entsteht die kontrollierte Ausgangslage, auf der reproduzierbare Screenshots basieren.
Visuelle Validierung nicht vergessen: Pixelmatch mit Threshold schafft den belastbaren Nachweis, dass ein Bild dem Referenzzustand entspricht – tolerant gegenüber kleineren Unterschieden, streng genug für echte Abweichungen.
Produktive Bedienung: Ausführung über den Visual Studio Test Explorer verhält sich „wie Unit Tests“. Das senkt die Einstiegshürden im Team und macht den Betrieb planbar.

Von der Idee zur laufenden Pipeline: Ein konsistenter Pfad

Die Stärke der gezeigten Lösung liegt nicht in Einzeltricks, sondern im Zusammenspiel:

Eine fachliche Beschreibungsebene, die wahrnehmbar lesbar ist.
Eine technische Übersetzungsebene, die präzise und wiederverwendbar bleibt.
Eine UI-Kapselung, die Stabilität schafft und Änderungen abfedert.
Ein Test-Framework, das Timing-Probleme proaktiv mindert.
Lifecycle-Hooks, die reproduzierbare Vorbedingungen herstellen.
Ein visueller Abgleich, der Qualität quantifizierbar macht.

Zusammen entsteht eine Pipeline, die Dokumentation auf Produktniveau mit vertretbarem Aufwand pflegt – über Sprachen hinweg, in hunderten Szenarien, mit messbaren Laufzeitvorteilen.

Fazit: Screenshots sind ein Engineering-Thema

„Screenshots“ mögen trivial klingen, doch in Summe mit 1.000 Seiten und 1.000 Bildern sind sie eine echte Engineering-Aufgabe. In „Capture Screenshots with Playwright & SpecFlow“ zeigte Hannes Etl (RUBICON IT GmbH), wie sich dieses Thema mit Playwright und SpecFlow strukturiert angehen lässt. Die Drei-Schicht-Architektur, Gherkin als lesbare Beschreibung, Step-Definitionen als technische Brücke, Page Objects als Kapselung, Auto-Waiting gegen Timing-Probleme, Hooks für Datenzustände und Pixelmatch für die Bildvalidierung – all das fügt sich zu einem schlüssigen Ganzen.

Die belegten Zahlen – 522 Screenshots pro Sprache, 109 Feature-Files, fast 400 Szenarien, Laufzeit von ca. 23 auf ca. 12 Minuten reduziert – unterstreichen die Praxistauglichkeit. Für Teams, die Benutzerhandbücher auf Produktniveau liefern müssen, ist dieser Weg ein belastbarer Blueprint. Der vielleicht wichtigste Punkt: Die Szenarien in nicht-technischer Sprache öffnen die Tür für Kolleg:innen jenseits des Codes. Genau dort liegen die Effizienzgewinne – in geteiltem Verständnis, klaren Rollen und einer Automatisierung, die die Dokumentation mit der gleichen Sorgfalt behandelt wie den Code.

Wer die Session gesehen hat, nimmt mit: Mit Playwright und SpecFlow wird Screenshot-Erzeugung nicht nur schneller, sondern auch verlässlicher und für breitere Teams zugänglich – und damit zu einem wiederholbaren, kontrollierbaren Baustein der gesamten Produktdokumentation.