Elektronische Gesundheitskarte und Telematikinfrastruktur

Testkonzept der TI

    

     

      
Version
      
2.6.1
     
     

      
Revision
      
548770
     
     

      
Stand
      
26.06.2020
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemKPT_Test
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das Testkonzept der Telematikinfrastruktur (TI) definiert die Anforderungen an die notwendigen Testmaßnahmen und Rahmenbedingungen für neue oder geänderte Komponenten und Dienste (nachfolgend Produkte) der Telematikinfrastruktur (TI) im Produktivbetrieb.

Über diese Testmaßnahmen müssen die Hersteller der Produkte ihre spezifizierte Funktionalität nachweisen, bevor schrittweise die Integration und übergreifende Nutzung weiterer Produkte vorgenommen wird.

Daher werden die Produkte auf definierte Schnittstellenleistung und Funktionalität getestet sowie Interoperabilitätstests aus Anwendungs- und Gesamtprozesssicht durchgeführt. Diese dienen der vollständigen Abnahme der jeweiligen Produkte und Fachanwendungen.

Das Testkonzept folgt dem Standard des International Software Testing Qualifications Board (ISTQB).

1.2 Zielgruppe

Das Dokument richtet sich an Zulassungs- bzw. Bestätigungsnehmer (Hersteller und Anbieter) von Produkten der TI sowie an die korrespondierenden testspezifischen Rollen. Die Zulassungs- bzw. Bestätigungsnehmer werden in diesem Dokument einheitlich als Zulassungsnehmer bezeichnet. Zu den Anbietern von Produkten zählen hier auch die Betreiber von Fachanwendungsspezifischen Diensten.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zu Testmaßnahmen der Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

1.4 Abgrenzungen

Normative Vorgaben zu Themen, welche nicht nur den Test betreffen, wie z. B. Releasemanagement, Migration, Zulassung und Betrieb, sind nicht Bestandteil dieses Konzepts.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

  <AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=]  angeführten Inhalte.

2 Allgemeine Testvorgehensweise

2.1 Einleitung

Das Ziel der Testaktivitäten ist es, den Nachweis zu erbringen, dass zuzulassende Produkte alle aus den jeweiligen Produkttypsteckbriefen gestellten funktionalen und nichtfunktionalen Anforderungen erfüllen Schwerpunkt sind hier Funktionalität, Sicherheit und Interoperabilität. Die Strukturierung in Testphasen soll die Testprozesse bis in den Produktivbetrieb der Komponenten unterstützen. Um das zu erreichen, wird das Testen in zwei Testphasen (siehe Kapitel 2.4) eingeteilt, die aufeinander aufbauen:

• Eigenverantwortliche Tests der Zulassungsnehmer (Hersteller und Anbieter)
• Zulassungs- bzw. Bestätigungstests der gematik (im Folgenden einheitlich als Zulassungstests bezeichnet)

Die jeweiligen Aktivitäten der Testphasen finden in eigenen Systemumgebungen (siehe Kapitel 3) statt:

• Referenzumgebung: Eigenverantwortliche Tests
• Testumgebung: Zulassungstests der gematik

Durch den Aufbau unterschiedlicher Systemumgebungen werden die Rahmenbedingungen geschaffen, die die einzelnen Teststufen unterstützen (siehe Kapitel 4.5).

Zur Verbesserung der Produktreife im Rahmen der Zulassungstests wird die Eigenverantwortung der Industrie durch Produkttests und produktübergreifende Tests gefordert. Eine Überprüfung der Produktreife erfolgt im Rahmen der Eingangsprüfung in der Testumgebung.

Hersteller und Anbieter von Produkten tragen zur Ende-zu-Ende-Funktionalität bei, da reine Tests der Produktschnittstellen nicht ausreichen, um Interoperabilität zu gewährleisten. Zur Wahrnehmung dieser Verantwortung ist es notwendig, den Herstellern und Anbietern die Möglichkeit zu geben, koordinierte Ende-zu-Ende-Tests durchzuführen.

Die genannten Zusammenhänge werden in der nachfolgenden Abbildung dargestellt.

Abbildung 1: Überblick der Testphasen

2.2 Ablauf für den Nachweis der funktionalen Eignung innerhalb eines Zulassungsverfahrens

In der folgenden Prozessgrafik sind die wesentlichen Prozessschritte beispielhaft dargestellt, die üblicherweise bei Neuzulassung eines Produkts durchlaufen werden.

Abbildung 2: Exemplarischer Ablauf eines Testverfahrens

Die Beschreibung des gesamten Zulassungsverfahrens für das jeweilige Produkt findet sich im gematik-Fachportal in der Verfahrensbeschreibung.

2.3 Testspezifische Rollen

Die betrieblichen Rollen und Akteure werden im spezifischen Betriebskonzept der TI [gemKPT_Betr] definiert. Darüber hinaus gibt es im Rahmen des Testgeschehens spezifische Aufgaben, die die allgemeine Definition ergänzen. Außerdem gibt es zusätzliche Rollen, die nur im Testgeschehen wirksam werden.

Die folgenden Rollen werden im Test wahrgenommen:

• Testkoordinierende Instanz (TKI) RU/TU (gematik)
• Testintegrator zentrale Plattformdienste (TIZP)
  
• Testbetriebsinstanz (TBI) (Anbieter bereits zugelassener Dienste)
  
• testdurchführende Instanz (TDI) RU (Zulassungsnehmer)
• testdurchführende Instanz (TDI) TU (gematik)
• Test- & Transitionmanager (TTM) (gematik)

werden im Anschluss definiert.

Der Anbieter zentrale Plattformdienste (AZPD) hat die Rollen TBI und TIZP inne.

Die folgende Abbildung zeigt einen Überblick des Rollenkonzepts:

Abbildung 3: Rollen innerhalb der Systemumgebungen

2.3.1 Testkoordinierende Instanz (TKI)

Die testkoordinierende Instanz erfüllt den gesetzlichen Testauftrag hinsichtlich § 291b SGB V und hat die übergreifende Koordinationsverantwortung für alle Test- und Wartungsmaßnahmen in der Referenz- und Testumgebung. Die testkoordinierende Instanz hat die übergreifende Verantwortung zur Sicherstellung der qualitäts- und termingerechten Umsetzung aller geplanten Test- und Wartungsvorhaben an Test- und Referenzobjekten.

In diesem Zusammenhang vertritt die testkoordinierende Instanz die Interessen der gematik zur Wahrung des diskriminierungsfreien Zugangs auf die Umgebungen durch Dritte und der gematik selbst. Die Hauptaufgaben der testkoordinierenden Instanz sind:

• Gewährleistung des diskriminierungsfreien Zugangs für alle Zulassungsnehmer
• Koordination von produktübergreifenden Tests
• Eskalative Instanz bei Termin- und Interessenskonflikten seitens der Zulassungsnehmer
• Regelmäßige Abstimmung mit TBI und TDI aller Zulassungsnehmer bezüglich aktueller und geplanter Test- und Wartungsaktivitäten
• Kontrolle der Testbelegungsplanung der Referenzumgebung mittels Test-Kalender
• Bewertung und Kommunikation von Risiken und Problemen an die Beteiligten der jeweiligen Systemumgebung
• Beauftragung von Services beim Testbetriebsverantwortlichen

