Teststrategie für AHB-Änderungen

Kurzantwort

Eine Teststrategie für eine AHB-Änderung beantwortet vier Fragen: Wie groß ist der Test (Umfang aus den Änderungshistorien), auf welchen Stufen läuft er (vom Mapping bis zur Abnahme), womit läuft er (Testdaten, Umgebung, Werkzeuge) und wann gilt er als bestanden (Abnahme mit Nachweis). Wie ein einzelner Testfall aus AHB-Zeile und Entscheidungsbaum entsteht, steht in AHB-Testfälle entwickeln; wie ein Formatwechsel im Unternehmen organisiert wird, in Release-Management für die Marktkommunikation. Dieser Artikel liegt dazwischen: Er legt fest, wie viele Fälle auf welcher Stufe nötig sind.

Umfang aus der Änderungshistorie

Jedes EDI@Energy-Dokument führt am Ende eine Änderungshistorie mit Änd-ID, Ort, „Bisher“, „Neu“, Grund und Status (Versionswechsel absichern). Jede Zeile bekommt eine Testtiefe. Die Beispiele stammen aus den Dokumenten zum 01.10.2026:

• Nur Schreibweise und Layout (UTILMD AHB Strom 2.2, Änd-ID 10000: Version 2.1 wird 2.2): kein Fachtest. Geprüft wird, dass das System die neue Versionskennung S2.2 erzeugt und akzeptiert.
• Geänderte Bedingung (Änd-ID 27084: In Bedingung [79] steht richtig STS+7++Z33): alle Prüfidentifikatoren, in denen die Bedingung vorkommt, je ein Fall mit erfüllter und mit verletzter Bedingung.
• Code mit Nutzungsende (EBD und Codelisten 4.3, Änd-ID 70329: A90, A96 und A99 laufen erst zum 01.04.2027 aus): Fälle mit dem Code vor und nach dem Datum, je mit der erwarteten Ablehnung.
• Geänderte Prüfung im Entscheidungsbaum (Änd-ID 70324, E_0270: auch die Artikel-ID 9991000003030-01 ist möglich): Fälle für die Rechnungsprüfung mit beiden Artikel-IDs.
• Neue oder entfallene Prüfidentifikatoren (Prüfidentifikatoren 4.0, Änd-ID 26133 und 26134, WiM Gas obsolet, 39000 bis 40000 neu): nur testen, was das Unternehmen sendet oder empfängt. Alles andere ist eine dokumentierte Nicht-Betroffenheit.

Die Liste ist die Grundlage für den Testplan. Eine Zeile ohne zugeordneten Test oder ohne Begründung der Nicht-Betroffenheit ist eine Lücke.

Teststufen

Stufe 1, Mapping und Syntax. Eine Regel, eine Nachricht. Prüft Segmente, Codes, Bedingungen gegen das AHB. Läuft früh und viel, auch automatisiert.

Stufe 2, Integration. Transport, Antwortverhalten und Fristen. Zu den Antworten gehört, was die Allgemeinen Festlegungen 6.1d seit dem 01.10.2026 für Strom festlegen: eine APERAK als Anerkennungsmeldung, eine CONTRL nur bei Syntaxfehler (Mitteilung Nr. 56). Der Nachrichtenweg lässt sich im IDoc-Monitoring verfolgen; SAP beschreibt es als Werkzeug zur Analyse von Status und Nutzdaten eingehender und ausgehender IDocs (SAP Help, IDoc Monitoring, IDoc-Monitoring im System). Das Monitoring belegt den Weg, nicht das fachliche Ergebnis.

Stufe 3, Prozess und Geschäftsobjekt. Das fachliche Ergebnis im System: Passt die Anlage, entsteht der Wechselbeleg, stimmt die Abrechnung? Hier liegt der Nutzen der Stufe gegenüber den ersten beiden. Ein richtig gemappter Wert kann in der Abrechnung trotzdem falsch ankommen. Die Prozesssicht liefern Prozessdokumente und Prozessmonitoring und Klärfälle.

