Teststrategie für AHB-Änderungen

Kurzantwort

Ein neues AHB ist keine reine Formatänderung. Es kann Pflichtfelder, Prüfregeln, Antwortverhalten, Fristen und fachliche Entscheidungswege verändern. Eine belastbare Teststrategie übersetzt deshalb jede AHB-Änderung zunächst in betroffene Prozesse und Rollen, baut daraus positive und negative Testfälle und prüft anschließend die Wirkung bis zum SAP-Utilities-Geschäftsobjekt. Maßgeblich ist immer die zum Umsetzungstermin verbindliche Version; Entwürfe und Konsultationsstände dürfen nicht versehentlich produktiv behandelt werden.

Der Test endet nicht bei einer syntaktisch gültigen EDIFACT-Datei. Zu prüfen sind Transport, Syntax, AHB-Regel, Antwortnachricht, Statusverarbeitung, Stammdatenzuordnung, Fristen, Wiederholung und fachliches Ergebnis. Regressionstests sichern außerdem bereits funktionierende Varianten wie Einzug, Auszug, Messwertkorrektur, Ablehnung und Mehrfachantworten.

AHB, MIG und Festlegung auseinanderhalten

Ein Anwendungshandbuch beschreibt, wie eine Nachricht in einem konkreten Prozess verwendet wird. Die Nachrichtentypbeschreibung (MIG) beschreibt die technische Struktur, während AHB und Entscheidungsdiagramme die fachliche Belegung und Prüfungen konkretisieren. Zusätzlich können Allgemeine Festlegungen, Codelisten, Übertragungsregeln und Beschlüsse der Bundesnetzagentur gelten. EDI@Energy veröffentlicht diese Dokumente in versionierten Ständen; die Bundesnetzagentur veröffentlicht Konsultationen und verbindliche Umsetzungstermine. EDI@Energy BNetzA Mitteilung Nr. 55

Der erste Projektschritt ist deshalb eine Baseline: Welche Fassung gilt für welchen Prozess, welche Rolle, welche Sparte und welchen Stichtag? Ein Delta zwischen zwei Dokumentversionen wird nicht nur nach hinzugekommenen Segmenten durchsucht. Relevant sind auch geänderte Muss-/Kann-Eigenschaften, Codelisten, Prüfidentifikatoren, Antwortregeln, Bedingungen in Entscheidungsbäumen und Fristen.

Delta-Analyse mit Auswirkungsmatrix

Für jede Änderung sollte eine Auswirkungsmatrix geführt werden. Sie verbindet die Dokumentstelle mit Prozess, Nachricht, Richtung, Systemkomponente, Testdaten, Erwartung und Verantwortlichem. Eine Formulierung wie „neues Pflichtfeld“ reicht nicht; zu beantworten ist, wer das Feld fachlich liefert, aus welchem Stammdatum es kommt, was bei fehlendem Wert geschieht und ob die Gegenstelle die Ablehnung über APERAK erwartet.

Die Matrix verhindert, dass technische Teams nur XML/EDIFACT-Strukturen testen und Fachbereiche nur Bildschirmbelege prüfen. Sie macht außerdem sichtbar, welche Regressionen trotz unveränderter Nachricht nötig sind: Ein Mapping kann durch eine neue Codeliste andere Fälle berühren.

Testfallklassen

Positive Fälle zeigen, dass eine gültige Nachricht vollständig verarbeitet wird. Sie sollten nicht nur den Standardfall enthalten, sondern unterschiedliche Sparten, Messkonstellationen, Marktlokationen, Zeiträume und Rollen. Ein Fall braucht eindeutige Testdaten und eine erwartete Statusfolge.

Negative Syntaxfälle prüfen fehlende Segmente, falsche Datentypen, ungültige Zeichensätze oder nicht erlaubte Strukturen. Negative AHB-Fälle sind davon zu trennen: Die Datei kann syntaktisch korrekt sein, aber eine fachliche Bedingung verletzen. Erwartet wird dann eine definierte Ablehnung, typischerweise mit passender Antwort und nachvollziehbarem Prüfidentifikator.

Grenzfälle sind besonders wertvoll: Stichtag um Mitternacht, Sommer-/Winterzeit, Nullmenge, Korrektur, verspätete Nachricht, doppelte Nachricht, paralleler Vertrag und wechselnde Marktrolle. Diese Fälle zeigen, ob die Implementierung Regeln wirklich auswertet oder nur den Happy Path abbildet.

Ende-zu-Ende in SAP Utilities

Ein Testfall ist erst bestanden, wenn die fachliche Wirkung stimmt. Für einen Messwert kann die Kette vom Eingang über technische Nachricht, Messwertstatus und Plausibilisierung bis zur Abrechnung reichen. Für einen Stammdatenaustausch gehört die Zuordnung zu Geschäftspartner, Vertragskonto, Anlage und Marktlokation dazu. Für eine Prozessnachricht sind Antwort, Korrelation und Frist Bestandteil des Ergebnisses.

