Wie SQACE testet, ob die Verarbeitung richtig gerechnet hat.
Eine Verarbeitung crasht selten. Sie liefert eine Zahl, die plausibel aussieht und trotzdem falsch ist. Auf dieser Seite folgen Sie einem einzigen Beispiel von Anfang bis Ende: vom Input über eine fachliche Regel bis zur klassifizierten Abweichung. So arbeitet SQACE an jeder Verarbeitung.
Wir verifizieren das Ergebnis, nicht nur, ob die Daten gut aussehen, und nicht nur, ob sich nichts verändert hat.
SQACE
Verifiziert, ob die Verarbeitung das fachlich richtige Ergebnis erzeugt hat, über einen regelbasierten Soll/Ist-Vergleich.
DQ-Monitoring
Zeigt, ob die Daten plausibel aussehen. Beantwortet nicht, ob die Verarbeitung korrekt gerechnet hat.
Regressionstest
Zeigt, ob sich gegenüber dem letzten Lauf etwas verändert hat. Findet keinen Fehler, der von Anfang an in der Logik steckt.
DQ-Monitoring und Regressionstests bleiben sinnvoll. SQACE setzt eine Ebene darüber an: Hat die Verarbeitung fachlich richtig gerechnet?
Vier Schritte, von der Regel zur Abweichung.
Schritt 1, Input
Eingangsdaten aus der Quelle lesen
SQACE liest die Eingangsfelder lesend aus der Quelle, hier per Oracle JDBC: den Kapitalertrag, den Steuersatz und die Teilfreistellung aus den Stammdaten. Dieselben Werte, die auch die produktive Pipeline verarbeitet hat.
Schritt 2, Regel
Die fachliche Regel im visuellen Builder
Der Fachbereich setzt die Regel im Rule Editor zusammen, Block für Block, ohne SQL. Eine Bedingung (WENN) und eine Berechnungsvorschrift (DANN), aus den Feldern der Quelle aufgebaut und an echten Daten verprobt, bevor sie produktiv läuft.
Der Fachbereich besitzt die fachliche Regel und weist sie nach, ohne dass jemand SQL entziffert. Was richtig ist, definiert die Person, die es fachlich verantwortet, sichtbar im Rule Editor rechts. Über „An echten Daten verproben“ lässt sich die Regel sofort gegen reale Werte prüfen, und die IT sieht dieselbe lesbare Logik, nicht eine Abfrage, die sie erst rückübersetzen müsste.
Felder aus der Quelle
Oracle JDBC, read-only
- kapitalertrag Betrag, Eingangsfeld
- steuersatz Quote, Eingangsfeld
- teilfreistellung Quote, Stammdaten
für die Position eine Teilfreistellung in den Stammdaten hinterlegt ist.
In Worten lesbar, die Formel darunter ist nur die zweite Schreibweise. Aus genau dieser Regel berechnet SQACE das Soll, ohne dass jemand eine SQL-Abfrage entziffern muss.
Soll ist die zweite, regelbasierte Berechnung. Klassifiziert als Rechenregel-Abweichung im Feld Kapitalertragsteuer, über Läufe verfolgt.
Schritt 3, Soll/Ist
Die zweite Berechnung gegen das Ist gestellt
SQACE rechnet das Soll aus der Regel noch einmal aus, auf einem zweiten, von der Pipeline getrennten Weg, und stellt es Zeile für Zeile gegen das Ist der Pipeline. Kapitalertrag und Steuersatz stimmen. Beim Steuerbetrag laufen Soll und Ist auseinander.
Schritt 4, Befund
Die Abweichung bis auf Feld und Regel
Der Befund bleibt nicht bei Rot oder Grün stehen. Er nennt das Feld (Kapitalertragsteuer), die erzeugende Regel und die Zahl der geprüften Positionen. Im Ist wurde die Teilfreistellung nicht angewandt, ein Logikfehler, der plausibel aussieht und den ein Blick auf die Daten allein nicht zeigt.
Abweichung über Läufe
In 3 von 12 betrachteten Läufen aufgetreten, jedes Mal in derselben Klasse: Rundungs- bzw. Rechenregel-Abweichung bei der Teilfreistellung.
Illustrative Lauf-Historie, synthetische Werte. So fasst SQACE eine Abweichung über mehrere Läufe zusammen und ordnet sie einer Klasse zu.
Vier Action-Typen, frei verkettet.
Ein Test entsteht aus wenigen Bausteinen, den Actions. Sie lassen sich kombinieren und wiederverwenden. Ohne SQL starten, für Sonderfälle SQL nutzen, sodass auch erfahrene Nutzer nicht ausgebremst werden.
Soll gegen Ist
Vergleich
Tabellen, XML und JSON auf Datensatz-, Spalten- und Regelebene vergleichen. Mit Toleranzen und Schweregraden, über hunderttausende Datensätze.
Regeln statt Augenschein
Validierung
Wertebereiche, Pflichtfelder, Beziehungen und fachliche Regeln prüfen. Ohne SQL definiert, direkt im Lauf ausgeführt.
Easy Query
Abfrage
Daten aus mehreren Quellen blockweise abfragen und aufbereiten, mit Join-Vorschlägen. SQACE erzeugt daraus prüfbares SQL.
Ein Ablauf
Verkettung
Lesen, aufbereiten, vergleichen, validieren und schreiben zu einem Ablauf verketten, per Drag-and-drop, ganz ohne Code.
Die Prüfinstanz sitzt außerhalb des Stacks.
Die zweite Berechnung läuft nicht in der Pipeline mit, die sie prüfen soll. SQACE liest die Ergebnisse lesend aus und rechnet das Soll auf einem getrennten Weg aus, aus Ihrem Regelwerk, unabhängig von Werkzeug und Verfahren. Geprüft wird das beobachtbare Ergebnis, nicht der gute Wille des Systems, das es erzeugt hat.
Das wird wichtiger, je mehr Verarbeitungen mit KI entstehen: Wer die Pipeline gebaut hat, ist nicht die richtige Instanz, um zu bestätigen, dass sie richtig gerechnet hat. Syntaktisch korrekter Code heißt nicht logisch korrektes Ergebnis.
Warum getrennt
- Eigenes Regelwerk statt der Logik, die im Verdacht steht.
- Lesender Zugriff auf das Ergebnis, kein Eingriff in den Lauf.
- Unabhängig von Tool, Verfahren und der KI, die die Pipeline gebaut hat.
Rund 80 Prozent der Verarbeitungen sind regelbasiert prüfbar.
Nach unserer Erfahrung lässt sich ein Großteil der Datenverarbeitungen, rund 80 Prozent, mit dem regelbasierten Soll/Ist-Ansatz abdecken: überall dort, wo sich das richtige Ergebnis aus Eingangsdaten und fachlichen Regeln ableiten lässt. Das ist eine Aussage zur Abdeckung, nicht zur Aufwandsersparnis. Für die übrigen Fälle bleiben Regressionstests und gezielte Validierungen das passende Mittel.
Vom Ad-hoc-Lauf zur automatisierten Suite.
Derselbe Test wächst mit. Was Sie ad-hoc verprobt haben, läuft ohne Neubau geplant oder aus Ihrer CI/CD-Strecke. Über das Launch Pad werden Test Suites parametrisiert und ausgeführt.
Ad-hoc verproben
Manuell
Einen Lauf direkt starten, das Ergebnis im Dashboard prüfen und die Regel anpassen. Try, run, adjust in einer Sitzung.
Wiederkehrend
Geplant
Denselben Test als geplante Suite ausführen, parametrisiert und nach jedem Release vergleichbar, ohne Neubau.
Über die REST-API
CI/CD
Suiten aus Jenkins, GitLab CI, Azure DevOps oder Camunda auslösen. Befunde werden ins Testmanagement (Jira/Xray) zurückgeschrieben.
Was Teams vor dem ersten Lauf fragen.
Nein. Fachliche Regeln entstehen im visuellen Rule Editor und in der Easy Query, Block für Block, ohne SQL. Für Sonderfälle steht eine SQL-Action bereit, sodass erfahrene Nutzer nicht ausgebremst werden.
SQACE rechnet das erwartete Ergebnis aus Ihren Eingangsdaten und Ihrem fachlichen Regelwerk noch einmal aus, auf einem zweiten, von der Pipeline unabhängigen Weg. Dieses Soll wird dann gegen das Ist der Pipeline gestellt.
Bis auf Feld- und Regelebene. Der Befund nennt das betroffene Feld, die erzeugende Regel und die Zahl der geprüften Positionen. Jeder Lauf ist reproduzierbar, versioniert und im Audit Trail hinterlegt.
Nach unserer Erfahrung lässt sich ein Großteil der Datenverarbeitungen, rund 80 Prozent, mit dem regelbasierten Ansatz abdecken. Das ist eine Aussage zur Abdeckung, nicht zur Aufwandsersparnis.
Sehen Sie den Soll/Ist-Vergleich an Ihren Daten.
In einer Demo rechnen wir das Beispiel an einem Ihrer Anwendungsfälle durch. Oder starten Sie mit einem Proof of Concept auf einer Pipeline.