2.3.2 Testintegrator zentrale Plattformdienste (TIZP)

Der TIZP ist für die Integration von Komponenten, Diensten und weiterer Anwendungen in RU und TU verantwortlich. Er bietet anderen Zulassungsnehmern die Anbindung an die TI an und integriert deren Produkte netztechnisch in die jeweilige Testbetriebsumgebung (RU/TU). Hierzu legt er z.B. IP-Adressen fest und konfiguriert Firewallregeln.

Der AZPD bietet über die Rolle TIZP einen Servicekatalog an, über die die in den Systemumgebungen nutzbaren zentralen Services abgerufen werden können.

2.3.3 Testbetriebsinstanz (TBI)

Die Testbetriebsinstanz für die Referenz- und Testumgebung gewährleistet den Betrieb ihrer jeweiligen Produkte in den Systemumgebungen RU und TU.

Die Verantwortung für die dezentrale Zone liegt bei der gematik (TU) bzw. bei einem von der gematik beauftragten Dienstleister (RU). Die Rolle der TBI wird vom jeweiligen Anbieter bzw. Hersteller des Dienstes oder der Komponente ausgeübt, wie in Abbildung 3: Rollen innerhalb der Systemumgebungen dargestellt.

Sofern in den jeweiligen Produkttypsteckbriefen gefordert wird, dass Services angeboten werden müssen, ist die TBI auch hierfür verantwortlich.

2.3.4 Testdurchführende Instanz (TDI) Referenzumgebung (RU)

Die testdurchführende Instanz der RU plant, steuert und verantwortet die Durchführung von Testmaßnahmen im Sinne der Qualitätssicherung seitens der Zulassungsnehmer. Diese Testmaßnahmen haben zum Ziel, der gematik die Funktionalität, Interoperabilität und Sicherheit in Form von eigenverantwortlichen Tests nachzuweisen. Die testdurchführende Instanz in der Referenzumgebung ist in der Regel der Zulassungsnehmer.

Die testdurchführende Instanz muss eigenverantwortlich die Durchführung von Testmaßnahmen als Qualitätssicherungsmaßnahme im Rahmen weiterer Lieferungen und Leistungen vollziehen (z. B. zur Fehlernachstellung als Wartungsleistung). Sie besitzt die zentrale Ergebnisverantwortung für alle eigenen Testmaßnahmen in der RU.

Testinhalte, -umfang und Testtiefe werden auf Grundlage des aktuellen Produkttypsteckbriefes von der Testdurchführenden Instanz mit dem jeweiligen Test & Transitionmanager der gematik abgestimmt und müssen die funktionalen Anforderungen zunächst vollumfänglich abdecken. Weitere Testdurchläufe können im Rahmen eines Regressionstests in Abstimmung mit dem Test & Transitionmanager der gematik durchgeführt werden.

Die TDI RU trägt die Verantwortung zur Einbindung ihres Produkts in alle Systemumgebungen (RU, TU) als Testobjekt und nach erfolgter Zulassung als Referenzobjekt in alle Systemumgebungen und die Produktivumgebung. Eine Erklärung von Test- und Referenzobjekten folgt in Kapitel 3.2.8 Die Einbringung als Referenzobjekt in alle Systemumgebungen erfolgt über den betrieblichen Changeprozess. Hier kann das ursprüngliche Testobjekt als Referenzobjekt genutzt werden, sobald dieses zugelassen ist.

In der Testphase der Eigenverantwortlichen Tests muss die TDI RU folgende Leistungen erbringen:

• Herstellung der Testbereitschaft inklusive Testdokumentation
• Durchführung der Tests (Gewährleistung der Durchführung aller geforderten Testarten)
• Erstellung eines schriftlichen Testberichts über die eigenverantwortlichen Tests
• Planung aller Testaktivitäten in der RU
• Fachkundige Beratung bei der Planung und Vorbereitung von Tests in der TU
• Unterstützung beim Nachstellen und Analysieren von auftretenden Fehlern in der TU
• Behebung von Fehlern seines Produkts

2.3.5 Testdurchführende Instanz (TDI) TU Testumgebung

Die testdurchführende Instanz der TU wird durch den Test- & Transitionmanager der gematik repräsentiert. Er hat die zentrale Ergebnisverantwortung für alle Testmaßnahmen in der TU für das jeweilige Produkt.

2.3.6 Test- & Transitionmanager (TTM)

Der Test- & Transitionmanager führt den Zulassungsnehmer durch den Prozess der Zulassung und koordiniert die Einbringung der Testobjekte in RU/TU und Bereitstellung der Konfigurationen. Er stellt durch Koordination der Güteprüfung, der Testberichte der TDI RU und der gematik-eigenen Testmaßnahmen in der TU die Qualität der jeweiligen Produkte sicher. Folgende Punkte gehören zu seinen Hauptaufgaben:

• Planung von kostenpflichtigen Diensten oder Konfigurationen für Testmaßnahmen mit der TDI RU
• Beteiligung im CAB und Vorgabe der Testmaßnahmen in den Systemumgebungen
• Prüfung von produkttypspezifischen Testkonzepten und Testfallspezifikationen des Zulassungsnehmers
• Planung und Steuerung der Zulassungstests
• Unterstützung bei der Einbindung der Testobjekte in die Systemumgebungen
• Koordination und Steuerung von Fehlerabsprachen
• Eskalation von Problemen im Zulassungsprozess
• Begleitung des Changeprozesses zur Einbindung der Referenzobjekte in die Systemumgebungen in enger Abstimmung mit den Service Delivery Managern (SDM) der gematik

2.4 Testphasen

Um den Zweck der Aufteilung in die Testphasen zu verdeutlichen, werden die zwei Testphasen durch eine kurze Beschreibung charakterisiert. Die Testziele und die jeweiligen Eingangs- und Ausgangskriterien werden aufgeführt

Eingangskriterien beschreiben Mindestkriterien für den Beginn einer Testphase bzw. deren jeweiligen Teststufen. Erst wenn diese Kriterien erfüllt sind, darf mit einer Testphase begonnen werden. Durch die Definition und Prüfung von Eingangskriterien ist ein effizienter Test in der Testphase gewährleistet.

Ausgangskriterien beschreiben Mindestkriterien für den Abschluss einer Testphase, bzw. deren jeweiligen Teststufen. Erst wenn diese Kriterien erfüllt sind, ist die Testphase beendet um das geforderte Qualitätsniveau zu erreichen.

Wenn Eingangs- oder Ausgangskriterien nicht wie gefordert erfüllt sein sollten, muss eine Risikobewertung vorgenommen und dokumentiert werden. Darin sollen folgende Punkte adressiert werden:

