ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a5f8fb49ab7e6e9ab4676c75978a76ffb23a8d4e
Orchestrator/bahn/project-audit/data/confluence-export/pages/556699737_2026-03-03 Smoketests nach Deployments.md
T
ankn a5f8fb49ab Migrate all repos into monorepo context folders 
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2026-06-30 20:39:52 +02:00

2.4 KiB
Raw Blame History

2026-03-03 Smoketests nach Deployments

Confluence Page ID: 556699737 Version: 2 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2026-03-03 Smoketests nach Deployments Labels: meeting-notes

Teilnehmer

  •      

Verständnis:

  • Smoketest: Validierung, dass die Umgebung nach Deployment eines Artefakts (Release/Hotfix) angekommen ist und Umgebung noch funktioniert

Ziel

  • Entwurf von Smoketests für Abnahme- und Produktionsumgebungen

Zu entscheidende Fragen:

  • Wer soll die ausführen können
  • Jeder der installiert → primär OpsSquad
  • Muss prinzipiell jedem möglich sein (auch PO/PM)
  • Scope: wie weit sollen die gehen, was wollen wir testen? 
  • pathOS+TPN
  • "nur" Kommunikationsweg: wir führen eine Anmeldung durch, die bei uns durchläuft, aber dann in der Eingangsvalidierung scheitert
  • Idee:
  • Kundennummer, die TPN nicht kennt
  • Datenkonstellation, die in TPN fachlich tiefer validiert wird (z.B. ETCS-Ausprägungen, oder Studienausprägungen als Triebfahrzeug)
  • dadurch wissem wir dass Kommunikation bidirektional funktioniert. Erzeugen so auch nur Daten in pathOS.
  • Für Produktion
  • Erzeugen von Daten in pathOS? → OK
  • Rahmenbedingungen (z.B. zu verwendende Kundennummer, Strecke, ...)
  • alles quasi unter dem Aspekt erstmal egal, da wir nur in die Fehlermeldung gehen
  • Welcher Test(s) sehen wir als verpflichtend an?
  • Alle drei Tests verpflichtend für alle Umgebungen (kann bei fachlichen Bedarf auch durch Positivfälle substituiert werden). 
  • Testdokumentation im Rahmen des Releases (Testexecution)? Gegen Checkliste prüfen. TODO

Testfälle:

  • Ablage hier: Test Repository - DB InfraGO ITD Lifecycle Management Tool 
  • Testideen:
  • Test im Kanal Portal
  • Trassenanmeldung
  • Case Reference Object anlegen
  • Test im Kanal CI
  • Trassenanmeldung
  • Trassenanmeldung: siehe unten. Einfachster Laufweg etc. → mit Testbausteinen beschreiben ( )!

TODOs:

  • Fachliche Konstellation finden, die bei TPN nicht durchgeht →   fragt Stefan →
  • erledigt: nehmen pathOS → Widerspruch in Zugsicherungssystemen, die sich gegenseitig ausschließen. Fällt bei BEP-Prüfung in TPN auf. Weitere Alternativen wären: nichtelektrifizierte Strecke und E-Lok, ...
  • Definition der Testfälle im XRay → Â
Reference in New Issue View Git Blame Copy Permalink