Tests, Qualitätssicherung und kontrollierte Veröffentlichung

Tests, Qualitätssicherung und Veröffentlichung

0:00 n8n hat seit Version 2.37 eine Review-Funktion: Sie reichen eine Version zur Freigabe ein, jemand sieht sie an, und erst dann geht sie live. Das klingt nach der Antwort auf alle Qualitätsfragen. Ist es aber nicht — und der Grund dafür ist der wichtigste Satz dieses Moduls: Ein Review prüft den Workflow. Es prüft nicht die Credentials, nicht die Einstellungen und nicht die Sub-Workflows.

0:23 Diese Lücke muss man kennen, sonst verlässt man sich auf eine Prüfung, die nur die halbe Miete ist. Dieses Modul handelt von der anderen Hälfte.

Tests, Qualitätssicherung und kontrollierte Veröffentlichung

0:32 Wir bleiben am dritten Tag und beim Thema Verlässlichkeit. Gestern ging es um Fehler, die passieren. Heute geht es darum, sie vorher zu finden. Wir beginnen mit einer Teststrategie — drei Arten von Fällen, von denen nur eine Freude macht. Dann Attrappen und Regressionstests. Danach Versionen, Vergleich und Review, mit der erwähnten Lücke. Und zum Schluss die Übergabe: Was gehört eigentlich dazu, damit jemand anders den Workflow betreiben kann?

Teststrategie für Workflow-Automatisierungen

1:00 Fangen wir mit der Strategie an. Ohne sie wird geprüft, was gerade zur Hand ist — und das ist fast immer der Fall, der ohnehin funktioniert. Eine Teststrategie legt fest, welche Fälle vor einer Veröffentlichung geprüft werden und woran sich ihr Bestehen erkennen lässt. Beides gehört zusammen: Ein Testfall ohne Bestehenskriterium ist nur ein Durchlauf.

1:21 Der Satz dahinter ist unbequem, aber richtig: Ohne Strategie prüft man den Fall, der ohnehin funktioniert. Das ist keine Nachlässigkeit, sondern menschlich — man baut ja gegen ein Beispiel, und dieses Beispiel liegt auf dem Tisch. Genau deshalb muss die Auswahl der Fälle eine bewusste Entscheidung sein und keine Nebenwirkung des Entwickelns.

1:41 Drei Arten, und die erste ist die langweiligste. Der Happy Path ist der erwartete Ablauf — vollständige Meldung, Portal erreichbar. Den haben Sie ohnehin getestet, sonst wären Sie nicht fertig geworden. Der Negativtest ist der abgewiesene Fall: Pflichtfeld fehlt, Anlage unbekannt. Hier zeigt sich, ob Ihre Prüfungen greifen. Und der Grenzfall ist der Rand des Erlaubten — null Treffer, fünftausend Treffer, ein Anhang mit sechzehn Megabyte.

2:08 Diese dritte Spalte zeigt Ihnen, dass die Beispiele aus unserem Seminar stammen: Jede Zahl darin ist eine Grenze, die wir in den letzten zwei Tagen besprochen haben. Vier Anforderungen. Getrennt von Produktionsdaten — auch dann, wenn es umständlicher ist; und es ist umständlicher, sonst würde es jeder tun. Reproduzierbar, damit derselbe Fall morgen dasselbe Ergebnis liefert.

2:31 Beschreibend benannt, damit der Zweck ohne Rückfrage erkennbar ist; „Test 3" sagt in einem halben Jahr niemandem etwas. Und angeheftet im Trigger, damit der Fall auf Knopfdruck wieder da ist — die Technik aus Modul zwei, hier als Testdatenverwaltung. Wenn Sie das konsequent tun, haben Sie nach einigen Wochen eine Sammlung von Fällen, die mehr wert ist als jede Dokumentation.

2:55 Der erste Punkt ist ein Datenschutzverstoß aus Bequemlichkeit: Getestet wird mit einem echten Kundendatensatz, weil er zur Hand war. Der zweite ist der Klassiker — der Negativtest fehlt, weil niemand einen kaputten Datensatz erzeugen wollte. Das ist zehn Minuten Arbeit und die halbe Testabdeckung. Der dritte kann richtig teuer werden: Die Testläufe schreiben in die Produktionssysteme; spätestens wenn die Testbestellung beim Lieferanten ankommt, wird das sichtbar.