• Auswirkung auf den Zeitplan – z.B. können Teile des Tests erst später (nach Vorliegen der Eingangskriterien) durchgeführt werden? Was sind die Auswirkungen auf den Gesamtplan?
• Auswirkung auf die Qualität der Testergebnisse und des Tests, z.B. können bestimmte Testfälle nicht durchgeführt werden?
• Auswirkung auf die Kosten des Tests, z.B. müssen Testfälle angepasst werden? Müssen Simulatoren entwickelt und eingesetzt werden? Müssen Testfälle mehrfach durchgeführt werden (nach Korrektur von möglichen Fehlern aus den vorigen Testphasen)?

Die Anforderungen für den jeweiligen Produkttyp sind aus dem Produkttypsteckbrief zu entnehmen.

In den nachfolgenden Kapiteln werden die Details zu den Teststufen (Kapitel 4.5), Testarten (Kapitel 2.5), Regressionstest (Kapitel 4.4), Systemumgebungen (Kapitel 3) und Testdokumentation (Kapitel 4) beschrieben.

2.4.1 Eigenverantwortlicher Test

Tabelle 1: Tab_Test_005 Eigenverantwortlicher Test

Die testdurchführende Instanz kann die benötigten Services zum Anbinden des Testobjekts beim TIZP über den Servicekatalog des AZPD buchen.

2.4.1.1 Qualitätssichernde Maßnahmen und Produktmuster

Im Rahmen der eigenverantwortlichen Tests behält sich die gematik folgende qualitätssichernde Maßnahmen vor:

• Anlassbezogene Anforderung eines Produktmusters 6 Wochen vor Beginn der Zulassungstests.
• Weitere anlassbezogene, vom Hersteller oder Anbieter durchzuführende Workshops zur Klärung von Fragen zur Testdokumentation oder Ergebnissen der Testdurchführung
• begleitende Stichproben:
• anlassbezogen bei der Durchführung Eigenverantwortlicher Tests
• der Entwicklungsfortschritte von Produkten

Produktmuster haben folgende Ziele:

• Aktives Risikomanagement
• Validierung der Testfälle vor Beginn der Zulassungstest

Die Bereitstellung des Produktmusters erfolgt je nach Ausprägung durch Lieferung an die gematik oder die frühzeitige Integration in die TU.

Im Rahmen der Produktmustervalidierung erfolgt durch die gematik keine Güteprüfung, Abnahme der Produktmuster oder Verantwortungsübernahme im Sinne der Produktentwicklung.

2.4.2 Zulassungstest

Tabelle 2: Tab_Test_006 Zulassungstest

Die gematik verwendet für die Klassifizierung von Fehlern die folgenden Schweregrade:

Schweregrad „Sehr schwer“: Das betroffene Testobjekt oder eine wesentliche Funktionalität sind nicht nutzbar. Es gibt keine Problemumgehung, um die fehlende oder fehlerhafte Funktion auszuüben. Das Testobjekt kann nicht eingesetzt werden.

Schweregrad „Schwer“: Das betroffene Testobjekt oder eine wesentliche Funktionalität ist nur mit großen Einschränkungen nutzbar. Es besteht die Gefahr von Datenverlust, Speicher- und Performanzproblemen. Es ist jedoch möglich, durch eine Problemumgehung die Funktionalität zur Verfügung zu haben. Das Testobjekt könnte auch dann nur mit Einschränkungen für die Nutzer eingesetzt werden.

Schweregrad „Mittel“: Das betroffene Testobjekt oder eine wesentliche Funktionalität ist nur mit geringfügigen Einschränkungen, welche nicht den Nutzer betreffen, einsetzbar.

Schweregrad „Leicht“: Die gefundenen Mängel haben keine Auswirkungen auf die Funktionalität oder Leistungsfähigkeit des Testobjekts. Das betroffene Testobjekt ist ohne Einschränkungen nutzbar. Es handelt sich um geringfügige Abweichungen, wie z. B. Rechtschreibfehler in Meldungstexten.

2.4.2.1 Testabbruch

Der Zulassungstest kann grundsätzlich in jeder Testphase bzw. Teststufe sowohl durch den Antragsteller als auch durch die gematik abgebrochen werden.
Die gematik behält sich einen Abbruch der Zulassungstests insbesondere vor, wenn abweichende Ergebnisse gegenüber den dokumentierten Ergebnissen zu Eigenverantwortlichen Tests in der RU ermittelt werden oder aus den Ergebnissen der bereits durchgeführten Testfälle hinreichend und objektiv ersichtlich ist, dass das Testobjekt Fehler enthält, aufgrund derer eine Zulassung nicht erteilt werden kann.
Dies ist vor allem dann gegeben, wenn wesentliche Funktionalitäten bzw. Anforderungen nicht, nicht vollständig oder fehlerhaft umgesetzt wurden.
Die gematik wird dem Antragsteller über das Vorliegen von Gründen für einen Testabbruch, einschließlich der Auswertung bis dahin festgestellter Fehler, schriftlich informieren.

2.5 Testarten

Die folgende Abbildung zeigt die Zuordnung der in diesem Kapitel beschriebenen Testarten zu den jeweiligen Testphasen und Teststufen.

Abbildung 4: Zuordnung Testarten

2.5.1 Güteprüfung

Die Güteprüfung ist eine statische Testart der gematik, in welcher die Testdokumentationen der eigenverantwortlichen Tests hinsichtlich Vollständigkeit, formaler und inhaltlicher Korrektheit, Konsistenz und Widerspruchsfreiheit und Nachvollziehbarkeit geprüft werden. Die Ergebnisse werden in einem Güteprüfungsprotokoll dokumentiert. Eine abgeschlossene Güteprüfung ist eine Voraussetzung für den Abschluss der Zulassungstests der gematik.

2.5.2 Funktionstest

Der Funktionstest überprüft, ob die Fachanwendung bzw. die Produkte den funktionalen Anforderungen genügen.

Für die Tests muss es einen definierten Ausgangszustand geben (Testdaten, Systemumgebungseinstellungen). Dieser muss nach einer Anzahl von durchgeführten Tests wiederhergestellt werden können, um eine verlässliche Ausgangsbasis für die Tests zu haben.

2.5.3 Interoperabilitätstest

Das Testziel des Interoperabilitätstests ist der Nachweis der korrekten funktionalen Interaktion der Produkte untereinander. Die Integration erfolgt stufenweise. Für den Interoperabilitätstest werden speziell vier Hauptkategorien unterschieden:

• Ende-zu-Ende-Tests der Anwendungsfälle (Use Cases)
• Fehlersituationen – unter anderem Tests von Fehlercodes, Zeittests, unspezifizierte Fehler
• Ausfalltests – mögliche Auswirkungen von Ausfällen von Produkten auf andere Produkte
• Tests der Public-Key-Infrastructure (PKI) (z.B. Zertifikatsmanagement, Wechsel Vertrauensanker)

2.5.4 Leistungstest

