Die Qualitätssicherung der TAF/TAP TSI-Gesamtlösung erfolgt entlang einer übergreifenden, abgestimmten Teststrategie.

Ziel ist die frühzeitige Validierung der fachlichen und technischen Anforderungen sowie die Sicherstellung der Betriebsfähigkeit in End-to-End-Prozessen. Das erfolgt sowohl innerhalb der DB InfraGO als auch im Zusammenspiel mit den Eisenbahnverkehrsunternehmen (EVU).

Dieses Kapitel beschreibt die grundlegenden Teststufen, das Testvorgehen in den Solutions sowie die Planung und Steuerung der integrierten Tests inklusive der Markttests.

2

Bearbeitungsstatus

Überblick Teststufen und Verantwortung für diese

Der Test im Rahmen der Umsetzung von TAP/TAF TSI umfasst folgende Teststufen:

• Kundentest
• Abnahmetest
• Systemintegrationstest
• Systemtest
• Integrationstest
• Komponententest

Dabei ist die Verantwortung für die Teststufen wie folgt definiert:

• Die Steuerung der Tests erfolgt durch das TTT Testmanagement ab Ebene Systemintegrationstest. 
• Die Durchführung liegt von Komponententest bis Systemintegrationstests bei den Projekten/Solutions
• Die Unterscheidung zwischen Durchführung und Steuerung ist dabei wie folgt zu verstehen:
  • Steuerung: Die die einzelnen Solutions bzw. Teams/Systeme (Beispiel TPN, Rut-K, GFD, PathOS, ...) den Anforderungsscope ihrers Systems bzw. ihrer Umsetzungsleistung kennen, jedoch nicht zwingend Anforderungen, welche sich aus übergreifenden Geschäftsprozessen an sie ergeben, ist die Verantwortung für Testaktaktivitäten, da Anforderungsscope bekannt, bis auf Systemtestebene durch die Solutions/Teams zu steuern. Gegen übergreifende Anforderungen, kommend aus E2E-Geschäftsprozessen bzw. TTT generell, steuert das übergreifende Testmanagement der Programmsteuerung/Solution Steuerung, da diese den E2E-Prozessscope betrachten. Dies beginnt bei der InfraGO-internen, aber System-übergreifenden Integrationstests (Teststufe Systemintegrationstest nach Pyramide) bis hin zu Abnahmetests mit den Kunden.
  • Durchführung: Die Durchführung der Testaktivitäten bis einschließlich Systemtest findet auf Ebene der Entwicklungsteams statt. Systemintegrationstests (beispielsweise die ART-üg Tests) werden durch das übergreifende Testteam Quest der Solution C2S durchgeführt. Punktuell kann hier Unterstützungsleistung aus den einzelnen Teams angefragt werden. Die InfraGO-Abnahmetests und die Kundentests werden moderiert durch die Makrttestleads und durchgeführt durch dedizierte Kollegen aus den Solutions, welche für diese Teststufen bereitgestellt werden.

Verantwortung für Qualitätssicherung in TTT Testmanagement

Das Testmanagement im Programm TTT steuert die folgenden Teststufen: 

• Systemintegrationstest:
  • Hierbei steht die übergreifende Zusammenarbeit von Systemen und Services im Vordergrund auf der funktionalen E2E-Kette
  • Die einzelnen Systeme und Services sind hierbei als Blackbox zu sehen. Die Bestellung werden per TPN bzw. Portal eingekippt und geprüft wird das entsprechende Ergebnis (Vertrag mit dem Kunden)
  • Testumfang: ausgewählte Tests (automatisiert/manuell) entsprechend der Priorisierung regressiv nach jedem Release und progressiv für jede neue Funktionalität
  • Dokumentation:
    • Testfälle sind in Xray hinterlegt
    • Ziel:
      • manuelle Testausführungen werden zukünftig in Xray ausgeführt ( ~25% der ART-übergreifenden Testfälle) 
      • automatisierte Testausführungen werden in TDM dokumentiert (~75% der ART-übergreifenden Testfälle)
  • Test-Bericht:
    • Ziel ist es, automatisiert aus Xray bzw. TDM Testergebnisse zu reporten
      • die Ergebnisse der automatisierten Tests sind sichtbar in https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/GelV_ART_ue_GTests_%C3%9Cbersicht.html?env=abnTTT 
        • allerdings fehlt hier stand heute die Verbindung zu den getesteten Anforderungen und gefundenen Defects
        • Beispiel
    • Aktuell werden die Ergebnisse der manuellen Tests manuell zusammengestellt
• Abnahmetest
  • Hierbei geht es um eine Blackbox Betrachtung der DB InfraGO mit Fokus auf realistische Kundenbestellungen und deren Verarbeitung
  • Bestellung werden manuell über das Portal eingepflegt oder über das Common Interface gesendet (  Abdeckung beider Kanäle ist wichtig) und orientieren sich an realistischen Kundenbestellungen, entweder vom Vertrieb oder den Testfällen der Kunden
  • Testumfang: Testfälle werden manuell entlang neuer Funktionalität durchgeführt, Regression ist bisher nicht vorgesehen
  • Dokumentation:
    • Testfälle werden in Xray hinterlegt
      
      