3:21 Und der vierte ist die Zusammenfassung von gestern: Bestanden heißt grün, nicht fachlich richtig.

Verträge, Mocking und Regression

3:27 Jetzt zu den Attrappen — und zu einem Problem, das in n8n-Projekten unterschätzt wird: Ein aktualisierter Baustein kann sich anders verhalten, ohne dass Sie irgendetwas geändert haben. Vier Gründe, und Sie kennen die Technik bereits. Der fremde Dienst ist in der Testumgebung nicht verfügbar — das ist der häufigste. Sein Fehlerfall lässt sich sonst gar nicht herbeiführen; Sie können ja schlecht den Lieferanten bitten, kurz offline zu gehen.

3:53 Angeheftete Daten ersetzen den Aufruf, ohne den Ablauf zu ändern — das ist der entscheidende Punkt: Die Logik dahinter läuft ganz normal. Und der Grenzfall mit fünftausend Treffern entsteht am Schreibtisch statt im Betrieb. Sie schreiben die Daten, statt auf sie zu warten. Ein Regressionstest prüft, dass eine Änderung nichts kaputt gemacht hat, das vorher funktionierte.

4:15 In n8n gibt es dafür einen Anlass, den man aus der Softwareentwicklung so nicht kennt: Jeder Baustein- und Versionswechsel ist einer. Ein aktualisierter Baustein kann Felder anders benennen oder anders antworten — ohne dass sich Ihr Workflow geändert hat. Das ist der Unterschied zu einer Bibliothek, die Sie selbst versionieren: Hier aktualisiert die Plattform, und Ihre Workflows fahren mit.

4:37 Deshalb gehört ein Versionssprung behandelt wie eine Änderung am eigenen Code. Fünf Schritte. Stellen Sie die Liste der Workflows zusammen, die betroffene Bausteine verwenden. Legen Sie je Workflow die vorhandenen Testfälle bereit — falls Sie welche haben; wenn nicht, ist jetzt der Moment, sie anzulegen. Aktualisieren Sie auf einer Testinstanz, nicht in Produktion. Fahren Sie die Testfälle durch und vergleichen Sie die Ausgaben mit dem Vorzustand.

5:04 Und bewerten Sie Abweichungen, bevor die Produktion nachzieht. Der wichtigste Satz steht in der Fußzeile: Ohne festgehaltenen Vorzustand ist ein Vergleich nach dem Sprung nicht mehr möglich. Sie können dann nur noch raten, ob es vorher anders war. Der erste Punkt ist eine Zeitbombe: Die Attrappe bleibt nach dem Test stehen und läuft mit in Produktion. Dann liefert Ihr Workflow zuverlässig Testdaten an echte Kunden.

5:29 Der zweite ist ein Wissensproblem: Der Vertrag mit der Gegenseite steht nur im Kopf der Entwicklerin — und dieser Kopf wechselt irgendwann den Arbeitgeber. Der dritte ist Routine mit Risiko: Aktualisiert wird direkt in Produktion, weil es bisher gutging. Und der vierte ist keine Prüfung, sondern eine Hoffnung: Regression wird geprüft, indem man den Workflow ansieht.

Versionen vergleichen und reviewen

5:51 Jetzt zu den Versionen — und zur Review-Funktion, mit der ich dieses Modul eröffnet habe. Vier Augen sind in n8n eine Funktion geworden, nicht mehr nur ein Vorsatz. Mit einer wichtigen Einschränkung. n8n legt bei jedem Speichern eine neue Version an, ebenso beim Wiederherstellen einer alten und beim Pull aus einem Git-Repository.

6:12 Eine Ausnahme sollten Sie kennen: Änderungen an den Workflow-Einstellungen erzeugen keine neue Version. Das ist der erste Hinweis auf die Lücke, über die wir gleich sprechen. Und noch eine Unterscheidung, die für Verwirrung sorgt: Die Versionshistorie ist etwas anderes als die Ausführungsliste. Versionen sind Stände Ihres Workflows, Ausführungen sind Läufe. Beides hat ein eigenes Menü, und beides verwechselt man erstaunlich leicht.