Der Leistungstest beinhaltet die Überprüfung des geforderten Antwortzeit- und Durchsatzverhaltens der in [gemSpec_Perf] definierten Anwendungsfälle. Außerdem wird getestet, ob sich Produkte unter Last beim Ausfall von aufgerufenen Produkten robust verhalten. Im Rahmen des Leistungstests werden Einzelinstanzen oder integrierte Teilsysteme einem Leistungstest unterzogen. Beim Leistungstest des Gesamtsystems unter Einbeziehung der dezentralen Komponenten wird Last auf die zentralen Dienste gelegt und parallel dazu Ende-zu-Ende-Antwortzeiten von Anwendungsfällen an der Schnittstelle Clientsystem – TI gemessen.

3 Systemumgebungen

Für die Tests der Zulassungsobjekte sind die Systemumgebungen „Referenzumgebung“ und „Testumgebung“ vorgesehen. Hierbei wird in einen zentralen und einen dezentralen Bereich unterschieden.

Die folgende Tabelle listet auf, was die Systemumgebungen für die Tests leisten sollen.

Tabelle 3: Tab_Test_001 Überblick Systemumgebungen im Rahmen von Test

Die strikte Trennung von Produktivbetrieb und Testbetrieb bezüglich der Verwendung von Daten ist essentiell. Einerseits muss sichergestellt werden, dass in der Referenzumgebung und in der Testumgebung keine Echtdaten verwendet werden. Es dürfen nur Testdaten und entsprechend auch Testkarten [gemSpec_TK] verwendet werden.

Die Einhaltung dieser strikten Trennung wird durch technische Maßnahmen (z. B. physikalische Trennung der Netze, Einbau von Prüfroutinen für Testkarten) und organisatorische Maßnahmen (z. B. Vorschreiben der Verwendung von Testkarten) sichergestellt.

Produkte müssen im Sinne dieser Trennung ebenfalls für jede Systemumgebung separat bereitgestellt werden. Hierbei sind grundsätzlich folgende Quellen für Mengengerüste zu beachten:

RU: Anzahl der Produkte wird von den Herstellern und Anbietern bzw. der testdurchführenden Instanz der RU verantwortet

TU: Anzahl der Produkte ergibt sich aus der Spezifikation bzw. für dezentrale Produkte aus der Verfahrensbeschreibung der Zulassung

Alle Testmaßnahmen in der Referenz- und Testumgebung werden mit Testdaten durchgeführt. Diese werden von Herstellern, Anbietern und Kartenherausgebern zur Verfügung gestellt, sofern es sich um einen Produkttyp handelt, der Daten in die TI liefert. Das Einbringen von Echtdaten ist in diese Systemumgebungen nicht erlaubt.

Testkarten für die eigenverantwortlichen Tests eines Zulassungsnehmers können über die gematik-Website bestellt werden.

3.1 Testobjekte

Die folgende Grafik gibt eine Übersicht des Gesamtsystems TI und der Verteilung der Produkttypen der TI:

Abbildung 5: Übersicht des Gesamtsystems Telematikinfrastruktur gemäß [gemKPT_Arch_TIP]

Tabelle 4: Tab_Test_019 Produkttypen der TI

Neben den Produkttypen der TI-Plattform sind für die Tests der TI-Plattform ggf. Clientsysteme erforderlich, insbesondere für den Produktübergreifenden Test. Clientsysteme sind dezentrale Systeme (mit Hard- und/oder Software-Bestandteilen), die als Clients mit der TI interagieren, aber selbst nicht als Bestandteil der TI betrachtet werden (z. B. PVS, AVS, KIS, E-Mail- Clients).

3.2 Anforderungen an die Systemumgebungen

In den folgenden Kapiteln sind nach Themengebieten geordnet die Anforderungen aufgeführt, die die Systemumgebungen bzw. die jeweiligen Zulassungsnehmer erfüllen müssen.

3.2.1 Trennung der Netzwerke

3.2.2 Trennung der Vertrauensräume

3.2.3 Gemeinsame Eigenschaften für alle Systemumgebungen

3.2.4 Gemeinsame Eigenschaften der Referenz- und Testumgebung

3.2.5 Exklusiver Zugriff

3.2.6 Logging

Die in diesem Kapitel beschriebenen Anforderungen an ein Logging beziehen sich auf die RU und TU. In diesen Systemumgebungen werden keine Echtdaten verarbeitet. Grundsätzlich sind alle Logging-Daten vertraulich. Eine Weitergabe und die Festlegung der Form der Weitergabe erfolgt ausschließlich durch die gematik.

Sollte das in der Anforderung TIP1-A_7331 angegebene Format nicht verwendbar sein, kann in Absprache mit dem TTM auch ein anderes Format verwendet werden.

3.2.7 Testwerkzeuge

3.2.8 Test- und Referenzobjekte

Referenzobjekte

Als Basis für eigenverantwortliche Tests (RU) und Zulassungstests (TU) sind Abbilder der in der PU vorhandenen Komponenten der TI erforderlich (gleiche Produkttypversion). Diese werden als Referenzobjekte bezeichnet. Gegen sie wird das aktuelle Testobjekt des Zulassungsnehmers getestet. Deren vollständigen Betrieb und die Erbringung des zugehörigen Service Levels verantwortet der jeweilige Anbieter entsprechend [gemRL_Betr_TI]. Referenzobjekte unterliegen den Vorgaben des betrieblichen Changeprozesses und können über den TI-Servicekatalog konfiguriert werden. Anfragen zu Konfigurationen an Fachdienste werden über den Test- und Transitionmanager der gematik gesteuert.

Referenzobjekte können nur in Absprache mit der gematik Simulatoren sein.

Testobjekte

Testobjekte sind Produkte eines Zulassungsnehmers, welche über die Tests in RU und TU eine Zulassung, Bestätigung oder Freigabe der gematik erhalten sollen. Das Einbringen und Herausnehmen aus der jeweiligen Betriebsumgebung (RU/TU) erfolgt über das betriebliche Change Management. In der Referenzumgebung kann ein Testobjekt jederzeit durch den Zulassungsnehmer konfiguriert und/oder angepasst werden. Eigenverantwortliche Tests müssen für alle Beteiligten der RU im Testkalender des TBV sichtbar gemacht werden. In der Testumgebung unterliegt das Testobjekt den Vorgaben des Test- und Transitionmanagers der gematik. Jegliche Anpassungen müssen mit ihm abgestimmt werden.

3.2.9 Referenzumgebung

3.2.9.1 Qualitätssicherungsmaßnahmen der Hersteller und Anbieter

3.2.9.2 Weiterentwicklung der Referenzumgebung

3.2.9.3 Nutzung der Referenzumgebung

3.2.9.4 Instanzen der Referenzumgebung

3.2.10 Testumgebung

3.2.10.1 Bestandteile der Testumgebung

3.2.10.2 Weiterentwicklung der Testumgebung

3.2.10.3 Dimensionierung der Testumgebung

