Testen im regulierten Umfeld: Worauf es wirklich ankommt
Testen ist in jedem Projekt ein wesentlicher Bestandteil der Qualitätssicherung. In regulierten Industrien wie Pharma, Medizintechnik oder Biotechnologie gilt das in besonderem Masse – und doch wird Testen dort häufig unterschätzt oder zu spät in die Planung einbezogen. Der Grund: Testing im GxP-Umfeld ist weit mehr als das Aufdecken technischer Fehler. Es ist ein regulatorisch geforderter Nachweis, dass ein System seinen vorgesehenen Zweck erfüllt, zuverlässig funktioniert und sicher zu betreiben ist.
Dieser Beitrag zeigt, worauf es beim Testen im regulierten Umfeld wirklich ankommt – von der Teststrategie über den Umgang mit Testdaten bis hin zur auditfähigen Dokumentation und zum Testing im laufenden Betrieb.
Warum Testen im regulierten Umfeld eine eigene Disziplin ist
In klassischen IT-Projekten verfolgt das Testen ein klares Ziel: sicherstellen, dass eine Software technisch korrekt funktioniert. Im regulierten Umfeld kommt eine zweite Dimension hinzu. Testen dient hier nicht nur der Fehlerfindung, sondern ist ein dokumentierter Nachweis gegenüber Behörden und internen Qualitätssystemen, dass ein System die definierten Anforderungen erfüllt.
Im GMP-regulierten Umfeld fordert EU-GMP Annex 11, dass computergestützte Systeme für ihren vorgesehenen Zweck validiert und während ihres gesamten Lebenszyklus kontrolliert betrieben werden. GAMP 5 liefert als anerkannter Industrieleitfaden einen risikobasierten methodischen Rahmen für die praktische Umsetzung. Der ISPE GAMP Good Practice Guide: Testing GxP Systems, Third Edition, konkretisiert diesen Rahmen für die Planung, Durchführung, Dokumentation und Bewertung von Tests im GxP-Umfeld. Testing ist dabei ein zentraler Bestandteil der Computervalidierung, aber nicht die einzige Qualitätssicherungs- und Verifizierungsaktivität. Es wirkt mit Anforderungen, Spezifikationen, Training, Governance und weiteren Kontrollen zusammen.
Wer das Testen unterschätzt oder auf die letzte Projektphase verschiebt, riskiert nicht nur Nacharbeiten und Verzögerungen – sondern im schlimmsten Fall auch Findings bei Audits und Inspektionen.
Die Teststrategie: Grundlage für strukturiertes Vorgehen
Am Anfang steht nicht der erste Testfall, sondern die Teststrategie. Sie legt fest, welche Systeme und Systembestandteile getestet werden müssen, welche Testarten zum Einsatz kommen und in welcher Tiefe das Testing erfolgt.
Eine risikobasierte Vorgehensweise, wie sie unter anderem in GAMP 5 beschrieben wird, ist dabei ein etablierter Ansatz. Grundlage ist ein ausreichendes Verständnis des unterstützten Geschäftsprozesses und der vorgesehenen Systemnutzung. Neben dem möglichen Einfluss auf Produktqualität, Patientensicherheit und Datenintegrität sollten auch Systemkomplexität, Neuartigkeit, Konfigurationsumfang und die Ergebnisse der Lieferantenbewertung berücksichtigt werden.
Eine gute Teststrategie definiert beispielsweise den Testumfang, die geeigneten Testarten, Verantwortlichkeiten, Freigabekriterien und den Umgang mit Abweichungen. Die Form, Detailtiefe und Formalität der Testnachweise sollten dem Risiko, der Komplexität und dem vorgesehenen Einsatz des Systems entsprechen.
Bei SaaS- und Cloud-Lösungen werden bestimmte Test- und Betriebsaktivitäten durch den Dienstleister übernommen. Das regulierte Unternehmen bleibt jedoch dafür verantwortlich, die Eignung der Lösung für den vorgesehenen Zweck und die Einhaltung der relevanten regulatorischen Anforderungen zu bewerten.
Testarten im regulierten Umfeld richtig einsetzen
Die Qualifizierungsstufen IQ, OQ und PQ können je nach System, Lebenszyklusmodell und Validierungsansatz unterschiedliche Schwerpunkte des Nachweises bilden. Testing ist dabei nicht auf ein starres Phasenmodell begrenzt: Auch Tests aus der Entwicklung, von Lieferanten und Integratoren sowie aus Integration, Abnahme und Betrieb können zur Gesamtabsicherung des Systems beitragen.
Installationsqualifizierung (IQ): Nachweis, dass das System beziehungsweise seine technischen Komponenten korrekt installiert und konfiguriert wurden – gemäss den Spezifikationen des Herstellers und den Anforderungen des Unternehmens.
Funktionsqualifizierung (OQ): Hier wird auf Funktionsebene getestet – das System muss nachweislich das tun, was spezifiziert wurde. Einzelne Funktionen, Konfigurationen und Geschäftsregeln werden systematisch geprüft, inklusive Negativtests.
Leistungsqualifizierung (PQ): Hier wird auf Prozessebene getestet – also ob das System im realen Betriebskontext mit relevanten Anwendern, geeigneten beziehungsweise repräsentativen Daten und realitätsnahen Prozessabläufen zuverlässig funktioniert.
Je nach Systemtyp, Projektkontext und eingesetzter Methodik ergeben sich zusätzliche Testschwerpunkte und Testanforderungen.
Testfälle: Qualität vor Quantität
Entscheidend ist nicht, möglichst viele Testphasen oder Testfälle durchzuführen. Wichtig ist vielmehr, dass alle für den vorgesehenen Zweck und die damit verbundenen Risiken relevanten Funktionen angemessen getestet werden. Über alle Testaktivitäten hinweg muss nachvollziehbar bleiben, welche Anforderungen und Risikominderungsmassnahmen durch welche Tests abgedeckt werden. Eine Traceability-Matrix unterstützt dabei.
Testing kann je nach Zielsetzung sowohl scripted als auch unscripted erfolgen.
Beim scripted Testing wird vorab festgelegt, was geprüft wird und wie die Prüfung abläuft. Testvoraussetzungen, einzelne Testschritte und erwartete Ergebnisse sind dokumentiert, sodass die Durchführung reproduzierbar ist und definierte Anforderungen gezielt verifiziert werden können.
Unscripted Testing folgt dagegen keinem vollständig vorgegebenen Ablauf. Die Testperson untersucht das System innerhalb eines definierten Ziels und Scopes flexibel und passt die nächsten Prüfschritte an die bisherigen Beobachtungen an. Dieser Ansatz eignet sich insbesondere dazu, unerwartete Fehler, unklare Bedienabläufe und Schwachstellen aufzudecken.
Beide Ansätze können sich ergänzen. Welche Kombination und welcher Detaillierungsgrad angemessen sind, hängt vom Testziel, der Komplexität des Systems sowie den Risiken für Patientensicherheit, Produktqualität und Datenintegrität ab.
Testfälle, die zu allgemein formuliert sind oder mehrere Prüfpunkte vermischen, erzeugen in der Regel Interpretationsspielraum – und damit Risiken bei der Nachvollziehbarkeit im Audit.
Testumgebung und Testdaten:
oft unterschätzte Erfolgsfaktoren
Die Qualität des Testings hängt massgeblich davon ab, unter welchen Bedingungen getestet wird. Eine Testumgebung, die wesentlich von der Produktivumgebung abweicht, liefert Testergebnisse von begrenzter Aussagekraft. In regulierten Industrien ist deshalb zu dokumentieren, inwieweit die Testumgebung die spätere Produktivumgebung repräsentiert – inklusive Hardware, Softwarekonfiguration und Benutzerkonten.
Ebenso wichtig ist der Umgang mit Testdaten. Produktivdaten sollten nur verwendet werden, wenn dies fachlich erforderlich, risikobewertet und angemessen kontrolliert ist. Je nach Datenart können dafür beispielsweise Anonymisierung oder Pseudonymisierung, geeignete Zugriffsbeschränkungen und eine dokumentierte Freigabe erforderlich sein. Gleichzeitig müssen Testdaten realistisch genug sein, um aussagekräftige Ergebnisse zu liefern.
Datenmigration: Testing als eigenständige Aufgabe
Ein in der Praxis oft vernachlässigtes Testthema ist die Datenmigration. Wann immer im Zuge einer Systemeinführung oder -ablösung Daten aus einem Altsystem in eine neue Umgebung übertragen werden, muss der Migrationsprozess risikobasiert verifiziert werden.
Datenmigrationstests haben die Aufgabe nachzuweisen, dass die migrierten Daten vollständig, korrekt und unverändert beziehungsweise inhaltlich korrekt transformiert im Zielsystem angekommen sind. Dazu gehören sowohl die Prüfung der Datenvollständigkeit als auch die Verifikation der inhaltlichen Korrektheit – insbesondere bei Transformationen in ein neues Datenmodell.
Dokumentation und Testabschluss: Der Nachweis zählt
Im regulierten Umfeld müssen Teststrategie, Testspezifikationen, Testprotokolle, Testbericht und Abweichungen nachvollziehbar dokumentiert werden. Art, Detailtiefe und Formalität der Testdokumentation sollten dabei dem Risiko, der Komplexität und dem vorgesehenen Einsatz des Systems entsprechen. Entscheidend ist, dass die durchgeführten Tests, ihre Ergebnisse und die daraus gezogenen Schlussfolgerungen belastbar nachvollziehbar sind.
Besonders der Testbericht wird in der Praxis oft unterschätzt. Er ist nicht nur eine Zusammenfassung – er enthält die explizite Bewertung, welches Restrisiko nach Abschluss der Tests verbleibt und ob dieses für eine Systemfreigabe akzeptabel ist. Genau hier wird die Verbindung zwischen Testing und Risikomanagement sichtbar.
Alle Dokumente müssen versioniert, freigegeben und über den gesamten Lebenszyklus des Systems aufbewahrt werden. Nachträgliche Änderungen müssen über einen dokumentierten Change-Control-Prozess abgewickelt werden.
Regressionstest und automatisiertes Testing:
Effizienz im laufenden Betrieb
Testen endet nicht mit dem Go-live. Änderungen an einem validierten System sollten im Rahmen des Change-Control-Prozesses auf ihre Auswirkungen auf den validierten Zustand bewertet werden. Diese Bewertung bestimmt, welcher Umfang an Nachverifikation und Regressionstests erforderlich ist.
Gerade bei wiederkehrenden Regressionstests können automatisierte Testwerkzeuge Effizienz und Reproduzierbarkeit verbessern. Ihr Einsatz muss zum System, zum Risiko und zur Teststrategie passen; auch die erzeugten Testnachweise müssen nachvollziehbar dokumentiert werden.
Bei SaaS- und Cloud-Lösungen verschiebt sich der Schwerpunkt zusätzlich auf die laufende Bewertung von Updates, Schnittstellen, Service-Provider-Nachweisen und Verantwortlichkeiten.
Was strukturiertes Testing im regulierten Umfeld auszeichnet
Effektives Testing in Life Sciences, Pharma oder Medizintechnik bedeutet nicht, möglichst viele Testfälle zu produzieren. Es bedeutet, das Testing so zu gestalten, dass es sowohl die Systemqualität sichert als auch den regulatorischen Anforderungen standhält – effizient, nachvollziehbar und auditierbar.
Das gelingt, wenn u.a.:
- Testumfang und Testtiefe risikobasiert festgelegt werden
- Anforderungen, Risiken und Testergebnisse nachvollziehbar miteinander verknüpft sind
- Testumgebung, Testdaten und Datenmigration angemessen berücksichtigt werden
- Testing auch nach dem Go-live als Teil des Systemlebenszyklus verstanden wird
Fazit
Testen im regulierten Umfeld ist kein bürokratischer Mehraufwand. Es ist eine Kernkompetenz, die massgeblich zur Auditierbarkeit, zur regulatorischen Konformität und zur sicheren Freigabe eines Systems beiträgt. Wer Testing als integralen Bestandteil der Systemvalidierung begreift – risikobasiert, strukturiert und über den gesamten Systemlebenszyklus hinweg –, schafft die Grundlage für IT-Systeme, die nicht nur technisch funktionieren, sondern auch den hohen Anforderungen regulierter Industrien dauerhaft gerecht werden.
Gerade hier zeigt sich, was DHC auszeichnet: die Kombination aus tiefem SAP- und IT-Know-how auf der einen und regulatorischer Expertise im GxP-Umfeld auf der anderen Seite. So entsteht ein Testing, das technische Qualität und Compliance-Anforderungen konsequent zusammendenkt – von der ersten Teststrategie bis zum letzten Regressionstest.
Sie planen ein Validierungsprojekt oder stehen vor einer Systemänderung?
Häufige Fragen zum Testmanagement im GxP-Umfeld
Was versteht man unter Testen im regulierten Umfeld?
Im regulierten Umfeld ist Testing ein wesentlicher Bestandteil der Computervalidierung (CSV), aber nicht die einzige Verifizierungs- und Qualitätssicherungsaktivität. Es dient dazu, nachzuweisen, dass ein computergestütztes System für seinen vorgesehenen Zweck geeignet ist und die definierten Anforderungen erfüllt. Dabei werden insbesondere Risiken für Patientensicherheit, Produktqualität und Datenintegrität berücksichtigt. EU-GMP Annex 11 bildet hierfür im GMP-Umfeld einen wichtigen regulatorischen Rahmen; GAMP 5 bietet ergänzend einen anerkannten, risikobasierten Ansatz für die praktische Umsetzung.
Was ist der Unterschied zwischen scripted und unscripted Testing?
Beim scripted Testing werden Testziel, Voraussetzungen, Testschritte und erwartete Ergebnisse vorab festgelegt und dokumentiert. Dadurch lassen sich definierte Anforderungen gezielt und reproduzierbar prüfen.
Unscripted Testing folgt dagegen keinem vollständig vorgegebenen Ablauf. Die Testperson untersucht das System innerhalb eines definierten Ziels und Scopes flexibel und passt die nächsten Prüfschritte an die bisherigen Beobachtungen an. Dieser Ansatz eignet sich besonders, um unerwartete Fehler, unklare Bedienabläufe und Schwachstellen aufzudecken. Auch unscripted Tests müssen nachvollziehbar geplant, durchgeführt und dokumentiert werden.
Warum sind Regressionstests nach Änderungen wichtig?
Warum muss auch die Datenmigration getestet werden?
Was ist beim Testing von SaaS- und Cloud-Lösungen zu beachten?
Bei SaaS- und Cloud-Lösungen werden bestimmte Test- und Betriebsaktivitäten durch den Dienstleister übernommen. Das regulierte Unternehmen bleibt jedoch dafür verantwortlich, die Eignung der Lösung für den vorgesehenen Zweck und die Einhaltung der relevanten regulatorischen Anforderungen zu bewerten.
Wie unterstützt DHC beim Testing im regulierten Umfeld?
DHC begleitet Unternehmen von der Teststrategie über die Erstellung von Testspezifikationen und die Testdurchführung bis hin zur vollständigen, auditfähigen Dokumentation – mit kombinierter Expertise aus SAP-Beratung und GxP-Compliance.