Inhaltsverzeichnis
Das Wichtigste vorab
Wie lässt sich der Regressionstestumfang begründen?
Leiten Sie Regressionstests aus Änderung, vorgesehenem Einsatz, möglichen Fehlerfolgen und Abhängigkeiten ab. Berücksichtigen Sie auch unveränderte Funktionen, wenn sie von der Änderung beeinflusst werden können. Bestehende Evidenz darf weiter tragen, wenn ihre Eignung für den neuen Stand begründet ist. Eine feste Testquote, ein universeller Vollretest oder der bloße Hinweis auf eine GAMP-Kategorie ersetzt diese Bewertung nicht.
- Geänderter Code und betroffener fachlicher Prozess sind nicht deckungsgleich.
- Nicht erneut geprüfte Funktionen brauchen eine nachvollziehbare Abgrenzung.
- Ein bestandener Einzeltest belegt seinen Prüfumfang, nicht automatisch die gesamte Änderung.
1. Regression beantwortet eine andere Frage als der Änderungstest
Der Änderungstest zeigt, ob die beabsichtigte neue Funktion funktioniert. Ein Regressionstest untersucht, ob bereits benötigtes Verhalten durch die Änderung unerwünscht beeinträchtigt wurde. Beide können sich im selben Testfall verbinden, müssen aber in der Abdeckungsentscheidung erkennbar sein.
Für Humanarzneimittel-GMP bilden insbesondere Annex 11 mit Validierung und kontrollierten Änderungen sowie ICH Q9(R1) den fachlichen Rahmen. GAMP unterstützt einen risikobasierten Lebenszyklusansatz. Die hier verwendeten öffentlichen ISPE-Unterlagen sind keine vollständige Wiedergabe des kostenpflichtigen GAMP-Leitfadens und begründen keine erfundene Pflicht zu einer bestimmten Testtechnik.
2. Vom technischen Änderungsumfang zum fachlichen Datenweg gehen
Ein Importbaustein kann von mehreren Workflows verwendet werden. Eine geänderte Bibliothek kann Funktionen beeinflussen, deren eigener Code unangetastet bleibt. Umgekehrt kann eine sauber getrennte Funktion außerhalb des tatsächlichen Wirkbereichs liegen. Deshalb ist die Aussage „Diese Maske wurde nicht geändert“ noch keine ausreichende Abgrenzung.
Erfassen Sie die relevanten Abhängigkeiten von Eingangsdaten, Konfiguration und Verarbeitung bis zur fachlichen Verwendung. Dazu gehören gegebenenfalls Rollen, Schnittstellen und Fehlerbehandlung. Die folgende eigene Matrix macht die begründete Auswahl prüfbar; sie schreibt keine universelle Dokumentenform vor.
| Bereich | Mögliche Auswirkung | Test- beziehungsweise Nachweisentscheidung |
|---|---|---|
| Geänderter Zahlenimport | Dezimaltrennzeichen wird falsch interpretiert | Neue und bisherige zulässige Formate gezielt testen |
| Unveränderte Berechnung | Falscher Eingangswert erzeugt falsches Ergebnis | Fachlichen Rechenweg mit importiertem Wert prüfen |
| Unveränderter Bericht | Andere Formatierung oder falscher Datenstand | Relevante Ergebnisdarstellung mitprüfen |
| Fehlerbehandlung | Ungültiger Wert wird still zu null | Negativfall mit definierter Reaktion prüfen |
| Berechtigungen | Änderung beeinflusst gemeinsamen Workflow | Abhängigkeit klären; relevante Kontrolle gegebenenfalls testen |
| Getrennter Versandprozess | Kein gemeinsamer Baustein oder Datenweg nachgewiesen | Nichtwiederholung mit konkreter Abgrenzung begründen |
3. Unsicherheit ist ein Auswahlgrund, kein Niedrigrisiko-Beleg
Bewerten Sie mögliche Fehlerfolgen und die Verlässlichkeit Ihrer Informationen. Ein unbekannter gemeinsamer Baustein ist nicht automatisch unkritisch, nur weil bisher kein Fehler gemeldet wurde. Fehlende Einsicht kann zusätzliche Klärung oder geeignete Prüfungen erfordern.
ICH Q9(R1) verbindet den angemessenen Grad an Formalität unter anderem mit Unsicherheit, Bedeutung und Komplexität. Ressourcenknappheit allein rechtfertigt keine niedrige Einstufung. Das bedeutet nicht, jede Unsicherheit mit einem pauschalen Volltest zu beantworten; es bedeutet, die tatsächliche Nachweislücke bewusst zu behandeln.
4. Eigener Prüffall: Der Wert 1,25 darf nicht zu 125 werden
Illustratives Beispiel: Eine fiktive Importfunktion wird geändert. Das definierte Soll erlaubt die Dezimaldarstellungen „1,25“ und „1.25“ in den jeweils vorgesehenen Eingabeformaten. Der fachliche Folgeschritt multipliziert den interpretierten Wert mit 80. Erwartet wird 100. Ein Fehler, der das Komma entfernt und 125 einliest, erzeugt dagegen 10.000.
Die unten definierte Fehlerreaktion ist Bestandteil dieses konstruierten Solls: Eine leere oder nichtnumerische Pflichtangabe wird zurückgewiesen und erzeugt kein fachlich verwendbares Ergebnis. Dies ist keine pauschale Produktfunktion oder universelle Vorgabe für sämtliche Importprozesse. Der Test muss tatsächliches Verhalten und erforderlichen Datenbezug belegen.
| Prüffall | Eingabe und Voraussetzung | Erwartetes Ergebnis | Nachweiszweck |
|---|---|---|---|
| Neues zulässiges Format | 1,25 im Kommaformat; Faktor 80 | 1,25 × 80 = 100 | Beabsichtigte Änderung |
| Bisheriges zulässiges Format | 1.25 im Punktformat; Faktor 80 | 1,25 × 80 = 100 | Bestehendes Verhalten bleibt geeignet |
| Unveränderte Folgefunktion | Importierter Wert 1,25; Berechnung unverändert | Bericht zeigt 100 mit richtigem Recordbezug | Fachliche Abhängigkeit geprüft |
| Leere Pflichtangabe | Kein Zahlenwert | Zurückweisung; kein verwendbares Ergebnis | Keine stille Umwandlung in 0 |
| Nichtnumerische Pflichtangabe | abc | Zurückweisung; kein verwendbares Ergebnis | Fehlerbehandlung |
| Zu erkennender Fehler | Komma wird entfernt; Wert 125 | 10.000 statt 100 | Test muss Abweichung erkennen |
5. Vorhandene Belege gezielt weiterverwenden
Nicht jeder bestehende Nachweis verliert durch eine Änderung automatisch seine Aussagekraft. Prüfen Sie jedoch, ob Version, Konfiguration, Umgebung und fachlicher Anwendungsfall weiterhin passen. Ein Herstellerbericht kann relevante Standardfunktionen abdecken, aber nicht ohne Prüfung jede kundenspezifische Kombination.
Dokumentieren Sie, welche Belege weiter tragen und wo neue Evidenz erforderlich ist. Eine alte bestandene Prüfung beweist nicht, dass eine neu betroffene Funktion unverändert arbeitet. Ebenso ist das Alter eines Belegs allein kein Grund, ihn ohne fachliche Betrachtung vollständig zu ersetzen.
6. Tests so ausführen, dass ihre Aussage verständlich bleibt
Der relevante Systemstand und die verwendeten Testdaten müssen erkennbar sein. Ein erwartetes Ergebnis ohne unabhängige fachliche Grundlage kann denselben Fehler wie die Anwendung enthalten. Im Beispiel wird die Rechnung deshalb unabhängig vorgegeben und nicht aus dem beobachteten Systemwert abgeleitet.
Öffentliche ISPE-Unterlagen erläutern unterschiedliche Testansätze und kritisches Denken. Daraus folgt kein Verzicht auf nachvollziehbare Ergebnisse. Automatisierte und untersuchende Verfahren können geeignet sein, wenn Zweck, tatsächliche Durchführung und relevante Befunde belastbar erkennbar bleiben. Die Methode ist ein Mittel zur Evidenz, nicht deren Ersatz.
7. Abdeckung und verbleibende Unsicherheit gemeinsam entscheiden
Fassen Sie zusammen, welche Wirkbereiche geprüft, durch geeignete bestehende Belege abgedeckt oder begründet ausgeschlossen wurden. Offene Befunde müssen hinsichtlich ihrer Auswirkung bewertet werden. Ein grüner Importtest darf eine unklare Berichtsausgabe nicht überdecken.
Die weitere Verwendung des geänderten Systems richtet sich nach dem kontrollierten Änderungsverfahren und den zuständigen Rollen. Es gibt hier kein universelles Unterschriftenschema für jede Änderung. Der Umfang der Prüfung kann auch während der Arbeit wachsen, wenn neue Abhängigkeiten oder Fehler sichtbar werden.
8. Checkliste für eine begründete Regressionstestauswahl
Eine kurze nachvollziehbare Auswahlbegründung ist hilfreicher als ein umfangreicher Testordner ohne erkennbaren Bezug zur Änderung. Die fachliche Reichweite muss sich aus dem tatsächlichen System ergeben, nicht aus einer beliebigen Prozentvorgabe.
Die folgende eigene Arbeitshilfe ergänzt Ihr Änderungsverfahren. Sie ist kein festes GAMP-Testpaket und keine Garantie, dass jede mögliche Störung erkannt wird.
- Änderung und beabsichtigtes Verhalten klar beschrieben.
- Gemeinsame Komponenten, Datenwege und Konfiguration berücksichtigt.
- Mögliche Auswirkungen auf unveränderte Funktionen geprüft.
- Kritische Fehlerfolgen und Unsicherheiten benannt.
- Weiterhin geeignete bestehende Evidenz zugeordnet.
- Neue Positiv-, Grenz- und Fehlerfälle passend ausgewählt.
- Nichtwiederholung konkreter Bereiche nachvollziehbar begründet.
- Befunde, verbleibende Unsicherheit und weitere Verwendung entschieden.
Häufige Fragen zu GAMP 5: Regressionstests
Muss nach jedem Update das gesamte System erneut getestet werden?
Nicht pauschal. Der Umfang folgt aus Änderung, Abhängigkeiten und Risiken. Bei tiefgreifenden Änderungen kann eine breite Prüfung erforderlich sein. Bei klar abgegrenzten Änderungen kann ein gezielter Umfang tragen. Entscheidend ist die begründete Abdeckung, nicht eine vorab festgelegte Minimal- oder Maximalregel.
Warum testen wir Funktionen, deren Code unverändert blieb?
Weil sich Eingangsdaten, gemeinsame Komponenten oder Konfigurationen verändert haben können. Im Beispiel bleibt die Berechnung unverändert und liefert wegen eines falsch importierten Werts trotzdem ein falsches Ergebnis. Unveränderter eigener Code ist daher kein ausreichender Nachweis der Nichtbetroffenheit.
Gibt es eine vorgeschriebene Regressionstestquote?
Aus den hier verwendeten Primärquellen ergibt sich keine universelle Quote. Zehn Prozent der alten Tests können wichtige Abhängigkeiten verfehlen; sehr viele Tests können denselben schmalen Bereich wiederholen. Wählen Sie nach fachlicher Abdeckung und Risiko statt nach einer reinen Anzahl.
Bestimmt die GAMP-Kategorie allein den Testumfang?
Nein. Sie ersetzt weder den vorgesehenen Einsatz noch die konkrete Auswirkungsbewertung. Eine pauschale Kategorienummer erklärt nicht, welche Datenwege und Entscheidungen Ihre Änderung betrifft. Die öffentliche GAMP-Darstellung betont den risikobasierten Lebenszyklusansatz, nicht ein universelles Testpaket pro Etikett.
Dürfen alte Tests als Nachweis weitergelten?
Ja, soweit ihre Eignung für den neuen Stand begründet bleibt. Prüfen Sie dafür relevante Version, Konfiguration und Anwendungsfall. Nicht jede Änderung entwertet sämtliche frühere Evidenz; eine neu beeinflusste Funktion ist aber nicht allein durch einen alten bestandenen Test abgedeckt.
Reichen die Regressionstests des Herstellers?
Sie können wichtige Evidenz liefern. Prüfen Sie deren tatsächlichen Umfang und die Übereinstimmung mit Ihrem Einsatz. Kundenspezifische Konfiguration, Schnittstellen oder Prozesse können zusätzliche Nachweise benötigen. Ein pauschaler Verweis auf das Herstellerpaket ersetzt diese Zuordnung nicht.
Quellen: [1]
Können Regressionstests automatisiert werden?
Müssen alle erwarteten Ergebnisse unabhängig berechnet werden?
Sie brauchen eine belastbare fachliche Grundlage für das Soll. Bei Rechenfunktionen kann eine unabhängige Berechnung besonders hilfreich sein. Die Quellen verlangen jedoch nicht, jedes erwartete Verhalten als Zahlenrechnung darzustellen. Wichtig ist, das Soll nicht unkritisch aus dem beobachteten Systemverhalten abzuleiten.
Was tun wir bei unbekannten technischen Abhängigkeiten?
Behandeln Sie sie als Unsicherheit. Klären Sie die Architektur oder wählen Sie geeignete Prüfungen, die den möglichen Wirkbereich abdecken. Fehlende Informationen sind kein Nachweis niedrigen Risikos. Zugleich ist ein pauschaler Volltest nicht automatisch die einzige sinnvolle Antwort.
Quellen: [2]
Wann ist eine Nichtwiederholung nachvollziehbar?
Wenn der Bereich anhand des tatsächlichen Änderungsumfangs und passender Evidenz begründet abgegrenzt ist. Benennen Sie die Grundlage, etwa fehlende gemeinsame Komponenten und Datenwege. „Nicht geändert“ oder „bisher nie fehlerhaft“ allein reicht für eine belastbare Auswirkungsbewertung häufig nicht.
Quellen & fachlicher Stand
Quellenstand: 7. Oktober 2026. Die fachlichen Beispiele betreffen Humanarzneimittel-GMP. Verwendet werden die genannten EU-GMP-/ICH-Quellen und öffentlichen ISPE-Unterlagen. Eine Erläuterung des vollständigen GAMP-Leitfadens ist damit nicht verbunden. Tabellen und Fallbeispiele sind illustrative Arbeitshilfen.
- Europäische Kommission: EU-GMP Annex 11, Computerised SystemsRevision Januar 2011; seit 30.06.2011; Principle; §§1,4,5,7,9–13,17; §12.4 Identität, Datum und Zeit; §10 kontrollierte Änderungen
- EMA/ICH: Q9(R1), Quality Risk ManagementEMA/CHMP/ICH/24235/2006 Corr.2; Veröffentlichung 31.01.2025; Q9(R1) wirksam seit 26.07.2023; §§3–4.6,5.1–5.3; Unsicherheit, Formalität, Wissensgrundlage und Neubewertung
- ISPE: GAMP – Zweck und risikobasierter LebenszyklusOffizielle Themenübersicht, abgerufen 07.10.2026; Einleitung GAMP guidance; Absatz zu nichtpräskriptiver Methode und GAMP 5 Second Edition
- ISPE: What You Need to Know About GAMP 5 Guide, 2nd EditionPharmaceutical Engineering, Januar/Februar 2023, Beitrag S.33–36; Druckseite 35 / PDF-Seite 37, Development Appendices: Testing guidance; Operation Appendices
- Europäische Kommission: EU-GMP Chapter 1, Pharmaceutical Quality SystemRevision 2013; seit 31.01.2013; §1.4(xii)–(xiv): vorausschauende Änderungsbewertung, Nachbewertung und Ursachenanalyse/CAPA; §1.5 Leitung
- Europäische Kommission: EU-GMP Chapter 4, DocumentationJanuar 2011; in Kraft seit 30.06.2011; Principle; §§4.1–4.9, insbesondere zeitnahe Aufzeichnung 4.8 und erkennbare Korrektur 4.9; §§4.10–4.12 Aufbewahrung
Zuletzt fachlich geprüft am 07.10.2026.
Daniel Herrmann Consulting
Änderungen mit passendem Testumfang absichern
Wir unterstützen Sie dabei, technische Änderungen in eine nachvollziehbare Auswahl von Regressionstests und geeigneten bestehenden Nachweisen zu übersetzen.
- IT-GxP-Audit →
Vorhandene Kontrollen und offene Nachweisfragen gezielt prüfen.
- IT-GxP-Compliance-Programm →
Verantwortung, Regelwerk und wiederverwendbare Abläufe im IT-GxP-Compliance Framework verbinden.
- IT-GxP-Coaching →
Ihr Team bei eigenen Bewertungen, Tests und nachvollziehbaren Entscheidungen begleiten.
- IT-GxP-Consulting →
Die konkrete Analyse und Umsetzung im vereinbarten Projektumfang unterstützen.