Inhaltsverzeichnis
Das Wichtigste vorab
Wie beurteilen wir automatisch erzeugte Testnachweise einschließlich Fehlererkennung und Auswertung?
Prüfen Sie nicht nur, ob die Automatisierung erfolgreich läuft, sondern ob sie relevante Fehler erkennt und Ergebnisse richtig zuordnet. Definieren Sie unabhängige Sollwerte, kontrollierte Fehlersituationen und die Bedeutung von bestanden, fehlgeschlagen oder nicht ausgeführt. Bewahren Sie die erforderliche Evidenz mit Bezug zu Software, Daten und Prüfregeln auf. Die fachliche Nutzungsentscheidung muss die tatsächliche Abdeckung und offene Befunde berücksichtigen; eine grüne Anzeige ersetzt sie nicht.
- Prüfgegenstand, Prüfwerkzeug und Ergebnisbewertung getrennt betrachten.
- Kontrollierte Fehler zeigen, ob die Prüfstrecke relevante Abweichungen erkennt.
- Digitale Evidenz anhand Aussage, Zuordnung und Verfügbarkeit beurteilen.
1. Trennen Sie drei Gegenstände der Prüfung
Die erste Frage betrifft die eingesetzte Produktions- oder QMS-Funktion. Die zweite betrifft das Werkzeug, das diese Funktion prüft. Die dritte betrifft die Auswertung, die aus Einzelbefunden ein Ergebnis erzeugt. Wenn derselbe fehlerhafte Rechenweg sowohl Produktivwert als auch Sollwert erzeugt, kann der Vergleich trotz falscher Ergebnisse grün bleiben.
Beschreiben Sie deshalb, woher der erwartete Wert stammt und wie unabhängig er vom Prüfgegenstand ist. Eine manuell nachvollziehbare Referenzrechnung kann für einen begrenzten Fall geeignet sein. Bei umfangreicheren Daten sind andere geeignete Referenzen möglich. Entscheidend ist die begründete Aussagekraft, nicht die pauschale Behauptung, jede unabhängige Prüfung müsse von einer zweiten Person ausgeführt werden.
Quellen: [1]
2. Ordnen Sie Automatisierung und Werkzeugnutzung ein
Die FDA-CSA-Guidance vom Februar 2026 befürwortet geeignete Werkzeuge und vorhandene digitale Evidenz. Sie behandelt Produktions- und QMS-Software im Medizinproduktebereich. Ihre Empfehlungen sind nicht bindend und lassen sich nicht ohne Scopeprüfung als universelle GxP-Pflichten ausgeben. Anwendbare Anforderungen bleiben maßgeblich.
Auch ein Testwerkzeug ist nach seiner konkreten Verwendung zu betrachten. Die Guidance unterscheidet Software, die regulierte Funktionen unterstützt, von Werkzeugen ohne entsprechenden Einsatz. Daraus folgt weder eine pauschale Vollvalidierung jedes Entwicklertools noch eine pauschale Ausnahme aller Testautomatisierung. Beschreiben Sie, welche Entscheidung sich auf das Werkzeug verlässt und welche Fehler seinerseits relevant wären.
3. Zeichnen Sie die vollständige Prüfkette auf
Die eigene Arbeitsmatrix betrachtet mehr als das eigentliche Testskript. Ein korrektes Skript kann gegen die falsche Umgebung laufen, veraltete Daten lesen oder durch eine fehlerhafte Zusammenfassung ein falsches Gesamtergebnis erhalten. Solche Übergänge gehören zur Beurteilung des Nachweises.
Für kleine Teams reicht häufig eine kompakte Darstellung mit klaren Identifikatoren. Sie sollte erkennen lassen, welcher Testlauf welchen Softwarestand unter welchen Bedingungen geprüft hat. Vermeiden Sie eine Zuordnung ausschließlich über einen veränderlichen Dateinamen wie „letzter Lauf“. Die benötigte Detailtiefe richtet sich nach der konkreten Aussage und dem Risiko.
| Stufe | Relevante Frage | Geeigneter Kontrollpunkt |
|---|---|---|
| Testdaten | Sind Referenzwerte und Randbedingungen bekannt? | Datensatzstand und unabhängige Sollbegründung |
| Ausführung | Wurde tatsächlich die vorgesehene Funktion geprüft? | Umgebung, Konfiguration und Softwarestand zuordnen |
| Vergleich | Erkennt die Regel relevante Abweichungen? | Bewusst falsche Werte und fehlende Ergebnisse einspeisen |
| Zusammenfassung | Bleiben Fehler und nicht ausgeführte Fälle sichtbar? | Einzelergebnisse gegen Gesamtstatus abgleichen |
| Aufbewahrung | Ist die erforderliche Aussage später nachvollziehbar? | Zugeordnete Ergebnisdaten, Prüfregeln und Kontext erhalten |
Quellen: [1]
4. Illustrativer Fall: fünf kontrollierte Prüfbedingungen
Ein fiktiver Hersteller prüft eine Berechnung, die eine eingegebene Länge in Millimetern in Zentimeter umwandelt. Die angenommene Anforderung lautet: Ergebnis = Eingabe / 10; fehlende Eingaben dürfen kein gültiges Ergebnis erzeugen. Die eigenen Referenzen sind 120 mm = 12 cm und 35 mm = 3,5 cm.
Um die Prüfstrecke selbst zu beurteilen, werden zusätzlich drei kontrollierte Fehlerbedingungen vorgesehen: ein falscher Ergebniswert, ein fehlendes Ergebnis und ein gar nicht ausgeführter Fall. Die Tabelle beschreibt erwartete Reaktionen der Automatisierung. Sie berichtet keine real ausgeführten Tests und behauptet keine produktspezifischen Werkzeugfunktionen.
| Fall | Kontrollierte Eingabe oder Ausgabe | Unabhängige Erwartung | Erforderliche Aussage der Prüfstrecke |
|---|---|---|---|
| A | 120 mm; ausgegeben 12 cm | 120 / 10 = 12 | Bestanden für diesen Vergleich |
| B | 35 mm; ausgegeben 3,5 cm | 35 / 10 = 3,5 | Bestanden für diesen Vergleich |
| C | 120 mm; absichtlich ausgegeben 120 cm | Falsch: Faktor 10 fehlt | Fachlichen Vergleich als fehlgeschlagen ausweisen; erwartete Fehlererkennung gesondert bewerten |
| D | 35 mm; Ergebnis fehlt | Keine ausreichende Ergebnisgrundlage | Fehlendes Ergebnis sichtbar, nicht als Null interpretieren |
| E | Fall wurde nicht ausgeführt | Keine Prüfaussage vorhanden | Nicht ausgeführt kennzeichnen; keine Aussage „bestanden“ über die Fachfunktion |
Quellen: [1]
5. Prüfen Sie den Gesamtstatus gegen Einzelbefunde
Im Sollfall sind zwei Vergleichsergebnisse korrekt. Die drei weiteren Bedingungen prüfen die Fehlererkennung beziehungsweise die Darstellung fehlender Evidenz. Ein Bericht „5 von 5 bestanden“ wäre nur dann verständlich, wenn er eindeutig die erfolgreiche Prüfung der fünf Kontrollbedingungen meint. Als Aussage, fünf fachliche Berechnungen seien korrekt gewesen, wäre er falsch.
Definieren Sie deshalb die Bedeutung der Zähler. Zwei erfolgreiche fachliche Vergleiche und drei korrekt erkannte Kontrollbedingungen sind unterschiedliche Größen. Halten Sie außerdem fest, wie Abbruch, Zeitüberschreitung und fehlende Daten behandelt werden. Ein übersprungener Test darf nicht durch die bloße Abwesenheit einer Fehlermeldung als bestandener Test erscheinen.
Quellen: [1]
6. Bewahren Sie die entscheidende digitale Evidenz
Die FDA empfiehlt, geeignete vorhandene digitale Nachweise zu nutzen, statt sie unnötig durch manuelle Dokumentation zu duplizieren. Entscheidend bleibt, ob der Record ausreichend objektive Evidenz für den vorgesehenen Einsatz liefert. Für die automatisierte Strecke kann das den Bezug zwischen Testdaten, Prüfregel, Lauf und Einzelergebnis erfordern.
Ein Screenshot der grünen Übersichtsseite zeigt selten alle dafür nötigen Informationen. Umgekehrt ist nicht jeder technische Debuglog automatisch ein erforderlicher regulierter Record. Bestimmen Sie, welche Informationen die Nachweisentscheidung tragen und wie sie verfügbar bleiben. Falls die erforderlichen Records elektronisch geführt werden, ist ihre Part-11-Anwendbarkeit gesondert zu prüfen.
Quellen: [1]
7. Beurteilen Sie Änderungen an der Prüfstrecke
Auch die Prüflogik kann sich ändern. Eine neue Rundungsregel, ein anderes Datenformat oder ein geänderter Vergleichsoperator kann die Aussage früherer Läufe beeinflussen. Behandeln Sie solche Änderungen sichtbar und prüfen Sie die betroffenen Kontrollbedingungen. Im Beispiel könnte eine zu große Toleranz den absichtlich falschen Wert unbemerkt akzeptieren.
Die passende Absicherung hängt vom Einsatz ab. Ein einmaliges Hilfsskript mit unabhängig überprüftem Ergebnis ist anders zu betrachten als eine zentrale Prüfstrecke, auf deren Status viele Freigabeentscheidungen beruhen. Eine pauschale Kategorie aus dem Wort Skript wäre ebenso unzureichend wie die Annahme, technische Werkzeuge seien grundsätzlich irrelevant.
Quellen: [1]
8. Checkliste vor Verwendung automatisierter Ergebnisse
Die eigene Checkliste richtet sich an die Entscheidung, ob Sie sich auf einen konkreten Lauf verlassen können. Sie ist kein vollständiger Werkzeugvalidierungsplan. Beginnen Sie mit den Folgen eines falschen grünen Ergebnisses und wählen Sie dazu passende Kontrollen.
Wenn ein kontrollierter Fehler nicht erkannt wird, reicht es nicht, den betroffenen Fall aus der Zusammenfassung zu entfernen. Untersuchen Sie die Ursache und die Reichweite. Frühere Ergebnisse können betroffen sein, wenn dieselbe fehlerhafte Prüfregel bereits verwendet wurde. Dokumentieren Sie die daraus folgende Bewertung und den korrigierten Nachweis.
- Prüfgegenstand und eingesetztes Werkzeug klar abgegrenzt.
- Sollwerte unabhängig und fachlich nachvollziehbar bestimmt.
- Kontrollierte falsche, fehlende und nicht ausgeführte Ergebnisse berücksichtigt.
- Lauf eindeutig mit Software, Daten und Prüfregeln verbunden.
- Einzelbefunde und Gesamtstatus widerspruchsfrei.
- Erforderliche digitale Evidenz verfügbar und zugeordnet.
- Offene Befunde und Änderungen für die Nutzungsentscheidung bewertet.
Quellen: [1]
Screenshots nach der benötigten Aussage auswählen
Ein Bildbeleg ist sinnvoll, wenn die sichtbare Benutzeroberfläche selbst Teil der Anforderung ist: etwa die erkennbare Warnung, die richtige Signaturbedeutung oder eine nicht erlaubte Handlung. Für einen vollständigen Abgleich vieler Datenzeilen kann ein geeigneter maschinenlesbarer Nachweis dagegen aussagekräftiger sein. Wählen Sie die Form danach aus, welche Beobachtung ein unabhängiger Prüfer benötigt. Eine hohe Screenshotanzahl ist keine eigenständige Aussage über Testqualität.
Annex 11 verlangt geeignete Nachweise für den vorgesehenen Einsatz; daraus folgt keine allgemeine Pflicht, jeden Mausklick abzufotografieren. Umgekehrt ist ein Log kein pauschaler Ersatz für jede sichtbare oder interaktive Anforderung. Prüfen Sie die Aussagegrenzen: Erfasst das Log nur einen Funktionsaufruf oder auch den tatsächlichen beobachteten Zustand? Die FDA-CSA-Guidance hat einen spezifischen Geltungsbereich für Production- und Quality-System-Software bei Medizinprodukten; sie ist keine allgemeine Befreiung sämtlicher Pharma-GMP-Tests von erforderlichen Nachweisen.
Quellen: [3]
Eigene Nachweismatrix: Beobachtung vor Dateiformat
Im konstruierten Freigabetest muss eine berechtigte Person einen bestimmten Record bestätigen können; ein unberechtigter Anwender darf dies nicht. Das technische Protokoll zeigt eine abgelehnte Anfrage. Der UI-Test prüft zusätzlich, ob die Oberfläche den richtigen Status verständlich zeigt und keinen Erfolg behauptet. Beide Belege können gemeinsam nötig sein, weil sie unterschiedliche Aussagen tragen. Eine alleinige Servermeldung oder ein alleiniger Bildausschnitt würde die jeweils andere Ebene offenlassen.
Identifizieren Sie Prüfgegenstand, Stand, Testfall, Eingabe, Erwartung, Ist-Ergebnis und Zeitpunkt in geeigneter Weise. Nicht jede Information muss in jedem Screenshot stehen, wenn das Paket die eindeutige Zuordnung trägt. Bewahren Sie die erforderliche digitale Evidenz kontrolliert auf. Wenn ein Lauf später wiederholt wird, bleiben alte Befunde und neue Ergebnisse unterscheidbar. Ein nachträglich erstelltes Bild darf nicht unbemerkt als Beleg einer früheren Testausführung erscheinen.
| Prüfaussage | Passender Nachweis | Grenze |
|---|---|---|
| Warnung ist für den Nutzer verständlich | Kontrollierter UI-Bildbeleg mit Testbezug | Beweist allein keine Backend-Verhinderung |
| Unberechtigter Zugriff wird abgewiesen | Aufruf und tatsächlicher Autorisierungsbefund | Bloß versteckter Button reicht nicht |
| Alle bezeichneten Werte stimmen | Nachvollziehbarer maschinenlesbarer Vergleich | Vergleichsregel und Population müssen geeignet sein |
| Signatur betrifft richtige Version | Record-, Versions- und Signaturbezug | Dekoratives Unterschriftenbild reicht nicht |
| Fehler führt zum richtigen Gesamtstatus | Einzelbefunde und Zusammenfassung | Grünes Symbol allein ist unzureichend |
Quellen: [3]
Häufige Fragen zu CSV-Testnachweise: Logs und Screenshots
Ist ein grüner Testlauf ein ausreichender Validierungsnachweis?
Er kann einen Teil der Evidenz liefern. Seine Bedeutung hängt von Prüfziel, Abdeckung, Daten und korrekter Ergebnisbewertung ab. Ein grüner Status belegt keine ungeprüften Anforderungen und ersetzt nicht die Entscheidung über offene Befunde oder den vorgesehenen Einsatz.
Quellen: [1]
Muss jedes Testwerkzeug vollständig validiert werden?
Eine pauschale Aussage ist nicht angemessen. Beurteilen Sie den konkreten Einsatz und die Abhängigkeit Ihrer Entscheidung vom Werkzeug. Die Guidance differenziert zwischen verschiedenen unterstützenden Werkzeugen und Nutzungen. Der Nachweisumfang muss zur tatsächlichen Funktion und möglichen Fehlerfolge passen.
Quellen: [1]
Warum sollen wir absichtlich falsche Ergebnisse einspeisen?
Damit lässt sich gezielt untersuchen, ob die Prüfstrecke einen relevanten Fehler erkennt. Ohne solche Kontrollbedingungen kann ein Vergleich grün bleiben, weil er gar nicht wirksam prüft. Die Auswahl der Fehler sollte zu den wichtigen Anforderungen und möglichen Fehlbewertungen passen.
Quellen: [1]
Dürfen Test und Produktivfunktion dieselbe Formel verwenden?
Das kann die Unabhängigkeit des Sollvergleichs schwächen. Wenn beide dieselbe falsche Logik enthalten, bleibt die Abweichung möglicherweise unsichtbar. Begründen Sie deshalb eine geeignete Referenz, etwa eine unabhängig nachvollzogene Rechnung für ausgewählte Fälle oder eine andere belastbare fachliche Grundlage.
Quellen: [1]
Wie behandeln wir einen nicht ausgeführten Test?
Er liefert keine Aussage über das beabsichtigte Verhalten. Kennzeichnen Sie ihn entsprechend und beurteilen Sie die Auswirkung auf die Nachweisentscheidung. Die Abwesenheit eines Fehlers ist kein Bestehen, wenn die Prüfung gar nicht stattgefunden hat.
Quellen: [1]
Sind Screenshots zusätzlich zu Logs notwendig?
Nicht generell. Wählen Sie die Evidenz nach ihrer Aussagekraft. Digitale Ergebnisdaten können mehr Kontext liefern als ein Bildschirmfoto. Ein Screenshot ist sinnvoll, wenn er eine relevante Aussage ergänzt; eine pauschale Doppelablage aller Ergebnisse ist daraus nicht abzuleiten.
Quellen: [1]
Sind automatisch erzeugte Logs immer Part-11-Records?
Nein. Entscheidend ist, ob sie im konkreten Zusammenhang erforderliche elektronische Aufzeichnungen darstellen. Ein Log, das den notwendigen Validierungsnachweis trägt, kann anders zu behandeln sein als ein routinemäßiger technischer Log ohne solchen Zweck. Die Verwendung muss dokumentiert eingeordnet werden.
Quellen: [1]
Was bedeutet 5 von 5 im Beispiel?
Die fünf Zeilen prüfen unterschiedliche Kontrollbedingungen. Zwei fachliche Vergleichswerte sind korrekt; drei weitere Zeilen verlangen sichtbare Fehler- oder Fehlendzustände. Eine Gesamtaussage muss diese Bedeutung erhalten. Sie darf nicht so wirken, als seien fünf fachliche Berechnungen erfolgreich geprüft worden.
Quellen: [1]
Müssen Änderungen an einem Prüfskript bewertet werden?
Ja, soweit sie die Aussage der verwendeten Evidenz beeinflussen können. Prüfen Sie betroffene Regeln, Datenformate und Ergebniszusammenfassungen. Nicht jede Textänderung hat dieselbe Wirkung; eine veränderte Toleranz oder Fehlerbehandlung kann dagegen wesentlich sein.
Quellen: [1]
Gilt diese Methode für jedes GxP-System gleich?
Die Arbeitshilfe ist übertragbar, der zitierte FDA-CSA-Scope nicht automatisch. Für pharmazeutische GMP-Systeme oder klinische Anwendungen müssen die jeweils anwendbaren Anforderungen gesondert bestimmt werden. Der Beitrag behauptet weder universelle Werkzeugpflichten noch eine allgemeine Befreiung von Nachweisen.
Müssen wir jeden Testschritt mit einem Screenshot dokumentieren?
Eine allgemeine Pflicht für jeden Mausklick lässt sich daraus nicht ableiten. Wählen Sie geeignete Belege für die tatsächliche Prüfaussage. Ein Bild kann UI-Verhalten zeigen; ein vollständiger Datenvergleich braucht andere oder zusätzliche Evidenz. Die Zuordnung und unabhängige Beurteilbarkeit des gesamten Nachweispakets sind entscheidend.
Quellen: [3]
Dürfen wir einen fehlenden Bildbeleg später nachstellen?
Eine spätere Nachstellung ist eine neue Beobachtung und muss als solche erkennbar sein. Sie darf nicht wie ein ursprünglicher Ausführungsbeleg erscheinen. Bewerten Sie die Nachweislücke und legen Sie eine kontrollierte ergänzende oder wiederholte Prüfung fest. Ursprünglicher Befund, neue Ausführung und Schlussfolgerung bleiben unterscheidbar.
Quellen & fachlicher Stand
Stand: 15. Oktober 2026. Bestehender Artikel gezielt vertieft; aktueller Quellenabgleich und vollständiger fachlicher Review vor Staging. Zahlenbeispiele, Kriterien und Tabellen sind eigene methodische Arbeitshilfen, keine pauschalen Regelwerksvorgaben.
- FDA: Computer Software Assurance for Production and Quality Management System SoftwareFinal Guidance 03.02.2026; nicht bindende Empfehlungen für Produktions-/QMS-Software im Medizinproduktebereich.
- 21 CFR Part 820 – Quality Management System RegulationAktueller QMSR-Text; seit 02.02.2026 wirksam. §§820.1,820.7,820.10,820.35,820.45.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)Geltende Fassung laut EudraLex-Verzeichnis am 15.10.2026. Anwendung, Risiken, Betrieb und Datenlebenszyklus; konkrete Prüfvorschläge sind eigene Ableitungen.
Zuletzt fachlich geprüft am 15.10.2026.
Daniel Herrmann Consulting
Den konkreten Nachweisprozess gemeinsam bearbeiten
Wir helfen Ihrem Team, automatisierte Prüfstrecken und ihre digitalen Nachweise fachlich zu beurteilen und die verbleibenden Lücken gezielt zu schließen.
- IT-GxP-Audit →
Anforderungen, vorhandene Nachweise und relevante Lücken beurteilen.
- IT-GxP-Consulting →
Vereinbarte Bewertungs-, Dokumentations- und Testarbeit im Projekt bearbeiten.
- IT-GxP-Coaching →
Ihr Team bei konkreten Entscheidungen und der Anwendung eigener Verfahren begleiten.
- IT-GxP-Compliance-Programm →
Passende interne Verfahren, Vorlagen und Schulung aufbauen.