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.
3.4 KiB
Testaktivitäten entlang HF und Releases
Confluence Page ID: 567911916 Version: 4 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen/Testaktivitäten entlang HF und Releases Labels:
Abgrenzung "fachlicher Test vs. Smoketest"
Da es gelegentlich zu Verwirrungen kam, hier eine möglichst einfache Darstellung und Abgrenzung der Themen "fachlicher Test" und Smoketest:
- Fachliche Tests stellen sicher, dass eine Fachlichkeit (in Form einer Story, Bug, whatever) richtig implementiert wurde.
- Smoketests stellen sicher, dass ein Deployment eines Release erfolgreich verlaufen ist und ein Release in der Umgebung grundsätzlich funktioniert. Dies sind fundamental verschiedene Dinge. Zur Verortung und Durchführung dieser Tests:
- Fachliche Tests führen wir i.d.R. nur ein einziges Mal aus. Immer auf der "tiefstmöglichen" Stufe. Das Prinzip ist nicht verhandelbar und auch keine Teamentscheidung - das dahinterstehende Thema "Shift Left" ist für das Value Team und damit auch für den ART Bestellsystem gesetzt.
- Dies bedeutet insbesondere, dass wir Funktionalitäten, die keine Umsysteme benötigen unterhalb der Stufe SIT testen.
- Smoketest hingegen führen wir pro relevanter Umgebung als Teil des Deployments aus. Relevante Umgebungen sind derzeit unsere Abnahmeumgebungen (abn1, abn2, abn4, abn8) und PROD.
Ãberblick über die Testaktivitäten im ART
Wer macht was wo und wie wird das dokumentiert?
| | Was | Teststufe (nach Pyramide) | Wer | Wo | Wann | Automatisiert oder manuell | Dokumentation | | Fachlicher Test von Stories und Bugfixes | KT, KIT, ST | Teams | BASE und IEU Umgebungen | Nach Fertigstellung der Stories (also deutlich vor dem Release) | Automatisiert | Verweis auf automatisierte Testausführungen zu den betroffenen Komponenten in der Releasedoku. | | Fachlicher Test von Stories und Bugfixes | ST | Teams | IEU Umgebungen | Nach Fertigstellung der Stories (also deutlich vor dem Release) | Manuell | Empfehlung: Für den Nachweis im Release: Testfälle im XRay und XRay Test Execution pro Release (z.B. "404-Tests für HF4.8") (â aber: wie das gemacht wird ist hier Teamverantwortung und -entscheidung. Mindestanforderung: Testausführung ist dokumentiert und einfach auffindbar!) Hinweis: automatisierte Tests auf dieser Ebene klar präferiert! | | Fachlicher Test von integrationstestbedürftigen Releaseinhalten mit Nachbarsystemen | SIT | Teams | SIT-Umgebung | Normalfall: nach dem Deployment des Release auf SIT | Manuell | XRay Test Execution des Release/HF (nach Template für SIT Tests) | | Fachliche Mini-Regressionstest mit Nachbarsystemen | SIT | Martin/Jun | SIT-Umgebung | Nach dem Deployment des Release auf SIT | Manuell (noch) | XRay Test Execution des Release/HF (nach Template für SIT Tests) | | Smoketests pro Umgebung (ABNs+PROD) | n.a. | OpsSquad | in jeder ABN- und PROD-Umgebung | Unmittelbar nach Deployment des Release (vor "Fertigmeldung") auf der Umgebung | Manuell (noch) | XRay Test Execution pro Umgebung (nach Template für Smoketests)
Auf den höheren Teststufen gibt es diverse andere Testaktivitäten, die mit dem ART Bestellsystem abgestimmt sind, aber nicht von diesem durchgeführt werden. Hierzu zählen die E2E-Tests im Rahmen des TTT-Programms, aber (indirekt) auch Dinge wie Mentorentests, E2E-Tests mit dem Betrieb etc. pp.