Testdaten für die GxP-Validierung: Normalfälle, Grenzen und Fehler gezielt auswählen

1. Die Prüffrage vor dem Datensatz festlegen

Beginnen Sie mit der Aussage, die ein Test belegen soll. Geht es um eine Berechnung, die Zuordnung zum richtigen Auftrag, eine Berechtigung oder die Behandlung unzulässiger Eingaben? Derselbe Zahlenwert kann für eine dieser Fragen geeignet und für eine andere bedeutungslos sein. Die Auswahl sollte deshalb nicht mit dem erstbesten verfügbaren Export beginnen.

Der regulatorische Beispielrahmen dieses Beitrags ist Humanarzneimittel-GMP. Annex 11 nennt geeignete Testmethoden und Szenarien, darunter Parametergrenzen, Datengrenzen und Fehlerbehandlung. Annex 15 behandelt vorab festgelegte Kriterien und die Bewertung tatsächlicher Ergebnisse. Seine konkreten OQ-Beispiele stehen im Anlagen- und Prozesskontext; sie werden hier nicht als unverändertes Prüfprogramm für jede Software ausgegeben.

Die folgenden Datensätze sind eigene konstruierte Arbeitshilfen. Sie zeigen eine Auswahlmethode, keine behördlich vorgeschriebene Testmenge. Andere GxP-Bereiche, zusätzliche US-Anforderungen und datenschutzrechtliche Detailfragen benötigen ihre jeweils passende Einordnung. Fachliche Aussagekraft und zulässige Bereitstellung von Daten sind getrennte Fragen, die beide geklärt sein müssen.

Quellen: [1] [2] [3]

2. Eingaberegel und erwarteten Prozesszustand eindeutig machen

Ein Grenzfall setzt eine bekannte Grenze voraus. Halten Sie fest, ob ein Bereich seine Endpunkte einschließt, ob leere Werte erlaubt sind und wie Zahlen eingegeben werden. Eine Vorgabe „bis 100“ lässt beispielsweise offen, ob null zulässig ist oder ein Dezimalwert akzeptiert werden soll. Solche Unklarheiten müssen fachlich geklärt werden, bevor daraus ein verbindliches Soll entsteht.

Beschreiben Sie nicht nur den Rückgabewert. Soll ein Datensatz gespeichert, ein Folgeauftrag erzeugt oder eine Aktion verhindert werden? Ein System kann eine Fehlermeldung zeigen und trotzdem einen ungewollten Eintrag anlegen. Die Auswahl geeigneter Testdaten sollte auch solche relevanten Nebenwirkungen sichtbar machen. Ein rein optischer Vergleich der Meldung reicht dafür möglicherweise nicht.

Trennen Sie gültige Fachregeln von der aktuell beobachteten Softwarefunktion. Wenn eine Anwendung 101 akzeptiert, obwohl höchstens 100 vorgesehen sind, ist damit nicht die Grenze widerlegt. Zunächst besteht eine Abweichung zwischen Regel und Beobachtung. Ob die Anforderung oder die Umsetzung geändert werden muss, ist anschließend begründet zu entscheiden, nicht durch stilles Anpassen des erwarteten Werts.

Quellen: [2] [3]

3. Das Soll unabhängig bestimmen

Leiten Sie das erwartete Ergebnis aus der freigegebenen Fachregel ab. Für eine einfache Rechnung kann eine nachvollziehbare Handrechnung genügen. Bei komplexeren Transformationen können eine anders aufgebaute Referenzrechnung, bekannte fachliche Referenzwerte oder eine begründete Kombination mehrerer Nachweise geeignet sein. Entscheidend ist, dass nicht dieselbe ungeprüfte Logik sich selbst bestätigt.

Eine zweite Tabellenzelle ist nicht automatisch unabhängig, wenn sie dieselbe kopierte Formel mit demselben Fehler verwendet. Ebenso ersetzt ein Screenshot der Anwendung keinen vorab bestimmten Sollwert. Halten Sie die fachliche Herleitung und ihre Quelle fest. Eine zusätzliche Person kann die Plausibilität prüfen; sie beseitigt eine gemeinsame falsche Grundlage aber nicht allein durch Mitzeichnung.

Definieren Sie Rundung, Einheit und Toleranz nur dort, wo sie fachlich gebraucht werden. Im späteren Beispiel werden ganze Stückzahlen exakt mit vier multipliziert; dafür ist keine Rundungstoleranz nötig. Bei Messwerten könnte die Situation anders sein. Ein universelles Prozentband wäre hier ebenso ungeeignet wie die Forderung, jedes Ergebnis müsse unabhängig von seinem Zweck immer mathematisch exakt sein.

Quellen: [2] [3] [5]

4. Einen vollständigen Datensatzpass führen

Eine Eingabedatei allein beschreibt häufig nicht den ganzen Fall. Rollen, Stammdaten, Systemzustand und erwartete Folgeaktionen können das Ergebnis beeinflussen. Die erste Arbeitshilfe bündelt diese Angaben. Sie darf in einem Testprotokoll, einer gelenkten Datei oder einem geeigneten Testwerkzeug umgesetzt werden. Wichtiger als das Format ist der nachvollziehbare Zusammenhang.

Vergeben Sie Datensatzkennung und Revision, wenn Daten wiederverwendet oder verändert werden. Referenzieren Sie gemeinsame Voraussetzungen, statt sie unkontrolliert in jede Zeile zu kopieren. Sobald ein einzelner Fall davon abweicht, muss die Abweichung erkennbar sein. Ein pauschaler Vermerk „wie vorher“ wird spätestens nach mehreren Änderungen oder einem unterbrochenen Lauf schwer verständlich.

Quellen: [2] [3] [4]

5. Normalfälle, Grenzen und Fehler bewusst kombinieren

Wählen Sie zunächst einen verständlichen Normalfall, an dem Berechnung und erwarteter Ablauf nachvollzogen werden können. Ergänzen Sie relevante untere und obere Grenzen sowie Werte außerhalb des erlaubten Bereichs. Leere Angaben, unpassende Formate und widersprüchliche Kennungen bilden wiederum andere Fehlerklassen. Ein einzelner Grenzwert ersetzt diese Unterschiede nicht.

Verändern Sie für diagnostisch klare Fälle zunächst eine wesentliche Bedingung. Wenn gleichzeitig die Menge ungültig und der Auftrag unbekannt ist, zeigt eine Ablehnung noch nicht, welche Kontrolle funktioniert hat. Anschließend können bewusst kombinierte Fälle sinnvoll sein, etwa zur Reihenfolge von Prüfungen oder zu Wechselwirkungen. Diese Auswahl braucht eine konkrete Frage, keine pauschale Forderung nach jeder möglichen Kombination.

Die erforderliche Tiefe hängt von Risiko, Komplexität, vorhandener Evidenz und verbleibender Unsicherheit ab. ICH Q9(R1) bietet dafür den verhältnismäßigen Risikorahmen. Es liefert weder eine feste Zahl von Datensätzen noch eine Garantie, dass eine bestimmte Anzahl alle Fehler findet. Dokumentieren Sie daher die abgedeckten Eingabeklassen und verbleibenden Grenzen statt nur die Gesamtzahl.

Quellen: [2] [5]

6. Das vollständige Beispiel vor der Ausführung definieren

Das folgende Beispiel ist vollständig konstruiert und wurde nicht in einem Produkt ausgeführt. Eine Planungsfunktion verarbeitet eine Auftragskennung und eine Packstückzahl. Die Kennung muss genau acht ASCII-Zeichen umfassen und einem vorhandenen Testauftrag entsprechen. Die Packstückzahl wird als ganze Zahl von 1 bis einschließlich 100 eingegeben, ohne Vorzeichen, führende Nullen oder Dezimaltrennzeichen. Je Packstück sind genau vier Behälter zu planen. Diese Grenzen sind frei gewählte Fachregeln des Beispiels, keine GMP-Vorgaben.

Bei gültiger Eingabe soll genau ein Planungsdatensatz mit unveränderter Auftragskennung und der berechneten Behälterzahl entstehen. Die Planungsfunktion löst im Beispiel auch bei gültiger Eingabe keine Folgeaufträge aus. Bei ungültiger Eingabe soll eine verständliche Ablehnung erscheinen; es dürfen weder Planungsdatensatz noch Folgeauftrag entstehen. Die Prüfung der Kennungslänge erfolgt vor der Suche nach dem Auftrag. So lässt sich eine falsche Länge im Beispiel von einem unbekannten, aber formal gültigen Auftrag unterscheiden.

Die gemeinsame Testbasis heißt F-1: Nur AU000001 ist als Auftrag angelegt; die Rolle Testplaner darf die Funktion ausführen. Für jeden Tabellenfall startet Zustand S0 mit leerem Eingabeformular, ohne Planungsdatensätze und ohne Folgeaufträge. Der Faktor vier und die Regeln sind unverändert. Die Tabellenwerte sind die exakt geplanten Eingaben; „leer“ bezeichnet ein tatsächlich nicht befülltes Feld, nicht das Wort leer.

Quellen: [2] [3]

7. Konkrete Datensätze und unabhängige Erwartungen festlegen

Aus der Beispielregel folgt die Rechnung Behälterzahl gleich Packstückzahl mal vier. Damit ergeben 10 Packstücke genau 40 Behälter, 1 Packstück genau 4 und 100 Packstücke genau 400. Diese Sollwerte wurden separat nachgerechnet. Für ungültige Eingaben wird kein fachliches Planungsergebnis erwartet; eine intern angezeigte Zahl wäre kein Ersatz für die geforderte Ablehnung ohne Speicherung.

Alle folgenden Fälle gelten für F-1 und beginnen unabhängig voneinander in S0. Bei jeder gültigen Eingabe bleibt die Kennung AU000001 unverändert; es entsteht genau ein Planungsdatensatz mit dem angegebenen Ergebnis. „Ablehnen“ bedeutet jeweils sichtbarer passender Fehler, null neue Planungsdatensätze und null Folgeaufträge. Diese gemeinsam festgelegten Erwartungen sind Bestandteil jeder Zeile.

Die Tabelle zeigt ausgewählte Klassen, kein vollständiges Testprogramm. Beispielsweise sind nicht berechtigte Rollen, sehr große Eingaben, zusätzliche Zeichensätze, gleichzeitige Nutzung und Schnittstellenwiederholungen hier nicht geprüft. Ob solche Fälle gebraucht werden, hängt vom realen Gebrauch und der Risikoanalyse ab. Die vollständig beschriebenen Beispielfälle behaupten keine vollständige Systemabdeckung.

Quellen: [2] [3]

8. Reset und Wiederholung ebenso konkret beschreiben

Sichern Sie nach jedem Fall zunächst den tatsächlichen Befund mit Zuordnung zu Datensatz, Ausführung und Systemstand. Dazu gehören im Beispiel die eingegebenen Werte, die beobachtete Rückmeldung sowie Anzahl und Inhalt neu entstandener Planungsdatensätze. Bei einer Ablehnung ist auch zu prüfen, ob unerwartet ein Folgeauftrag entstanden ist. Eine beabsichtigte Rücksetzung darf solche Befunde nicht unsichtbar machen.

Für das isolierte Beispiel lautet Reset R-1: Belege der Ausführung sichern, alle durch diesen Fall erzeugten Planungs- und Folgeaufträge kontrolliert aus dem Testbestand entfernen, Formular leeren und S0 erneut bestätigen. Auftrag AU000001, Rolle Testplaner und Faktor vier bleiben bestehen. Die Rücksetzung betrifft ausdrücklich die Testumgebung und ist keine Anleitung zum Löschen produktiver GMP-Aufzeichnungen.

