GxP-Testwerkzeuge: Eignung statt blindem Toolvertrauen

Einordnung und Geltungsbereich

Annex 11 Abschnitt 4.7 verlangt eine dokumentierte Eignungsbewertung automatisierter Testwerkzeuge und Testumgebungen. Die konkrete Nachweisform richtet sich nach der Aufgabe und dem Risiko einer falschen Prüfaussage.

Quellen: [1]

Prüfen Sie auch, ob der Test einen Fehler erkennen kann

Trennen Sie das erwartete Ergebnis möglichst von derselben Logik, die geprüft wird. Wenn das Testskript dieselbe fehlerhafte Berechnung unverändert übernimmt, bestätigen sich zwei gleiche Fehler gegenseitig. Eine geeignete unabhängige Vergleichsgrundlage kann diese Schwäche reduzieren.

Sichern Sie den Bezug zwischen Teststand, Eingaben und Ergebnis. Änderungen am Skript, an Bibliotheken oder an der Testumgebung können die Aussage verändern. Ein Ergebnis ohne nachvollziehbaren Werkzeugstand ist bei späteren Fragen schwer einzuordnen.

Quellen: [1]

Die beabsichtigte Prüfaussage des Werkzeugs beschreiben

Ein Testwerkzeug kann Aktionen ausführen, Werte vergleichen oder Nachweise erzeugen. Ein Fehler im Werkzeug kann einen Fehler im System übersehen oder einen falschen Befund erzeugen. Beschreiben Sie deshalb, welche Aussage auf seinem Ergebnis beruht und welche Folgen ein falsches Grün hätte. Nicht jedes Hilfsskript besitzt denselben Einfluss.

Annex 11 verlangt im Kontext geeigneter Testmethoden eine angemessene Bewertung automatisierter Testwerkzeuge und Testumgebungen. Daraus folgt nicht, dass jedes kleine Skript ein identisches vollständiges Dokumentenpaket wie eine Fachanwendung benötigt. Die Tiefe richtet sich nach Zweck, Komplexität und Risiko der Prüfaussage.

Unterscheiden Sie kommerzielles Werkzeug, eigene Skripte und Konfiguration. Ein validiertes Grundprodukt kann mit einem falsch gesetzten Filter dennoch ungeeignete Ergebnisse liefern. Ein einfaches eigenes Skript kann eine klar begrenzte Aufgabe gut erfüllen, wenn seine Funktion und Grenzen geeignet geprüft sind. Der Produktname allein beantwortet die Eignung nicht.

Quellen: [1]

Eine Werkzeugakte mit Regeln und Grenzen führen

Erfassen Sie Version, Eingaben, Vergleichslogik, ausgeschlossene Felder und Ausgabe. Benennen Sie, wer Änderungen bewertet und wer das Ergebnis prüft. Die Akte sollte den tatsächlichen Zweck erklären, statt nur Installationsdaten zu sammeln. Ein Reviewer muss verstehen, was ein Pass bestätigt und was nicht.

Dokumentieren Sie Annahmen über Datenformat, Kodierung und Sortierung. Ein Vergleich kann bei vertauschter Reihenfolge falsch melden oder Werte falsch zuordnen. Die richtige Schlüsselregel ist häufig wichtiger als eine große Zahl erfolgreich verarbeiteter Zeilen. Die Anforderungen folgen dem konkreten Vergleichszweck.

Quellen: [1]

Beispiel: Vergleichsskript ignoriert das kritische Statusfeld

Das Szenario ist konstruiert. Ein Skript vergleicht Migrationsdateien und meldet keine Unterschiede. Sein Feldkatalog enthält jedoch den Chargenstatus nicht. Eine falsche Freigabeinformation bleibt unentdeckt. Das Werkzeug funktioniert exakt wie programmiert, erfüllt aber die benötigte Prüfaussage nicht.

Bereiten Sie einen kleinen bekannten Referenzbestand vor. Er enthält unveränderte Zeilen, fehlende Datensätze, doppelte Schlüssel und einen gezielt falschen Status. Legen Sie erwartete Befunde unabhängig fest. Führen Sie das Skript aus und vergleichen Sie Bericht und Sollbefunde. Der Test prüft damit nicht nur Ausführung, sondern Erkennungsfähigkeit.

Nach Ergänzung des Felds wird die Prüfung wiederholt. Bewerten Sie auch frühere mit dem ungeeigneten Stand erzeugte Aussagen. Eine neue richtige Version macht alte grüne Berichte nicht automatisch belastbar. Der betroffene Umfang wird anhand tatsächlicher Nutzung und Datenrisiken bestimmt.

Quellen: [1]

Unabhängige Sollwerte und negative Fälle verwenden

Eine zweite Kopie derselben Logik ist keine starke unabhängige Referenz. Herleiten Sie erwartete Ergebnisse aus einer geeigneten fachlichen Grundlage oder einer anders geprüften Methode. Bei einfachen Regeln kann eine nachvollziehbare manuelle Rechnung genügen. Komplexere Werkzeuge benötigen entsprechend geeignete Evidenz.

Prüfen Sie Fehlersituationen des Werkzeugs selbst. Was geschieht bei nicht lesbarer Datei, fehlender Spalte oder ungültigem Format? Ein Abbruch darf nicht als erfolgreicher Null-Befund-Bericht erscheinen. Der Nutzer sollte erkennen, ob die Prüfung tatsächlich vollständig ausgeführt wurde.

Berücksichtigen Sie Toleranzen und Normalisierungen. Eine bewusste Rundung kann für einen Zweck geeignet sein, für einen anderen kritische Unterschiede verdecken. Dokumentieren Sie, weshalb die Regel passt. Die Standardeinstellung eines Werkzeugs ist keine automatische fachliche Akzeptanzgrenze.

Quellen: [1]

Nachweise und Reproduzierbarkeit erhalten

Verknüpfen Sie Werkzeugstand, Eingabestand, Einstellungen und Ergebnisbericht. Ein späterer Lauf mit einer anderen Datei oder Bibliotheksversion kann andere Resultate erzeugen. Die genaue technische Ablage kann variieren; entscheidend ist die nachvollziehbare Wiederauffindbarkeit des tatsächlich verwendeten Stands.

Wenn Screenshots oder andere Nachweise automatisch erzeugt werden, prüfen Sie deren richtigen Bezug. Ein Bild ohne Recordkennung oder mit veraltetem Bildschirmzustand kann wenig beweisen. Ein Werkzeug, das Aktionen schnell ausführt, muss dennoch den tatsächlich benötigten Soll-Ist-Vergleich ermöglichen.

Bewerten Sie manuelle Eingriffe. Wenn ein Bearbeiter Berichte nachträglich filtert oder korrigiert, sollte die endgültige Prüfaussage nachvollziehbar bleiben. Ein bearbeitetes Ergebnis darf nicht als unveränderte automatische Ausgabe ausgegeben werden. Rollen und Review werden passend zum Risiko festgelegt.

Quellen: [1]

Änderungen und Wiederverwendung bewusst steuern

Ein Werkzeug kann für mehrere Projekte verwendet werden, wenn sein Zweck und seine Grenzen passen. Prüfen Sie neue Datenformate, Felder und Regeln. Ein bewährter Vergleich für einfache Stammdaten bestätigt nicht automatisch historische Auditdaten oder komplexe Beziehungen. Die Wiederverwendung braucht einen passenden Einsatzbezug.

Bei Änderungen werden betroffene Referenzfälle wiederholt und neue Risiken ergänzt. Ein kleiner Codeeingriff kann zentrale Vergleichslogik beeinflussen. Die Zahl geänderter Zeilen ist daher kein ausreichender Umfangsmaßstab. Benennen Sie fachliche Wirkung und geeignete Regression.

Quellen: [1]

Arbeitsvorlage: einen falschen grünen Vergleich gezielt verhindern

Erstellen Sie einen kleinen bekannten Bestand mit erwarteten Befunden. Im Beispiel enthält er identische Daten, einen fehlenden Record, einen doppelten Schlüssel und einen falschen Status. Diese Fälle prüfen unterschiedliche Eigenschaften. Die Sollbefunde werden unabhängig hergeleitet und vor Durchführung dokumentiert.

Betrachten Sie neben der Logik auch Ausführung und Bericht. Eine fehlende Spalte sollte nicht als erfolgreicher Nullvergleich erscheinen. Eine abgeschnittene Fehlerliste darf wichtige Befunde nicht unbemerkt verlieren. Der Nachweis verbindet richtigen Eingang, geeignete Regel und vollständige verständliche Ausgabe.

Wiederholen Sie die passenden Referenzfälle bei einer Änderung. Ein kleiner Eingriff in Filter oder Normalisierung kann große fachliche Wirkung besitzen. Die Bewertung richtet sich nach dieser Wirkung, nicht nur nach der Zahl geänderter Codezeilen. Neue Einsatzbereiche benötigen einen eigenen passenden Zweckbezug.

Quellen: [1]

Die nächsten Schritte

• Prüfaufgabe und mögliche falsche Schlussfolgerungen definieren.
• Werkzeug mit bekannten richtigen und falschen Fällen bewerten.
• Stand und erforderliche Bedienregeln kontrollieren.
• Änderungen auf die Aussage der bisherigen Tests bewerten.