6:38 Drei Stufen, und die erste ist eine Warnung: Ohne bezahlten Plan reicht die Historie vierundzwanzig Stunden zurück. Das genügt für „Ups, das wollte ich nicht" — nicht aber für „Wie sah das vor dem Release aus?". Cloud Pro bekommt fünf Tage, die vollständige Historie gibt es mit Enterprise. Und jetzt die Fußzeile, die für alle gilt: Benannte Versionen werden nie automatisch aufgeräumt.

7:01 Wenn Sie also einen Stand behalten wollen — vor einem größeren Umbau etwa —, geben Sie ihm einen Namen. Das ist der einzige Weg, einen Meilenstein dauerhaft zu sichern. Ein Workflow Review bindet eine gespeicherte Version an eine Freigabe. Statt zu veröffentlichen reichen Sie sie ein und weisen sie einer Person zu. Nach Zustimmung veröffentlicht n8n genau diese Version — und jetzt kommt ein Detail, das ich bemerkenswert finde: im Namen der einreichenden Person, nicht der zustimmenden.

7:30 Das heißt, in Veröffentlichungshistorie und Audit-Protokoll steht, wer die Änderung gebaut hat, nicht wer sie durchgewunken hat. Das ist eine bewusste Entscheidung für Verantwortlichkeit — und ein Argument, das Sie in Governance-Diskussionen brauchen können. Und hier ist die Lücke. Vier Dinge stehen ausdrücklich nicht im Review: die Workflow-Einstellungen — Zeitzone, Fehler-Workflow, Ausführungsreihenfolge.

7:54 Die verwendeten Credentials und die Variablen. Die Data Tables, auf die der Workflow zugreift. Und die aufgerufenen Sub-Workflows; jeder davon trägt sein eigenes Review, wenn überhaupt. Das Entscheidende: Diese Dinge wirken sofort in Produktion, auch während ein Review offen ist. Sie können also eine Version gewissenhaft prüfen lassen, und parallel ändert jemand die Credential, die sie benutzt. Das Review merkt davon nichts.

8:21 Der erste Punkt ist eine Verfügbarkeitsfrage: Reviews sind Enterprise, ab Version 2.37.0, und ein Admin muss sie erst freischalten. Prüfen Sie das, bevor Sie einen Prozess darauf aufbauen. Der zweite steht ebenfalls in der Dokumentation: Die Funktion ist im Preview-Status und sollte nicht als Produktionszusage gelten. Der dritte überrascht im Alltag: n8n verschickt keine Benachrichtigung — der Reviewer muss selbst in seine Liste sehen.

8:48 Und der vierte ist die Lücke von eben in Aktion: Während des Reviews wird eine Credential geändert und wirkt sofort.

Weitergeben und abnehmen

8:55 Zum Abschluss die Frage, an der sich zeigt, ob ein Workflow wirklich fertig ist: Kann ihn jemand anders übernehmen? Und dafür braucht es mehr als den Workflow selbst. Ein n8n Package bündelt Workflows in eine übertragbare Datei und bewegt sie zwischen Instanzen — über API oder Kommandozeile, samt Credential-Platzhaltern und einer Liste der Abhängigkeiten.

9:17 Auf diese beiden Zusätze kommt es an. Der Platzhalter sorgt dafür, dass Sie Zugangsdaten nicht mit exportieren — das ist die technische Absicherung gegen einen Fehler, den man sonst leicht macht. Und die Abhängigkeitsliste sagt Ihnen, was auf der Zielinstanz vorhanden sein muss. Denken Sie an eine Umzugskiste mit Packliste: Sie wissen beim Auspacken, was fehlt.

9:39 Vier Bestandteile. Der Workflow selbst und die Versionen, auf die er sich stützt. Die benötigten Credentials — als Platzhalter, nie als Inhalt. Die vorausgesetzten Data Tables, Variablen und Sub-Workflows; das ist genau die Liste, die das Review nicht abdeckt, und deshalb steht sie hier. Und die Akzeptanzkriterien, an denen der Betrieb den Erfolg misst — der Begriff aus dem letzten Modul, jetzt in seiner Anwendung.