Im SAP-System dürfen Tests nicht nur die Nachrichtentabelle betrachten. Zu prüfen sind die für den Prozess relevanten Logs, Prozessdokumente, Messwerte, Stammdaten und Belege. SAP beschreibt IDoc-Monitoring als Möglichkeit, inbound und outbound Status sowie Nutzdaten zu analysieren; der Monitor ist damit ein Beleg für den Nachrichtenweg, aber nicht automatisch für das fachliche Ergebnis. SAP Help

Testdaten und Isolation

Testdaten müssen fachlich repräsentativ und technisch reproduzierbar sein. Für jede Variante werden die beteiligten IDs, Zeitpunkte, Messwerte, Marktrollen, Versionen und erwarteten Antworten dokumentiert. Produktive personenbezogene Daten sind dafür nicht automatisch geeignet. Besser sind synthetische Daten oder anonymisierte Kopien mit kontrollierter Beziehung zwischen Partner, Vertrag und Lokation.

Ein Testsystem muss gegenüber externen Partnern isoliert sein. Nachrichten dürfen nicht versehentlich produktive Verträge ändern oder echte Antworten auslösen. Gleichzeitig sollte der Transportweg möglichst produktionsnah simuliert werden. Abweichungen, etwa ein Mock statt einer echten AS4-Strecke, werden im Testbericht ausdrücklich festgehalten.

Automatisierung, Wiederholung und Regression

Automatisierte Tests eignen sich für wiederkehrende Format- und Mappingprüfungen. Sie ersetzen nicht die fachliche Auswahl der Fälle. Ein guter Satz umfasst Golden Messages, bewusst fehlerhafte Nachrichten, erwartete Antwortnachrichten und eine Prüfung des Zielobjekts. Nach jedem Lauf werden Nachrichten-ID, Version, Testdatenstand, Ergebnis und Logreferenz gespeichert.

Bei Wiederholungen ist Idempotenz zentral. Wird dieselbe Nachricht erneut angeliefert, darf sie nicht ohne weiteres einen zweiten Vertrag oder Beleg erzeugen. Ein Korrekturfall darf dagegen den fachlich korrekten neuen Zustand herstellen. Diese beiden Fälle müssen getrennt getestet werden.

Regressionen sollten risikobasiert priorisiert werden. Hohe Priorität haben Prozesse mit vielen Marktpartnern, kurzen Fristen, hohen Mengen oder regulatorischer Relevanz. Niedrige Priorität bedeutet nicht „nicht testen“, sondern geringere Ausführungstiefe bei unveränderten Pfaden.

Cutover und Abnahme

Vor dem Umsetzungstermin braucht es eine klare Versionierungs- und Cutover-Entscheidung: Welche Version wird gesendet, welche empfangen, und wie werden Nachrichten behandelt, die vor dem Stichtag erzeugt, aber danach zugestellt werden? Die Antwort muss aus den verbindlichen Dokumenten und dem jeweiligen Prozess abgeleitet werden.

Die Abnahme umfasst mindestens Testfallliste, erwartete Ergebnisse, offene Abweichungen, Risikoentscheidung, Monitoring-Konzept und Rückfallplan. Ein Rückfallplan bedeutet nicht automatisch, dass alte Versionen weitergesendet werden dürfen. Er kann auch bedeuten, die Verarbeitung zu stoppen, Nachrichten sicher zu puffern und nach Freigabe kontrolliert nachzuverarbeiten.

Typische Missverständnisse

„Wenn die MIG validiert, ist der Test bestanden.“ Die MIG deckt Struktur ab; AHB-Regeln und fachliche Wirkung bleiben zu prüfen.

„Nur neue Felder brauchen neue Tests.“ Geänderte Bedingungen, Codes, Antworten und Fristen können alte Fälle brechen.

„Ein negativer Test ist ein Fehler.“ Ein negativer Test ist erfolgreich, wenn die Nachricht kontrolliert und mit der erwarteten Reaktion abgelehnt wird.

„Ein Screenshot reicht als Nachweis.“ Ein belastbarer Nachweis enthält Version, Testdaten, Nachricht, Antwort, Status und fachliches Ergebnis.

Ein Beispiel für eine Testfallkarte

Eine gute Testfallkarte beginnt mit dem Zweck: etwa „Nachricht mit neuem Pflichtmerkmal wird für eine gültige Marktlokation verarbeitet“. Danach folgen Vorbedingungen, konkrete Testdaten, verwendete Dokumentversion, Eingangsnachricht, erwartete Prüfungen, erwartete Antwort und erwartetes SAP-Ergebnis. Ein zweiter Fall verwendet dieselbe fachliche Situation ohne das Pflichtmerkmal. Dann muss die erwartete Ablehnung präzise beschrieben sein; „Fehler“ ist kein prüfbares Ergebnis.