3.2.10.4 Betrieb der Testumgebung

3.2.10.5 Nachstellen von PU-Fehlern in TU

4 Szenarien

4.1 Einleitung

In diesem Kapitel werden zunächst die verschiedenen Szenarien identifiziert unter denen Testmaßnahmen durchgeführt werden müssen. Anschließend werden für jedes Szenario die Rahmenbedingungen und konkrete Anwendung der in Kapitel 2 beschriebenen allgemeinen Testvorgehensweise beschrieben.

Die Unterscheidung nach zentralen und dezentralen Produkten sowie Fachanwendungen erfolgt gemäß Kapitel 3.1.

4.2 Testvorgehensweise im Rahmen der Zulassung eines neuen Produkts

Tabelle 6: Tab_Test_021 Szenario: Zulassung eines neuen Produkts

4.3 Testvorgehensweise im Rahmen der Zulassung eines geänderten Produkts

Tabelle 7: Tab_Test_022 Szenario: Zulassung eines geänderten Produkts

4.4 Regressionstest

Ein Regressionstest stellt fest, ob durch eine durchgeführte Modifikation neue Fehler erzeugt oder (bisher maskierte) Fehler freigelegt wurden und ob bisher positiv durchgeführte Tests weiterhin positiv durchgeführt werden können. Eine Modifikation kann die Installation einer neuen Fachanwendungsversion nach einer Fehlerbehebung, eine Aktualisierung von Produkten (z. B. Datenbank-Updates) sein oder auch Änderungen in den Testtools (Veränderungen an Testtreibern oder Simulatoren) bewirken.

Die für den Regressionstest verwendeten Testfälle sind eine Teilmenge der für das jeweilige Testobjekt geplanten (funktionalen) Testfälle und sollen weitgehend automatisiert durchgeführt werden. Dabei liegt der Schwerpunkt nicht nur auf der funktionalen Verifikation, sondern auch auf der Sicherstellung der richtigen Installation und Konfiguration einer Fachanwendung in der Systemumgebung. Der Regressionstest beinhaltet damit die anderen Testarten Funktionstest, Interoperabilitätstest und Leistungstest.

Nicht geänderte Produkttypen werden geprüft, wenn sie an einem Anwendungsfall beteiligt sind, an dem mindestens ein neuer oder geänderter Produkttyp beteiligt ist. Der Umfang eines Regressionstests richtet sich dabei nach Art, Umfang und Kritikalität der Änderungen. Der Regressionstest muss nicht notwendigerweise alle bereits vorhandenen Testfälle beinhalten, er muss aber mindestens sicherstellen, dass Änderungen keine unerwünschten Auswirkungen auf nicht geänderte Komponenten haben. Dafür ist es notwendig, dass die jeweils verantwortliche testdurchführende Instanz eine entsprechende Auswirkungsanalyse als Grundlage der Regressionstests durchführt.

4.5 Teststufen

Die Teststufen laufen sequentiell ab. Eine Teststufe beginnt erst, wenn die vorherige Teststufe erfolgreich abgeschlossen ist. Dieses Vorgehen erfolgt sowohl bei den Eigenverantwortlichen Tests (EvT) wie auch bei den Zulassungstests (ZulT).

4.5.1 Produkttest (EvT)

Tabelle 8: Tab_Test_008 Produkttest (EvT)

4.5.2 Produktübergreifender Test (EvT)

Tabelle 9: Tab_Test_009 Produktübergreifender Test (EvT)

4.5.3 Eingangsprüfung (ZulT)

Tabelle 10: Tab_Test_010 Eingangsprüfung (ZulT)

4.5.4 Produkttest (ZulT)

Tabelle 11: Tab_Test_011 Produkttest (ZulT)

4.5.5 Produktübergreifender Test (ZulT)

Tabelle 12: Tab_Test_012 Produktübergreifender Test (ZulT)

4.6 Interoperabilität

Um die korrekte funktionale Zusammenarbeit der Produkte untereinander nachzuweisen, müssen im Rahmen der Interoperabilitätstests die anwendungsfallbasierten Tests mit vielen verschiedenen Produktkombinationen durchgeführt werden. Allerdings würde die Abdeckung aller möglichen Produktkombinationen zu einer zeitlich und wirtschaftlich nicht vertretbaren Menge von Tests führen. Somit muss die Interoperabilität mit einer begrenzten, aber fachlich ausreichenden Mindestanzahl von Produkten der beteiligten Produkttypen und anderer am Anwendungsfall beteiligter Komponenten nachgewiesen werden. Nachfolgende Tabelle zeigt für die zuzulassenden oder freizugebenden Produkte die Mindestanzahl der Interoperabilitätspartner. Zum Beispiel müssen für den Konnektor (VSDM) die VSDM-Anwendungsfälle mit mindestens drei verschiedenen eHealth-Kartenterminals und drei Fachdiensten nachgewiesen werden. Es muss dabei aber nicht jedes Kartenterminal mit jedem Fachdienst kombiniert werden.

Die Nutzung von geeigneten Testobjekten kann notwendig sein, wenn zeitgleich Änderungen an mehreren Produkten der TI vorliegen. Grundvoraussetzung für ein geeignetes Testobjekt ist, dass zumindest die korrekte Umsetzung der für den jeweiligen Interoperabilitätstest benötigten Funktionalität(en) im Rahmen von Produkttests erfolgreich nachgewiesen wurde.

Die Angabe der Mindestanzahl geht davon aus, dass ausreichend viele Referenzobjekte bzw. geeignete Testobjekte vorhanden sind. Sollte die geforderte Anzahl nicht zur Verfügung stehen, kann in Abstimmung mit dem TTM gegen eine verringerte Zahl getestet werden.

Tabelle 13: Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung

4.7 Testdokumentation

Zur Dokumentation der Testaktivitäten der verschiedenen Testphasen und Teststufen sollen durch die Hersteller oder Anbieter bzw. die testdurchführende Instanz unterschiedliche Dokumente erstellt werden.

Die Testdokumentation eines Herstellers oder Anbieters soll dabei einheitlich strukturiert sein und alle relevanten Informationen konsolidieren (z.B. von Subunternehmen).

Der genaue Lieferzeitpunkt der Dokumente ist jeweils als Eingangs- bzw. Testausgangskriterium definiert.

4.7.1 Testkonzept

Tabelle 14: Tab_Test_013 Testkonzept

4.7.2 Testspezifikation

Tabelle 15: Tab_Test_014 Testspezifikation

4.7.3 Release Notes

Tabelle 16: Tab_Test_015 Release Notes

4.7.4 Produktdokumentation

Tabelle 17: Tab_Test_016 Produktdokumentation

4.7.5 Testprotokoll

Tabelle 18: Tab_Test_017 Testprotokoll

4.7.6 Testbericht

Tabelle 19: Tab_Test_018 Testbericht

4.8 Serviceprodukte der gematik zur Testunterstützung