10:04 Wenn der Betrieb nicht weiß, woran er einen guten Lauf erkennt, kann er auch nicht melden, dass etwas nicht stimmt. Fünf Schritte, und der zweite ist der ehrlichste Test, den es gibt. Listen Sie die Abhängigkeiten auf. Exportieren Sie den Workflow als Package und spielen Sie ihn auf einer zweiten Instanz ein — und zwar wirklich, nicht gedanklich.

10:25 Füllen Sie dort die Platzhalter und fahren Sie die Testfälle durch. Halten Sie Akzeptanzkriterien und Betriebshinweise schriftlich fest. Und schließen Sie die Übergabe an eine benannte Person ab, nicht an ein Team. Die Fußzeile bringt es auf den Punkt: Was beim Einspielen auf der zweiten Instanz fehlt, fehlt auch im Notfall — nur haben Sie es dann eiliger.

10:47 Der erste Punkt ist der häufigste Exportfehler: Exportiert wird der Workflow, aber nicht seine Sub-Workflows. Der zweite ist ein Sicherheitsproblem: Zugangsdaten landen im Export, weil der Weg über die Oberfläche bequemer war als das Package. Der dritte betrifft die Abnahme selbst: Geprüft wird die Technik, aber nicht die fachlichen Kriterien — dann ist die Abnahme ein Funktionstest und keine Abnahme.

11:10 Und der vierte ist eine Organisationsfrage mit Ansage: Der Betrieb erfährt vom neuen Workflow, als er das erste Mal scheitert.

Übung

11:18 Jetzt führen Sie eine kleine Änderung durch den vollständigen Qualitätsweg. Die Änderung selbst ist in fünf Minuten gebaut — es geht um alles, was davor und danach kommt. Der Störungs-Workflow von Kesselwerk soll eingehende Meldungen zusätzlich nach Dringlichkeit einordnen. Das ist absichtlich eine kleine Änderung: Sie soll Sie nicht beschäftigen, sie soll nur einen Anlass liefern.

11:40 Geübt wird der Weg von der Änderung bis zur veröffentlichten Version — mit Testfällen, Vergleich, Freigabe und der Liste dessen, was die Freigabe nicht abgedeckt hat. In echten Projekten ist genau dieser Weg der Unterschied zwischen einem Bastelbetrieb und einer belastbaren Automatisierung. Das Lernziel: eine Änderung so durch Test und Freigabe führen, dass der Stand vor und nach der Veröffentlichung belegbar ist. Belegbar — nicht erinnerbar.

12:05 Erfolgreich sind Sie, wenn drei Testfälle dokumentiert und bestanden sind, die Versionen verglichen wurden, die Freigabe erteilt ist und die Abhängigkeiten außerhalb des Reviews benannt sind. Dieser letzte Punkt ist der eigentliche Lerneffekt des Moduls. Wer früh fertig ist, benennt die freigegebene Version und begründet den Namen — dann haben Sie den Meilenstein gesichert, über den wir bei der Historie gesprochen haben.

12:29 Eine Stunde, fünf Schritte. Sichern Sie zuerst den aktuellen Stand als benannte Version — das ist Ihr Vergleichspunkt und zugleich Ihr Rückweg. Ergänzen Sie die Einordnung und legen Sie Testfälle für alle drei Arten an: Happy Path, Negativtest, Grenzfall. Öffnen Sie alte und neue Version nebeneinander und benennen Sie die Unterschiede. Reichen Sie die Version zur Freigabe ein und arbeiten Sie die Rückmeldung ein.

12:53 Und listen Sie zum Schluss auf, was das Review nicht abgedeckt hat — und prüfen Sie diese Punkte gesondert. Vier Fallen. Erstens: Der Vorzustand wird nicht gesichert, und der Vergleich ist danach nicht mehr möglich — der übersprungene erste Schritt. Zweitens: Die Testfälle entstehen nach der Änderung und prüfen genau sie; damit testen Sie Ihre Absicht, nicht das Verhalten.

13:16 Drittens: Das Review wird als vollständige Prüfung verstanden — die Lücke aus dem dritten Kapitel. Und viertens, ein Fall, der Sie in der Übung tatsächlich treffen wird: Es wird versucht zu veröffentlichen, während das Review noch offen ist. Das geht nicht, und das ist gut so.