A_26673 - Testumgebung in der Produktentwicklungsphase

Der Hersteller des PoPP-Service MUSS in der Produktentwicklungsphase das Testobjekt in der Vorintegrationsumgebung RU DEV bereitstellen, um Tests für die Kontrollpunkte unter [A_26676] zu ermöglichen. 
[<=]

A_26674 - Bereitstellung von Testkomponenten und Testartefakten in den Testumgebungen

Der Hersteller des PoPP-Service MUSS das Testobjekt und Testartefakte so entwickeln und bereitstellen, dass diese in allen Testumgebungen genutzt werden können.
[<=]

A_26675 - Format der Testszenarien

Der Hersteller des PoPP-Service MUSS alle für den funktionalen Test erforderlichen Testszenarien und Testfälle nach der Behavior Driven Development (BDD)-Technik erstellen und z. B. in der Beschreibungssprache "Gherkin" formulieren.
[<=]

A_26676 - Kontrollpunkte während der Entwicklungsphase

Der AN MUSS die von der gematik vorgegebenen Kontrollpunkte während der Entwicklungsphase durchführen. Dadurch wird die Reife und der Fortschritt der in Entwicklung befindlichen Produktkomponenten überprüft.

[<=]

A_26677 - Herstellerspezifische Kontrollpunkte

Der Hersteller des PoPP-Service KANN weitere Kontrollpunkte in seinem Qualitätsprozess vorsehen und umsetzen. In diesem Fall KÖNNEN die Testergebnisse in einer von der gematik bereitgestellten Datenaustauschplattform abgelegt werden.
[<=]

A_27393 - Bereitstellung als signiertes OCI konformes Image

Der Hersteller des PoPP-Service MUSS jedes Release des Testobjektes als signiertes OCI konformes Image gemeinsam mit der Konfigurationsanleitung zur Integration in die gemeinsame RU DEV Umgebung liefern. [<=]

A_27394 - Agiler Bereitstellungsprozess

Um die Stabilität der gemeinsamen RU DEV Umgebung zu gewährleisten, MUSS der Hersteller des PoPP-Service sich an folgendem agilen Prozess halten.

1. Änderungsmanagement: Der Hersteller des PoPP-Service DARF Modifikationen an den Komponenten ausschließlich innerhalb der dafür vorgesehenen Zeitfenster zwischen den durch gematik festgelegten Sprints vornehmen.
2. Flexibilität bei der Bereitstellung: Der Hersteller des PoPP-Service MUSS das aktuelle Bereitstellungsfenster überspringen, wenn das Testobjekt noch keinen stabilen Status erreicht hat.
3. Automatisierte Qualitätssicherung: Nach dem Schließen des Änderungszeitfensters werden in der RU DEV Umgebung über Nacht automatisierte E2E-Tests ausgeführt. Diese haben zum Ziel, potenzielle Probleme in den Komponenten zu identifizieren, die möglicherweise negative Auswirkungen auf die Tests anderer Hersteller haben könnten.
4. Fehleranalyse-Phase: Der Hersteller des PoPP-Service MUSS während der Testdurchführung aufgetretene Fehler, nach der Bereitstellung analysieren, um die betroffenen Komponenten zu identifizieren. Die gematik legt die Länge der Fehleranalyse-Phase anlassbezogen fest.
5. Rollback: Der Hersteller des PoPP-Service MUSS das Testobjekt am Ende der Fehleranalyse-Phase auf die letzte bekannte, fehlerfreie Version zurückzusetzen, falls Fehler im Testobjekt festgestellt wurden, welche die Integrität des Gesamtsystems gefährden. Der Hersteller des PoPP-Service MUSS die festgestellten Fehler im Testobjekt in den nächsten Sprints beheben.
6. Abschluss der Änderungen: Nach dem Rollback prüft die automatisierte Qualitätssicherung erneut, ob die Stabilität der gemeinsamen Umgebung gewährleistet ist. Sollte dies nicht der Fall sein, werden die Schritte 4 bis 6 solange überprüft, bis die gemeinsame Umgebung die notwendige Stabilität erreicht.

Durch diese strukturierte Vorgehensweise wird eine hohe Systemstabilität gewährleistet und gleichzeitig die notwendige Flexibilität für kontinuierliche Verbesserungen und Anpassungen ermöglicht.
[<=]

A_26684 - Freie Nutzung der entwickelten Testartefakte

Der Hersteller des PoPP-Service MUSS alle Testartefakte, die für die Testaktivitäten vom Hersteller entwickelt werden, der gematik Kosten- und Lizenzfrei zur Nutzung und Weiterentwicklung zur Verfügung stellen.
[<=]

A_27053 - Freie Nutzung der erworbenen Testartefakte

Der Hersteller des PoPP-Service MUSS alle Testartefakte, die für die Testaktivitäten von Dritten erworben werden, der gematik Kosten- und lizenzfrei zur Nutzung zur Verfügung stellen.
[<=]

A_26685 - Automatisierung der Testartefakte

Der Hersteller des PoPP-Service MUSS alle Testartefakte so entwickeln und bereitstellen, dass diese eine kontinuierliche, automatisierte Testausführung ermöglichen.
[<=]

A_26686 - Verwendbarkeit von Testkomponenten und Testartefakten in automatisierten CI/CD-Pipelines

Der Hersteller des PoPP-Service MUSS ausführbare Testartefakte so entwickeln und bereitstellen, dass sie in automatisierten CI/CD-Pipelines verwendet werden können.
[<=]

A_26688 - Labeln von Komponenten

Der Hersteller des PoPP-Service MUSS seine Komponenten mit einem zur Umgebung gehörenden Label versehen. Dadurch sollen Komponenten im Produktlebenszyklus eindeutig identifiziert werden, ob sie in der TU oder PU eingesetzt werden dürfen.
[<=]

A_26689 - Keine Hardware-Abhängigkeiten bei Komponenten in Testumgebungen

Der Hersteller des PoPP-Service MUSS seine Komponenten so entwickeln und bereitstellen, dass keine Hardware-Abhängigkeiten, z. B. zu einem HSM entstehen. Dies kann z. B. durch den Einsatz von Simulatoren oder Mocks erreicht werden.
[<=]

A_26690 - Nutzung von Private oder Secret Keys in Testumgebungen

Der Hersteller des PoPP-Service MUSS in Testumgebungen sicherstellen, dass die verwendeten Private oder Secret Keys bekannt sind.
[<=]

A_27100 - Übergreifende Testmaßnahmen

Der Hersteller des PoPP-Service MUSS bei der Vorbereitung und Durchführung von übergreifenden Testmaßnahmen, wie z. B. Durchstichtests oder Connectathons, auch nach der Zulassung auf Aufforderung des AG mitwirken, z. B. durch Bereitstellung und Konfiguration der benötigten Komponenten und Testumgebungen oder Unterstützung bei der Problemanalyse. [<=]