Die gematik bietet Zulassungsnehmern eine Reihe von Serviceprodukten an, die für die Entwicklung der Produkte bzw. für die eigenverantwortlichen Tests genutzt werden können. Welches Services dies sind, deren Verfügbarkeit und die Konditionen zu welchen diese genutzt werden können, sind im gematik Fachportal aufgeführt.

5 Fachanwendung VSDM

5.1 Testkarten

Verschiedene Anwendungen, die durch die Telematikinfrastruktur (TI) unterstützt werden, verwenden verschiedene Typen von Smartcards. Zur Unterstützung der Entwicklung von Anwendungen der TI, von Produkten der TI, aber auch in den Zulassungstests werden Testkarten verwendet. Sie weisen eine spezifische Personalisierung auf. Auf den Testkarten personalisierte Zertifikate sind u. a. von einem testspezifischen Vertrauensraum abgeleitet und sind daher grundsätzlich nicht in der produktiven TI einsetzbar. Da Anwendungen häufig das Zusammenspiel verschiedener Smartcards erfordern, wurden Sets verschiedener Testkarten definiert. Die Testkarten-Sets können von der gematik bezogen werden. Der Einsatz physischer Testkarten zu Testzwecken schränkt die Möglichkeiten einer Testautomatisierung ein. Zur Unterstützung der Testautomatisierung können physische Testkarten durch eine Kartensimulation, ggf. durch eine Kartenterminalsimulation ergänzt, ersetzt werden. Die Kartensimulation, mit den respektiven Kartensimulationsimages, kann durch entsprechende Konfiguration die Funktionsweise aller G2-Testkarten (eGK, HBA und SMCs) nachbilden. Für die Fachdienste VSDM wird ein Zusammenspiel von verschiedenen Testkartenarten benötigt (eGK, HBA und SMC-B).

5.1.1 Testkartenausprägungen

Für verschiedene Testmaßnahmen werden unterschiedliche Ausprägungen von Testkarten eingesetzt.

• Physische Testkarten zeichnen sich durch eine spezielle Kunststoffkarte mit eingebautem integriertem Schaltkreis (Chip) aus und werden über ein Kartenterminal angesteuert, um für Testmaßnahmen verwendet zu werden. Daher ist immer ein manueller Steckvorgang erforderlich und eine Verwendung in automatisierten Testabläufen schwierig.
• Virtuelle Testkarten werden u. a. beim Test von Fachdiensten VSDM eingesetzt. Diese Testkarten werden in den Bestandssystemen von Fachdiensten als XML Strukturen in Datenbanken verwaltet und ermöglichen u. a. die Initialisierung von Updates der Versicherten Stammdaten (VSD) auf einer elektronischen Gesundheitskarte (eGK). Virtuelle Testkarten setzen zwingend den Einsatz einer Kartensimulation voraus. Da das manuelle Stecken einer physischen Testkarte entfällt, sind virtuelle Testkarten besonders für automatisierte Testmaßnahmen (z. B. Last-, Performancetests) geeignet. Lasttests erfordern eine hohe Anzahl verschiedener Testkarten, durch den Einsatz virtueller Testkarten kann der Aufwand für den Testaufbau erheblich reduziert werden.
• Kartensimulations-Images für Testkarten sind XML-Strukturen, die eine Voraussetzung für den Einsatz einer Kartensimulation darstellen. Im Zusammenspiel mit virtuellen Testkarten wird eine effiziente Testautomatisierung möglich.
• Kartensimulations-Images können, aufgrund des normativen Formats, auch für Testmaßnahmen zu Card Operating Systemen (COS) und Objektsystemen (eGK, HBA, SMCs) verwendet werden (z. B. in einer frühen Phase von Zulassungstests einer Smartcard), wie auch zur Steuerung und Konfiguration von Testtools eingesetzt werden.

Neben den Ausprägungen weisen Testkarten auch verschiedene Personalisierungen auf, die auch mit spezifischen COS-Ausprägungen einhergehen.

• Testkarten eGK weisen personenbezogene Personalisierungen auf, die sowohl in den VSD als auch in den Zertifikaten Verwendung finden. Die personenbezogenen Daten werden zufällig aus einem Datenpool ausgewählt und dürfen keinen Bezug zu realen Personen haben. Testkarten eGK können mit Institutskennzeichen aktiver Krankenkassen oder einem Institutskennzeichen des GKV-SV personalisiert sein, um in den Testumgebungen der Telematikinfrastruktur (TI) ggf. Fachdienste zu erreichen, die VSD-Updates auf eine Testkarte eGK schreiben können.
• Testkarten SMC-B weisen institutionsbezogene Personalisierungen auf, die in den Zertifikaten Verwendung finden. Die institutionsbezogenen Daten werden zufällig aus einem Datenpool ausgewählt und dürfen keinen Bezug zu realen Institutionen haben.
• Testkarten HBA weisen personenbezogene Personalisierungen auf, die in den Zertifikaten Verwendung finden. Die personenbezogenen Daten werden zufällig aus einem Datenpool ausgewählt und dürfen keinen Bezug zu realen Personen haben.

5.1.2 Testkarten Verwendung

Physische Testkarten werden von verschiedenen Serviceprodukten verwendet, um die Entwicklung von Produkten und Anwendungen für die TI zu unterstützen, können aber auch in Form spezifischer Testkarten Sets Entwicklungstätigkeiten bezogen werden. Physische Testkarten werden auch im Rahmen von Zulassungstests für Produkttests der Fachdienste VSDM, für produktübergreifende und Ende-zu-Ende Tests eingesetzt. Die Testkarten müssen den Anforderungen der Testkartenspezifikation [gemSpec_TK] genügen.

Im Rahmen von Zulassungstests werden in Produkt- und produktübergreifenden Tests der Fachdienste VSDM auch virtuelle Testkarten eGK eingesetzt zum Einsatz, um u. a. Last- und Performancetests mit einer großen Anzahl verschiedener Personalisierungsausprägungen der eGK über einen längeren Zeitraum hinweg durchführen zu können.

Kartensimulations-Images werden für Zulassungstests unterschiedlicher Produkte verwendet, um einen möglichst hohen Testautomatisierungsgrad zu erreichen bzw. mit vereinfachten Testaufbauten arbeiten zu können.

Physische und virtuelle Testkarten wie auch Kartensimulations-Images verwenden für Updates symmetrische und/oder asymmetrische Schlüssel. Ein Dokument zur Schlüsselgenerierung [gemSpec_TK_SG] definiert Algorithmen zur Generierung der verschieden Schlüssel und eröffnet damit Möglichkeiten einer Manipulation von Personalisierungsinhalten der Testkarten ohne Verwendung eines spezifischen Fachdienstes. Sofern Fachdienste für Updates von Testkartenpersonalisierungen zur Verfügung stehen, müssen durch den Fachdienst täglich wechselnde Updates der von ihm verwalteten Testkarten bereitgestellt werden. In physischen Testkarten personalisierte X.509-Zertifikate müssen online vom Trust Service Provider (TSP), der die Zertifikate erstellt hat, prüfbar sein.