Stufe 4, Abnahme. Der Fachbereich bestätigt ausgewählte echte Varianten und das Gesamtergebnis (siehe unten).

Das Zukunftsformat lässt sich bei SAP Market Communication for Utilities schon vor dem Stichtag testen: Test-Subkonten und Test-Systeme spielen die Prozesse mit den künftigen Versionen durch (SAP Help, Test Future Process Versions and Data Formats). Für ein klassisches IDE-System ist das in der geprüften Quelle nicht beschrieben.

Regressionsumfang

Eine Änderung kann Bestehendes brechen, ohne dass sie es nennt. Der Regressionsumfang ergibt sich aus den Anwendungsfällen, die das Unternehmen tatsächlich sendet und empfängt: Die Anwendungsübersicht der Prüfidentifikatoren liefert die Liste je Prozess. Davon werden die Fälle gewählt, die viele Marktpartner betreffen, kurze Fristen haben oder hohe Mengen tragen, zum Beispiel Anmeldung 55001, Bestätigung 55002 und Ablehnung 55003, Messwerte und Netznutzungsrechnung. Ein unveränderter Pfad bekommt weniger Tiefe, nicht keinen Test.

Testdaten und Umgebung

Gute Testdaten sind synthetisch oder anonymisiert und tragen ihre Beziehungen: Geschäftspartner, Vertrag, Anlage, Marktlokation (elfstellig, zum Beispiel 57891234562), Zeitraum und erwartete Antwort. Ein Testsystem darf Partner nicht versehentlich erreichen. Das gilt auch für automatisierte Läufe: Der Katalog führt eCATT (Transaktion SECATT) als Werkzeug, das Bedienschritte aufzeichnet und wieder abspielt, mit dem Hinweis, dass Testläufe echte Daten schreiben und nie auf ein Produktivsystem gehören (SECATT). Wo der Partnerkanal fehlt, steht im Testbericht, was stattdessen simuliert wurde.

Abnahme

Die Abnahme bündelt: Testfallliste mit Version und Ergebnis, offene Abweichungen mit Entscheidung, Liste der Nicht-Betroffenheiten, nicht geprüfte Punkte (zum Beispiel ein nicht erreichbarer Partner), Monitoring-Konzept für die ersten Tage und Rückfallplan. Ein Screenshot reicht nicht als Nachweis. Er braucht Version, Testdaten, Nachricht, Antwort, Status und das fachliche Ergebnis. Abweichungen werden nach Ursache getrennt: Produktfehler, Testdatenfehler, Konfiguration, Unklarheit im Dokument. Nicht jede blockiert den Stichtag, aber jede hat einen Eigentümer. Die Testfälle für häufige Fehler bleiben als Regressionsbestand für den nächsten Wechsel.

Typische Missverständnisse

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

„Nur neue Felder brauchen neue Tests.“ Geänderte Bedingungen, Codes und Prüfungen im Entscheidungsbaum können alte Fälle brechen.

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

Offen

• Ob und wie ein klassisches IDE-System das Zukunftsformat vor dem Stichtag testbar macht, ist nicht belegt.
• Testwerkzeuge über eCATT hinaus (SAP Solution Manager, Cloud ALM, CBTA) sind hier nicht geprüft und deshalb nicht beschrieben.

Quellen und Pflegehinweis

Beispiele aus den Änderungshistorien des UTILMD AHB Strom 2.2, der Anwendungsübersicht der Prüfidentifikatoren 4.0 und des EBD-Dokuments 4.3, Stand 01.04.2026, verbindlich ab 01.10.2026; SAP-Aussagen aus der SAP-Hilfe und der Transaktionswerkbank. Geprüft am 05.10.2026. Vor jedem Wechsel die Änderungshistorien der dann gültigen Fassungen neu lesen.