Testen, Fehler, Übergabe

Fang vorne an, vor dem ersten Node. Jemand sagt: Der Workflow soll Bestellungen freigeben. Das ist ein Wunsch. Was daran ist prüfbar? Nichts. Freigeben ab welchem Betrag? Durch wen? Was passiert mit Anforderungen, die nirgends reinpassen?

Ein prüfbarer Auftrag besteht aus Akzeptanzkriterien: Sätze, die man beobachten kann. Nicht „soll gut funktionieren“, sondern „bei Eingabe X kommt Y raus“. Zu jedem Satz gehört ein Lauf, der ihn beweist. Und der Trick: Du schreibst die Kriterien, bevor du baust. Dann weißt du beim Bauen, wann du fertig bist, und beim Testen, wonach du suchst. Für deinen eigenen Workflow reichen zwei, drei solcher Sätze in einer Sticky Note oben links.

Aus den Kriterien wird eine Testmatrix. Das ist eine Tabelle, nichts Kompliziertes: ein Fall je Zeile, dazu Eingabe, erwarteter Weg und erwartete IT-Prüfung. Jeder Fall hat einen Grund: B-01 ist der Kleinbetrag, B-02 und B-03 prüfen die Grenzen bei 100 und 1.000, B-04 den Großbetrag, B-05 den fehlenden Betrag und B-06 einen Betrag als Text. Das sind die sechs Testfälle aus Teil 5. In die Spalte „Tatsächlich“ schreibst du erst nach dem Lauf, was wirklich kam, und dazu einen Haken oder ein Kreuz.

Warum die Erwartung zuerst? Weil das Gehirn bequem ist. Klickst du erst und schaust dann, siehst du „Sofort freigegeben“ und denkst: passt. Hast du vorher „An Teamleitung“ aufgeschrieben, stutzt du. Genau so fällt der Fehler bei B-02 auf.

Der letzte Fall ist neu: B-01 zweimal hintereinander. Was passiert? Zweimal „Bestellung auslösen“. In deinem Lern-Workflow ist das nur ein Output, in echt wären es zwei Monitore. Dazu kommt gleich mehr.

Diese vier Fehler stecken in fast jeder Freigabekette. Merk dir die Symptome, dann erkennst du sie schneller.

Felder gehen verloren: Im Ergebnis fehlt die Nummer. Du hast eine Freigabe, aber niemand weiß, für welche Bestellung. Die Grenze ist falsch: Der Auftrag sagt „unter 100“, gebaut ist „kleiner gleich“. Ein Zeichen, und die Teamleitung wird übergangen. Groß und klein: Der Monitor ist IT, aber die IT-Prüfung sagt nein, weil die Expression mit „it“ klein vergleicht. Das passende Rezept „IT-Prüfung: ja oder nein“ steht im Expression-Baukasten. Und die fehlende Wiederholungssperre: Jemand klickt zweimal auf Absenden, zwei Monitore werden bestellt. Das Wort dafür heißt Idempotenz, es kommt gleich.

Jetzt geht es um Nodes, die nicht falsch rechnen, sondern wirklich abbrechen. Dafür hat jeder Node den Reiter Settings, gleich neben Parameters.

Retry On Fail versucht es noch einmal, wenn der Node scheitert. Du stellst ein, wie oft und wie lange n8n dazwischen wartet (Wait Between Tries). Das passt, wenn ein Wetterdienst oder ein Mailserver kurz nicht antwortet. Ein fehlendes Feld fehlt auch beim dritten Versuch. Und Vorsicht bei Nodes, die etwas senden: Sonst geht die Mail dreimal raus.

On Error steht im Standard auf Stop Workflow: Der Lauf bricht ab, der Node wird rot, du siehst es in den Executions. Mit Continue (using error output) bekommt der Node einen zweiten Ausgang, und fehlgeschlagene Items fließen dort heraus. Die kannst du abfangen und an einen Menschen geben. Continue ohne Fehlerausgang macht einfach weiter, das ist nur sinnvoll, wenn du weißt, was mit dem Loch passiert. Stop and Error ist ein eigener Node: Du brichst absichtlich ab, mit deiner Meldung, etwa „Pflichtfeld E-Mail fehlt“. Das ist besser als ein rätselhafter Fehler drei Nodes später. Lektion 14 zeigt die Einstellungen zum Ausprobieren. Im Lernpfad blendest du sie mit dem Schalter „Fortgeschritten“ ein.

Fünf Regeln, die einem niemand beibringt, bis es wehtut. Nodes umbenennen: markieren und F2, oder im geöffneten Node oben auf den Namen klicken. „Switch1“ sagt nichts, „Nach Betrag verteilen“ sagt alles. Und weil du Expressions mit dem Node-Namen schreibst, liest sich dann auch die Formel wie ein Satz.

Eine Sticky Note oben links (Rechtsklick auf den Canvas, Add sticky note) mit Zweck, Start und Testfällen. Was für die Übergabe dazukommt, zeigt die nächste Folie. Keine Passwörter und keine API-Schlüssel in Textfeldern, nie: Dafür gibt es Credentials. Ein Workflow wird exportiert, geteilt, abfotografiert, und alles im Feld ist dann offen. Klein halten: ein Workflow, ein Zweck. Bei vierzig Nodes lieber teilen. Und den Stand markieren, dann weißt du später, welche Fassung das ist.

Was fehlt an „Starte ihn und schau, ob alles stimmt“? Alles. Wofür ist er da? Wie starte ich ihn? Womit? Was heißt „stimmt“? Wen frage ich?

Eine gute Übergabe beantwortet sechs Fragen und nennt eine Ansprechperson. Zweck: was der Ablauf macht und für wen. Start: wer oder was ihn auslöst und wo die Testdaten hineinkommen. Daten und Systeme: woher die Daten kommen, wohin sie gehen und welche Zugänge nötig sind. Regeln: welche Entscheidungen er trifft. Tests: welche Fälle mit welchem Ergebnis geprüft sind, also deine Testmatrix. Offene Grenze: was er nicht kann und was noch ungetestet ist. Und die Ansprechperson: wen man fragt.

Der Test ist einfach: Kann jemand anderes den Workflow starten und prüfen, ohne dich zu fragen? Die Sticky Note oben links ist der beste Ort dafür. Der Übergabe-Checker fragt genau diese Punkte ab, sagt dir, was fehlt, und baut dir einen Übergabebogen zum Kopieren.

Jetzt bist du dran, mit einem Ablauf aus deinem eigenen Alltag. Bau nicht den ganzen Prozess, sondern einen kleinen Ausschnitt: drei bis fünf Nodes, ein Trigger, ein Ergebnis, das man sieht, und eine Prüfung mit Fallback.

Was du nicht anbinden kannst, dein CRM, deine Buchhaltung, simulierst du mit einem Edit Fields, das so tut, als ob. Markier in der Sticky Note, was simuliert ist. Nimm nur den Gedanken mit: Welcher kleine Teil meines Ablaufs würde mir wirklich helfen? Teil 7 greift das zum Abschluss auf.