5.1.3 Anforderungen an die Testkarten eGK

5.2 Flip/Flop-Verfahren

Um die Kommunikation zwischen testdurchführender Instanz und dem Betreiber des Fachdienstes VSDM zu minimieren, hat sich das sogenannte Flip/Flop-Verfahren bewährt. Der Fachdienst UFS bietet täglich ein Update für verschiedene Testkarten an.

Um in Testverfahren das erfolgreiche Update der VSD auf der eGK nachweisen zu können, werden unterschiedliche Ausprägungen der VSD verwendet.

An geraden Tagen realisiert der Fachdienst VSDD ein Update mit VSD der Variante 1 und an ungeraden Tagen ein Update mit VSD der Variante 2. Nach erfolgreichem Abschluss des jeweiligen Updates der VSD auf der eGK löscht der UFS die Update-Information.

Die Funktionalität des Fachdienstes CMS wird durch Sperren und Entsperren der Gesundheitsanwendung (DF.HCA) überprüft.

Im Kontext der Implementierung und Umsetzung des Flip/Flop-Verfahrens ergeben sich die nachfolgend aufgeführten Anforderungen.

5.3 Umgang mit mandantenfähigen Fachdiensten

Betreiber der Fachdienste VSDM können auch mehrere Anbieter von eGK unterstützen. Da die Eigenschaften der eGK auch die Zugangswege durch die Telematikinfrastruktur zum Fachdienst beeinflussen, muss jeder Anbieter von Fachdiensten Testkarten bereitstellen und durch den Betreiber seiner Fachdienste verwalten lassen.

Betreiber mandantenfähiger Fachdienste müssen mindestens zwei Testkartensätze (siehe Kapitel 5.1) unterschiedlicher Anbieter (Mandanten) verwalten und für Testmaßnahmen das Flip/Flop-Verfahren aktivieren.

Im Produkttest bleiben Tests zur Mandantenfähigkeit auf 2 Mandanten beschränkt. Allerdings müssen im produktübergreifenden Test für jeden Mandanten eines Fachdienstes mindestens 2 Testkarten verwaltet und das Flip/Flop-Verfahren für Testmaßnahmen aktiv sein.

Grundsätzlich soll jeder Anbieter von Fachdiensten mindestens einen Testkartensatz für Testmaßnahmen zur Verfügung stellen, um ggf. mehrere testdurchführende Instanzen bei der Testdurchführung zu unterstützen.

5.4 Testdurchführung der EvT bei VSDM

Das Testportal bietet eine zusätzliche Qualitätssicherung und entbindet den Hersteller nicht vom Testen der korrekten Funktionalität nach Anforderungslage. Für Anforderungen, für die es im Testportal Testfälle gibt, werden allerdings keine gesonderten Nachweise verlangt.

6 Fachanwendung AdV

Für die Produkttests der AdV (Anwendungen der Versicherten) und für produktübergreifende Tests werden Testkarten (physische eGK) eingesetzt. Die Testkarten müssen den Anforderungen der eGK-Testkartenspezifikationen [gemSpec_TK_FD, gemSpec_TK] genügen, von den Fachdiensten der Anwendung VSDM mit Updates versorgt werden können und auf der Testkarte personalisierte X.509-Zertifikate müssen online gegen einen Trust Service Provider (TSP) prüfbar sein.

Es können die für die Fachdienste VSDM bereitgestellten Testkartensätze genutzt werden.

Die Afo wird benötigt, um beim Test des VSDM Anwendungsfalls mit virtuellen Karten zu arbeiten.

7 Fachanwendung ePA

Für die Testbarkeit der Fachanwendung ePA ist es notwendig, dass die Hersteller die folgenden Anforderungen erfüllen.

7.1 ePA-Aktensystem

Eine mögliche Realisierung der Anforderung würde z.B. darin bestehen, dass der Hersteller des Aktensystems in regelmäßigen Zeitintervallen (z.B. alle 2h) ein mit der TDI der TU definiertes Backup bzw. einen Snapshot wiederherstellt. Auch der definierte Inhalt eines Aktenkontos soll zusammen mit der TDI der TU festgelegt werden.

Hinweis: Dazu zählen auch von der gematik erstellte Testkarten.

Für Zulassungen des ePA-Aktensystems in der Version 1 können Hersteller bis zum 31.12.2020 eine Zulassung erhalten, ohne die von der gematik zur Verfügung gestellten Testfälle durchgeführt zu haben. In diesem Fall müssen die Hersteller eigene Testfälle für die ggf. fehlenden Nachweise entwickeln und durchführen.

Das Testportal bietet eine zusätzliche Qualitätssicherung und entbindet den Hersteller nicht vom Testen der korrekten Funktionalität nach Anforderungslage. Für Anforderungen, für die es im Testportal Testfälle gibt, werden allerdings keine gesonderten Nachweise verlangt.

7.2 ePA-Modul Frontend des Versicherten

Im Rahmen der Testphase Eigenverantwortlicher Test muss der Hersteller eines ePA-Modul Frontend des Versicherten auch Tests mit einem von der gematik zur Verfügung gestellten Aktensystem-Simulator durchführen. Die mit diesem Simulator durchgeführten Testfälle können als Nachweis der Anforderungserfüllung der eigenverantwortlichen Tests genutzt werden. Die Liste der Anforderungen, die durch den Einsatz des Aktensystem-Simulators für die EvT genutzt werden können, ist im Produkttypsteckbrief des Frontend des Versicherten zu finden.

7.3 Basis-Consumer/KTR-Consumer

Für die Testbarkeit eines Basis- oder KTR-Consumers muss der Hersteller dieses Produkttyps die folgende Anforderung erfüllen.

7.4 Signaturdienst

Für die Testbarkeit eines Signaturdiensts muss der Hersteller dieses Produkttyps die folgende Anforderung erfüllen.

7.5 Schlüsselgenerierungsdienst

Für die Testbarkeit eines Schlüsselgenerierungsdienstes muss der Hersteller dieses Produkttyps die folgenden Anforderungen erfüllen.

8 Weitere Anwendungen

Die Anbieter weiterer Anwendungen (anderer Anwendungen des Gesundheitswesens (aAdG) oder anderer Anwendungen des Gesundheitswesens mit Zugriff auf Dienste der TI aus angeschlossenen Netzen des Gesundheitswesens (aAdG-NetG-TI)) durchlaufen die in den vorherigen Kapiteln genannte Testvorgehensweise nur teilweise, da sie selbst keine Erfüllung der von der gematik erstellten Spezifikationen nachweisen müssen. Sie müssen allerdings nachweisen, dass die Services bzw. Komponenten, die sie von der TI nutzen keine negativen Auswirkungen auf dieselben haben – den sogenannten Schnittstellentests.

Der Anbieter einer weiteren Anwendung hat die Möglichkeit für eigene Tests die Referenzumgebung der gematik zu nutzen. Die Koordination für den Zugang übernimmt auf Seiten der gematik der Test- & Transitionmanager.