Wird der Lauf unterbrochen oder ist der Zustand unklar, starten Sie den nächsten Fall nicht einfach mit einem angenommenen S0. Stellen Sie fest, was tatsächlich vorhanden ist, und dokumentieren Sie die Wiederherstellung. Bei wiederholtem Test wird der neue Befund separat zugeordnet. So bleiben ein ursprünglicher Fehler und ein später erfolgreiches Ergebnis unterscheidbar.

Quellen: [2] [4]

9. Datenherkunft und Änderungen passend behandeln

Synthetische Daten können besonders hilfreich sein, wenn Sie gezielt eine Grenze, ein ungültiges Format oder eine seltene Kombination herstellen möchten. Reale Datenausschnitte können wiederum Strukturen sichtbar machen, die in einer einfachen Konstruktion fehlen. Entscheidend ist die Eignung für die konkrete Prüffrage. Die bloße Herkunft macht einen Datensatz weder automatisch repräsentativ noch ungeeignet.

Dieser Beitrag beurteilt keine datenschutzrechtlichen Einzelpflichten für personenbezogene Produktivdaten. Klären Sie deren zulässige Nutzung und die erforderlichen Schutzmaßnahmen gesondert. Eine Maskierung allein beantwortet außerdem nicht, ob Beziehungen, Formate oder Wertebereiche für den fachlichen Test erhalten geblieben sind. Prüfen Sie die Aussagekraft nach einer Veränderung erneut.

Ändern Sie Datensätze oder Sollwerte kontrolliert. Wenn eine neue Fachregel nun fünf statt vier Behälter je Packstück vorsieht, entsteht ein anderer erwarteter Stand. Alte Ergebnisse dürfen nicht durch Überschreiben der Referenzwerte scheinbar zur neuen Regel passen. Halten Sie Änderungsgrund, betroffene Fälle und erforderliche neue Nachweise fest. Bestehende unveränderte Fälle können weiterhin geeignet sein, sofern ihre Voraussetzungen passen.

Quellen: [2] [3] [4]

10. Auswahl und Aufwand gemeinsam begrenzen

Für den Start benötigen Sie gültige Anforderungen, bekannte Fehlerszenarien, einen ausreichend geklärten Teststand und Zugang zu den benötigten Stammdaten. Der Fachbereich bestätigt Regeln und Sollbedeutung; IT beziehungsweise Systemverantwortlicher klärt Zustand, Rollen und Rücksetzung; QA unterstützt den geregelten Nachweisweg. Eine klare erste Fallgruppe hilft, diese Beiträge abzustimmen.

Der Aufwand steigt mit unklaren Fachregeln, komplexen Datenbeziehungen, schwer herstellbaren Zuständen und aufwendigem Reset. Viele zufällige Datensätze lösen diese Probleme nicht. Beginnen Sie mit einer wichtigen Prüffrage, vervollständigen Sie Daten und Soll und erproben Sie die Wiederholbarkeit. Danach erweitern Sie die Auswahl gezielt um noch nicht abgedeckte Risiken.

• Gültige Anforderung und konkrete Prüffrage benannt.
• Eingabeklassen und gewählte Fälle nachvollziehbar begründet.
• Alle relevanten Felder, Rollen und Vorbedingungen festgelegt.
• Sollwert und Prozesswirkung vorab unabhängig hergeleitet.
• Relevante Grenz-, Fehler- und Nebenwirkungsfälle berücksichtigt.
• Belegzuordnung, Reset und erneute Ausgangsprüfung beschrieben.
• Versionsstand, Datenherkunft und verbleibende Abdeckungsgrenzen sichtbar.

Quellen: [2] [5]