Für Korrekturen wird eine Kette aus mindestens drei Nachrichten sinnvoll: ursprünglicher gültiger Wert, korrigierter Wert und Wiederholung beziehungsweise Folgeprozess. Dabei wird geprüft, ob der neue Zustand entsteht, ob der alte Zustand nachvollziehbar bleibt und ob keine doppelte Menge in Abrechnung oder Bilanzierung landet. Für zeitkritische Prozesse werden die tatsächlichen Erzeugungs-, Versand-, Eingangs- und Verarbeitungszeitpunkte dokumentiert.

Change Governance und Umgebungen

Die AHB-Änderung muss mit dem Release des Mappings, der Partnervereinbarung und dem Deployment der SAP-Erweiterungen zusammenpassen. Ein fachlicher Test in einer Umgebung mit alter Codeliste liefert sonst ein trügerisches Ergebnis. Die verwendeten Artefakte werden daher versioniert: Mapping, AHB, MIG, Codelisten, Testdaten und Konfiguration.

Sinnvoll ist eine Staffelung. Im Unit- oder Mappingtest wird die einzelne Regel geprüft. Im Integrationstest werden Transport und Antwort einbezogen. Im Prozessintegrationstest wird die SAP-Utilities-Wirkung geprüft. Im Abnahmetest bestätigt die Fachseite ausgewählte reale Prozessvarianten. Die Stufen dürfen nicht verwechselt werden: Ein bestandener Mappingtest sagt wenig über eine korrekte Nachberechnung aus.

Nach dem Go-live beginnt die Hypercare-Phase. Überwachungskennzahlen werden mit der Vorperiode verglichen, neue Fehlerbilder gesammelt und die ersten produktiven Fälle stichprobenartig fachlich kontrolliert. Ein ungewöhnlicher Rückgang eingehender Nachrichten kann ebenso wichtig sein wie ein Anstieg abgelehnter Nachrichten.

Qualitätskriterien für einen bestandenen Test

„Bestanden“ sollte für jede Testfallklasse eine konkrete Bedeutung haben. Bei einem positiven Fall sind Nachricht, Antwort, Statusfolge und fachliches Zielobjekt korrekt. Bei einem negativen Fall wird die Nachricht mit dem erwarteten Fehlerbild abgelehnt und erzeugt keine unerlaubte Nebenwirkung. Bei einem Wiederholungsfall bleibt das Ergebnis idempotent. Bei einer Korrektur wird der neue Wert wirksam, ohne die Historie unkenntlich zu machen.

Zusätzlich wird geprüft, ob der Test selbst aussagekräftig war. Ein Fall ohne echte Pflichtfeldprüfung, ohne realistische Zeitbeziehung oder ohne Gegenprüfung im Zielobjekt kann grün sein und trotzdem eine Lücke darstellen. Die Testleitung bewertet deshalb Abdeckung nicht nur nach Anzahl der Fälle, sondern nach abgedeckten Regeln, Rollen, Varianten und Fehlerklassen.

Ein Abweichungsprotokoll trennt Produktfehler, Testdatenfehler, Konfigurationsabweichung und Dokumentunklarheit. Nicht jede Abweichung blockiert den Go-live, aber jede braucht eine begründete Entscheidung, einen Eigentümer und gegebenenfalls einen Nachtest. Besonders riskant sind Abweichungen, die nur durch manuelle Korrektur im Betrieb beherrschbar wären.

Die beste Teststrategie bleibt anschlussfähig an den Betrieb. Testfälle für häufige Fehler werden nach dem Umsetzungstermin als Monitoring- und Regressionstests weiterverwendet. So entsteht kein einmaliger Testordner, sondern ein lebender Bestand, der mit neuen AHB-Versionen und realen Störungen wächst.

Die Testdokumentation sollte außerdem festhalten, was nicht geprüft wurde. Ein nicht verfügbarer Partnerkanal, eine nicht getestete Sparte oder ein fehlender Sonderfall ist ein bewusstes Risiko und keine unsichtbare Lücke. Diese Transparenz erleichtert die Freigabeentscheidung und verhindert, dass ein späterer Fehler fälschlich als überraschend gilt. Ein Traceability-Index ordnet jede relevante AHB-Regel mindestens einem positiven und einem negativen Testfall zu. So bleibt sichtbar, ob eine Änderung nur technisch validiert oder auch fachlich abgenommen wurde.

Quellen und Pflegehinweis

AHB, MIG, Codelisten und Umsetzungstermine sind versioniert und ändern sich. Vor jeder Kampagne muss die Dokument-Baseline neu festgestellt werden. Die Verfahren der Bundesnetzagentur – etwa GPKE und WiM – bilden den regulatorischen Rahmen; EDI@Energy liefert die technischen Dokumente. SAP-Eigenheiten hängen von Release, Add-ons und kundeneigenem Mapping ab und müssen im eigenen System verifiziert werden.