8.1 Vorbereitung der EvT zur funktionalen Eignung

Vor Beginn der EvT in der RU ist eine Freischaltung des Serviceportals und des Testumgebungskalenders RU erforderlich. Die Freischaltung eines Zugangs zum Testkalender und zum Serviceportal der RU wird vom TTM veranlasst. Der Eintrag der geplanten Testzeiträume in den Testkalender der RU wird vom jeweiligen Antragssteller selbst durchgeführt. Der TTM führt den Bestätigungsnehmer durch die notwendigen Prozesse und unterstützt den Anbieter weiterer Anwendungen beim Zugang zur RU.

8.2 Durchführung EvT zur funktionalen Eignung

Durch den Bestätigungsnehmer ist die erforderliche Testspezifikation inkl. der Testfallspezifikationen zu erstellen und die Testdurchführung in Testprotokollen und einem Testbericht zu dokumentieren. Eine Orientierungshilfe für die Ausgestaltung der Testfallspezifikation ist im Anhang B des Testkonzepts zu finden. Für den Testbericht stellt die gematik ebenso ein Template im Anhang B zur Verfügung.

Die Dokumente werden durch die gematik einer Güteprüfung unterzogen.

8.3 Schnittstellentests in der TU

Voraussetzung für den Start der Schnittstellentests durch die gematik ist eine vollständige Installation und Konfiguration des Testobjekts durch den Anbieter der weiteren Anwendung.

Nach Durchführung der Schnittstellentests wird das Ergebnis in einem Testbericht dokumentiert. Dieser Testbericht dient bei einem positiven Ergebnis als Nachweis der funktionalen Eignung des Produkts und wird an die Zulassungsstelle der gematik übergeben.

Tabelle 20: Tab_Test_005 Eigenverantwortlicher Test

Tabelle 21: Tab_Test_007 Bestätigungstest

Der Anbieter Anderer Anwendungen des Gesundheitswesens (aAdG) oder Anderer Anwendungen des Gesundheitswesens mit Zugriff auf Dienste der TI aus angeschlossenen Netzen des Gesundheitswesens (aAdG-NetG-TI) muss die Testaktivitäten in der Testumgebung im Bestätigungsverfahren unterstützen. Dies kann bspw. das Auslösen eines bestimmten Events in seiner Anwendung sein, sodass die gematik auf Seiten der TI das richtige Verhalten der Anwendung nachvollziehen kann.

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

Ein umfangreiches Glossar findet sich im Fachportal der gematik-Website.

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

9.5.2 Weitere Dokumente

10 Anhang B – Beispielhafte Testdokumentation

In diesem Kapitel werden die Anforderung an die Testdokumentation durch Beispiele ergänzt und ein möglicher Ansatz zur Beschreibung des Testvorgehens vom Testkonzept über die Testspezifikation bis zum Testbericht erläutert.

10.1 Testkonzept

Die folgende Tabelle zeigt eine mögliche Vorlage zur Übersicht der zu testenden Leistungsmerkmale eines Produkttyps sowie die Zuordnung zu den Prüfverfahren und einem oder mehreren Testfällen. Auf Grund des unterschiedlichen Umfangs und Komplexität der Anforderungen oder Anwendungsfälle kann es notwendig sein, diese zunächst in Teilaspekte zu zerlegen welche jeweils durch Testfälle abgedeckt werden. Das Ziel hierbei ist es, eine Rückverfolgbarkeit zwischen den zu testenden Leistungsmerkmalen und den zugeordneten Testfällen herzustellen. Des Weiteren sollte beschrieben werden, welche Leistungsmerkmale nicht geprüft werden.

Tabelle 22: Tab_Test_023 Vorlage Testkonzept

Die folgende Tabelle zeigt die exemplarische Übersicht von ausgewählten Anforderungen und zugeordneten Testfällen zu konkreten Anforderungen aus ORS1.

Tabelle 23: Tab_Test_024 Beispiel Testkonzept

* Zu den Testfällen TF_00001, TF_00003, TF_00004, TF_00005 und TF_00023 sind im folgenden Abschnitt mögliche Testfallspezifikationen beschrieben.

10.2 Testspezifikation

Die folgende Tabelle zeigt eine mögliche Vorlage zur Spezifikation eines Testfalls.

Tabelle 24: Tab_Test_025 Vorlage Testfallspezifikation

Die folgenden Tabellen zeigen die exemplarische Beschreibung von ausgewählten Testfällen zu konkreten Anforderungen aus ORS1.

Good Practice: Bei der Spezifikation von TF_00004 wird beim erwarteten Ergebnis von Schritt 4 explizit eine Return Message aus bereits ermittelten Parametern zusammengebaut – es ist explizit klar was genau in jedem Feld steht (entsprechend der Standardkonfiguration) und kann geprüft werden.

Tabelle 25: Tab_Test_026 Beispiel Testfall 1

Good Practice: Bei der Spezifikation von TF_00005 werden vorher mitgetrackte Werte später wieder verwendet, z.B. beim erwarteten Ergebnis von Schritt 4.

Tabelle 26: Tab_Test_027 Beispiel Testfall 2

Good Practice: Bei der Spezifikation von TF_00023 wird in den Vorbedingungen noch mal explizit auf den Parameter der Standardkonfiguration aufmerksam gemacht, der für diesen Testfall der wichtige ist.

Tabelle 27: Tab_Test_028 Beispiel Testfall 3

Good Practice: Bei der Spezifikation von TF_00001 ist der Weg zum Teststatus explizit gemacht – manchmal ist es wichtig wie ein Status erreicht wurde, weil das für den Testablauf wichtig werden kann, weil interne Parameter die dabei gesetzt wurden Änderungen in Verhalten bewirken können, zudem wird insbesondere der TUC der mit dieser Frontend Funktion abgeprüft wird explizit gemacht (und man kann da weiterprüfen).

Tabelle 28: Tab_Test_029 Beispiel Testfall 4

Good Practice: Bei der Spezifikation von TF_00003 werden Verbindungsschritte explizit gemacht, so dass Logs genauer daraufhin geprüft werden können, ob der Weg zu einen Zustand auch korrekt ist.

Tabelle 29: Tab_Test_030 Beispiel Testfall 5

Die folgende Tabelle zeigt eine mögliche Spezifikation der in den Testfällen referenzierten Basiskonfigurationen:

Tabelle 30: Tab_Test_031 Beispiel Testkonfiguration

10.3 Testprotokoll

Die folgende Tabelle zeigt eine mögliche Vorlage zur Dokumentation der Testergebnisse durch ein Testprotokoll:

Tabelle 31: Tab_Test_032 Vorlage Testprotokoll

10.4 Tabelle umzusetzender Anforderungen

Die folgende Tabelle zeigt, in welcher Art und Weise eine Auflistung der umgesetzten bzw. nicht umgesetzten SOLL/SOLL NICHT/KANN - Anforderungen erwartet wird.