• Kundentest
  • Hierbei geht es um Blackboxtests gemeinsam mit dem Kunden mit dem Ziel, Teilprozesse, Gesamtprozesse und Varianzen dieser (Attribute) zu testen
  • Kunden schicken Bestellungen über ihre Systeme an das Common Interface, darüber kommen sie ins unsere Systeme. Wir bearbeiten die Bestellungen und schicken sie über das Common Interface zurück an die Kunden. Diese prüfen die eingegangenen Nachrichten.
  • Testumfang: Testfälle werden manuell entlang des testbaren Scopes durchgeführt
  • Dokumentation:
    • Testdurchführung wird in den Testsheets gemeinsam mit den Kunden dokumentiert (Ablage in Teams, das mit den Testpartnern geteilt wird)
  • Bericht siehe 100 Statusreporting

Das übergreifende Testmanagement verantwortet dabei folgende Testarten: 

• Funktionale Tests nach Testpyramide (beschrieben bereits oben)

• Smoketests: Werden stündlich auf der ITU und KTU durchgeführt und prüfen eine einfache Anmeldung bis zum Vertragsschluss im GelV und NEP. Ergebnisse können hier getrackt werden:

  • ITU GelV: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/GelV_Index.html?env=ituTTT
  • ITU NEFP: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/Nfpl_Index.html?env=ituTTT
  • ITU uj Bau: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/ujBau_Index.html?env=ituTTT

  • KTU GelV: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/GelV_Index.html?env=abnTTT

  • KTU NEFP: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/Nfpl_Index.html?env=abnTTT

• Shakedown Tests: Gemeinsam mit Kunden wird nach dem InfraGO Release und vor einer Kundentestsession eine Basisbestellung (Einfach Anmeldung Basiszug mit jeweiligen EVU im NEFP) durchgeführt.

• (Kundentests) Markttests

• Last- und Performance Test für die Gesamtprozesskette

Verantwortung für Qualitätssicherung in Projekten/Solutions

Die Projekte / Solutions sind für die Qualitätssicherung, der von ihnen gelieferten Software verantwortlich. Dazu steuern sie die Tests in folgenden Teststufen:

• Komponententest
• Integrationstests
• Systemtest

Die Projekte/Solution verantworten darüber hinaus die qualitätsgesicherte Lieferung in die Teststufen Systemintegrationstest und Abnahmetest sowie den Kundentest.

Durch die einzelnen Projekte/Solutions sind die folgenden Testarten abzudecken:

• Funktionale Tests (siehe Testpyramide)
• Last- und Performance Tests auf Ebene eines Systems

• Penetration Tests

• Desaster Recovery

Testvorgehen

Das Vorgehen zum ART-übergreifenden Test umfasst die folgenden Teilaspekte:

• Testscope & Testfälle
• Testablauf insb. Kundentests
• Defect Mgmt
• Testreporting
• Umgebungen
• Testdatenmanagement

Testscope

Der gemeinsame Nenner der Entwicklung aller InfraGO Anteile, sowie der Entwicklung unserer Kunden stellt die öffentlich verfügbare Schnittstellenbeschreibung dar. In aktuellster Form ist zu finden unter https://www.dbinfrago.com/web/schienennetz/netzzugang-und-regulierung/taf-tap-tsi/evu_schnittstelle-11089208. Zim   ist die aktuelle Version 4.6.1.

Für den Test betrachten wir auf strategischer Ebene die TTT Teilprozesse und die technischen/fachlichen Attribute, welche in Summe eine TTT-Nachricht beschreiben:

Prozesse

Die Teilprozesse, Prozessbilder und Beschreibungen sind hierbei in folgendem Dokument zu finden: (Original Quelle: Link | Auszug: Link)  in Kapitel 5.

• Intern bilden wir die Prozesse aktuell wie folgt ab - veraltet-
  

  Zusammenfassende Sicht aus TTTneo:

Attribute - veraltet

Die technischen/fachlichen Attribute sind hauptsächlich in folgendem Anforderungsdokument zu finden: (Original Quelle: Link | Auszug: Link)

• Intern haben wir im Conflience ein Attributmapping aus der Schnittstellenbeschreibung in die umsetzenden Systeme aufgebaut:
  

  Attributmapping TTTneo: https://arija-confluence.jaas.service.deutschebahn.com/x/hUdKGQ

Testvorgehen entlang Anforderungsmatrix

Der Scope übergreifend betrachtet ergibt sich entsprechend aus der Kombination von Teilprozessen/Geschäftsvorfällen mit den zugehörigen Attributen. Dies kann in Form einer Matrix dargestellt werden, wobei auf der X-Achse die Teilprozesse genannt sind und auf der Y-Achse die Attribute genannt sind. Das Testvorgehen deckt diese Anforderungsmatrix nun in drei Schritten jeweils pro Teststufe ab:

1. Happy Path Tests Teilprozesse
   1. Ablauf: Es ist im ersten Schritt sicherzustellen, dass alle (im aktuellen Testscope (bspw. für den Sommer NEP1) Teilprozesse mit einem Basiszug (einfachstes Setup von Attributen, keine Infrastrukturherausforderungen, kurzer Laufweg,...) erfolgreich durchlaufen werden können
   2. Gewünschte Erkenntnisse: Die Prozesse sind nach Schnittstellenvereinbarung sauber implementiert und können von Kunden durchlaufen werden (Betrachtung rein der Prozesssicht, bewusst ohne Komplexität, um prozessuale Fehler auszuschließen)
2. Einfach Attributtests
   1. Ablauf: Es sind Einzelattribute (bspw. Alternative Charakteristika, Nachtsprung, Gefahrengüter,...) in einem möglichst einfach Szenario (kurzer Laufweg, keine komplexen Attributkombinationen,...) zu prüfen
   2. Gewünschte Erkenntnisse: Die Attribute für sich genommen funktionieren und können durch die InfraGO Systeme und die im Schritt 1 getesteten Teilprozesse sauber verarbeitet werden
3. Komplexe Tests
   1. Ablauf: Da wir nun wissen, dass alle Teilprozesse und alle Einzelattribute funktionieren, testen wir nun die beliebige (erlaubte) Kombination von Attributen und Teilprozessen (intern am Beispiel real vom Kunden bestellter Züge), durch Kunden anhand ihrer produktionsnahen Bestellungen
   2. Gewünschte Erkenntnisse: Kann unser System produktive Züge von Heute (und nach Schnittstellenbeschreibung auch von Morgen erlaubte) sauber abbilden und die Prozesse mit gewünschten Ergebnis (zum Beispiel Vertragsendzustand) abbilden?

Die Testfälle sind in  ausgeführt.

Defect Management

in Arbeit

Testreporting

Das Reporting erfolgt - zum Stand wöchentlich 100 Statusreporting. Zusätzlich erfolgt ein Beitrag zum Lenkungskreis TTT.

Umgebungen - veraltet

Die Umgebungen zur Durchführung der Systemintegrations-, Abnahme- und Markttests werden durch die Projekte/Solutions verwaltet und bereitgestellt.

Für C2S und O2C gibt es folgende Umgebungen:

• Fachliche Beschreibung: für C2S und Details für TTT Neo 
• Technische Übersicht und aktueller Status Smoke-Test: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/

Es gab signifikante Herausforderungen zur Umgebungsstabilität. Daher wurde eine Taskforce ins Leben gerufen. Seit April 2025 wurden Fehler der Umgebungen zunächst in Excel getrackt (https://dbsw.sharepoint.com/:x:/r/teams/TTT-Portfolio-Management/_layouts/15/Doc.aspx?sourcedoc=%7B6A721131-9152-4EB2-93F0-311F6836178A%7D&file=KTU_Fehlertracking_Liste.xlsx&action=default&mobileredirect=true). Seit werden Probleme mit der Umgebung als Defects erfasst und in Jira getrackt.

Testdatenmanagement

 Das Testdatenmanagement erfolgt heute dezentral bei den jeweiligen Systemen. Da - auch produktiv - viele Systeme für gleiche fachliche Daten unterschiedliche Quellen nutzen, kommt es immer wieder zu Herausforderungen insb. in Bezug auf die Infrastrukturdaten, da das Mapping bei IDBF im Infrastrukturdatenmanager (IM) veraltet ist.

Testplanung

Die Testplanung für Integrations- und Markttests basiert jeweils auf den Release- bzw. Lieferplänen der Projekte/Solutions. Die benötigten Testaktivitäten werden nach dem Abschluss von Entwicklung und Qualitätssicherung in den ARTs - Erreichung Meilenstein in Planung der Projekte/Solutions - geplant. 
Je nach fachlichem Inhalt des Meilensteins werden die benötigten Testfälle ermittelt und daraus die notwendige Zeit für die Testdurchführung inkl. Nachtests unter der Annahme, dass FixIT aller kritischen Defects zeitnah erfolgt, ermittelt. 

• 10 Testkonzept u. Planung

Stand vom gibt es die zeitliche Planung oben, aber diese ist noch nicht ressourcentreu. 

Informativ: Testvorgehen in den Projekten / Solutions

Hier sind informativ Link zu Dokumentation des Vorgehens zur Qualitätssicherung in Projekten / Solutions eingefügt, sofern sie der Programmsteuerung und dem übergreifenden Testmanagement vorliegen. Die Liste hat keinen Anspruch auf Vollständigkeit:

• Dokumentation aus Sicht O2C
  • QA Test Bestellsystem
• Dokumentation aus Sicht C2S
• Dokumentation aus Sicht S2O
  • Planung auf Ebene Meilenstein: