Azure DevOps im GxP-Einsatz: Testnachweise bis zur Auslieferung verbinden

1. Den Nachweisprozess statt des Produktnamens bewerten

Azure DevOps kann Aufgaben verwalten, Quellcode aufnehmen, Software bauen und Testergebnisse zusammenführen. Entscheidend für die GxP-Bewertung ist, welche dieser Informationen in Ihrem Betrieb eine qualitätsrelevante Entscheidung tragen. Ein informelles Entwicklungsboard hat eine andere Funktion als ein Testmanagementsystem, dessen Bericht als wesentlicher Validierungsnachweis verwendet wird. Auch ein unterstützendes Werkzeug kann durch diese Verwendung relevant werden.

Der hier betrachtete Fall betrifft Computersysteme für die Herstellung von Humanarzneimitteln im EU-GMP-Umfeld. Annex 11 ist die einschlägige GMP-Leitlinie für diesen Systemkontext. §4.7 adressiert ausdrücklich die dokumentierte Bewertung der Eignung automatisierter Testwerkzeuge und Testumgebungen. Daraus folgt weder eine pauschale Produktzulassung noch ein identischer Prüfumfang für sämtliche Dienste.

Beschreiben Sie zunächst: Welche Aussage übernimmt das Team aus Azure DevOps, wer entscheidet damit und welche Fehlfunktion könnte diese Entscheidung verfälschen? Ein falsch gefilterter Bericht, ein überschriebenes Sollresultat oder ein Ergebnis zum falschen Build sind dafür konkrete Ausgangspunkte. Dokumentieren Sie außerdem, welche Nachweise außerhalb der Plattform geführt werden.

Quellen: [1] [11] [10]

2. Services, Server und Lizenzen konkret festhalten

Azure DevOps Services ist der von Microsoft betriebene, fortlaufend aktualisierte Dienst. Azure DevOps Server wird auf eigener Infrastruktur betrieben. Microsoft dokumentiert im aktuellen Server-Release-Strang eine RTW-Ausgabe vom 9. Dezember 2025 und Patch 8 vom 10. September 2026. Das ist ein dokumentierter Versionsbezug, keine Aussage über Ihren installierten Stand. Server 2022 bleibt ebenfalls in der Dokumentation sichtbar.

Erfassen Sie Organisation beziehungsweise Collection, Projekte, Prozessmodell, Erweiterungen, Identitätsanbindung und eingesetzte Build-Agents. Bei Server kommen Betriebssystem, Datenbank, Installation und Patchverwaltung hinzu. Bei Services benötigen Sie einen geregelten Umgang mit Dienständerungen und den weiterhin selbst verantworteten Komponenten. Eine gleiche Bildschirmbezeichnung belegt keine identische Funktion.

Für Test Plans reichen Sichtzugriff und eine beliebige Projektmitgliedschaft nicht für alle Aufgaben. Die Microsoft-Dokumentation nennt für bestimmte Verwaltungs- und Konfigurationsaufgaben Basic + Test Plans oder entsprechende Visual-Studio-Abonnements sowie zusätzliche Berechtigungen. Prüfen Sie den Zugang der tatsächlichen Tester und Stellvertreter vor der Testplanung. Ein freigeschaltetes Konto beantwortet noch nicht, was dieser Benutzer fachlich entscheiden darf.

Quellen: [1] [9] [2]

3. Die Verbindung von Anforderung bis Auslieferung definieren

Microsoft beschreibt Verknüpfungen zwischen Anforderungen, Tests, Fehlern und Codeänderungen. Der Nutzen entsteht erst, wenn diese Verbindungen Ihre konkrete Nachweisfrage beantworten. Eine allgemeine Beziehung zwischen zwei Work Items kann beispielsweise zu wenig aussagen, wenn offenbleibt, ob der Test die aktuelle Anforderungsversion oder nur einen früheren Entwurf abdeckt.

Die folgende Arbeitsmatrix ist eine eigene Empfehlung für einen kleinen Entwicklungsbereich. Die Bezeichner sind frei gewählt. Sie beschreibt den erforderlichen Zusammenhang und schreibt kein bestimmtes Zusatzprodukt vor. Prüfen Sie die Kette auch rückwärts: vom tatsächlich installierten Paket zu den relevanten Prüfungen und deren Ausgangsvorgaben.

Quellen: [4] [3] [11]

4. Testfälle und Ausführungsergebnisse auseinanderhalten

Ein Testplan referenziert Testfälle. Wird ein gemeinsam verwendeter Testfall geändert, betrifft das auch andere Pläne und Suites, die auf ihn verweisen. Ein wiederverwendeter Planname ist deshalb noch keine eingefrorene Testvorgabe. Legen Sie fest, wie der verwendete Stand von Schritten, Parametern und Sollresultaten für eine spätere Prüfung nachvollziehbar bleibt.

Ein Testpunkt kombiniert Testfall, Suite, Konfiguration und Tester. Seine wiederholten Ausführungen erzeugen unterschiedliche Ergebnisse. Die aktuelle Execute-Ansicht zeigt das jüngste Ergebnis. Für die Bewertung einer bestimmten Auslieferung benötigen Sie gegebenenfalls die Ausführungshistorie statt nur dieser jüngsten Sicht.

Prüfen Sie im eigenen Ablauf eine Änderung nach abgeschlossener Ausführung: Bleibt feststellbar, welche Vorgabe tatsächlich geprüft wurde? Wird ein erneuter Lauf verständlich vom früheren Ergebnis unterschieden? Entscheiden Sie vorab, wann Kopien, ein kontrollierter Export oder andere festgelegte Referenzen erforderlich sind. Das geeignete Verfahren muss auch gemeinsam genutzte Schritte und Parameter berücksichtigen.

Quellen: [2] [3] [12]

5. Pipeline-Erfolg und Nutzungsentscheidung verbinden

Eine Pipeline kann erfolgreich enden, obwohl sie nur einen Teil der notwendigen Prüfungen enthält. Legen Sie deshalb fest, welche Tests automatisch laufen, welche außerhalb der Pipeline stattfinden und wie aus beiden Bereichen ein belastbarer Entscheidungsstand entsteht. Ein nicht veröffentlichter oder falsch zugeordneter Ergebnisdatensatz darf nicht stillschweigend als bestanden gelten.

Für Azure DevOps Services dokumentiert Microsoft Ressourcen-Checks außerhalb der YAML-Datei. Diese werden durch Ressourcenadministratoren verwaltet. Selbstgenehmigung ist konfigurierbar; bestimmte Checks können mit entsprechender administrativer Befugnis umgangen werden. Die bloße Existenz eines Approval-Schritts beantwortet folglich weder die Befugnisfrage noch die fachliche Bedeutung der Bestätigung.

Definieren Sie für Ihre Auslieferung eine eindeutige Entscheidung: Welches Paket darf für welchen Verwendungszweck in welche Umgebung? Beziehen Sie offene Abweichungen und betriebliche Voraussetzungen ein. Eine technische Deployment-Erlaubnis kann Teil dieses Verfahrens sein. Ob sie zugleich eine ausreichende elektronische Signatur darstellt, ist bei entsprechendem Verwendungszweck gesondert zu bewerten.

Quellen: [5] [11]

6. Änderungen und administrative Ausnahmen prüfen

Repos kann Branch Policies erzwingen. Microsoft unterscheidet jedoch ausdrücklich das Umgehen von Regeln beim Abschluss eines Pull Requests und beim direkten Push. Kontrollieren Sie diese Rechte zusammen mit den Rechten, Regeln oder Pipeline-Ressourcen selbst zu verändern. Eine sorgfältig konfigurierte Prüfung verliert ihren Zweck, wenn derselbe unkontrollierte Weg sie dauerhaft ausschalten kann.

Die Prüffälle sollten die tatsächlich erlaubten und verbotenen Handlungen Ihrer Rollen abbilden: Testvorgabe ändern, Ergebnis nachtragen, Auslieferung auslösen, Freigaberegel anpassen und einen Notfalleingriff durchführen. Eine kleine Organisation benötigt dafür keine erfundene Standardzahl an Unterschriften. Sie benötigt eindeutige Befugnisse, angemessene Kontrollen und vertretbare Zuständigkeiten.

Azure-DevOps-Auditing ist laut aktueller Learn-Dokumentation Public Preview, standardmäßig ausgeschaltet und an eine Microsoft-Entra-Organisation gebunden; Server ist nicht eingeschlossen. Bewerten Sie den konkreten Ereigniskatalog. Work-Item-Historie, Repository-Historie, Organisationsaudit und Entra-Protokolle beantworten verschiedene Fragen. Ein einzelner Export ist nicht automatisch deren vollständige Zusammenführung.

Quellen: [8] [6] [11]

7. Ergebnisse und Kontext über die benötigte Frist erhalten

Microsoft beschreibt, dass beim Löschen eines Pipeline-Runs unter anderem Logs, Build-Artefakte, Testergebnisse und Run-Metadaten entfallen. Test- und Release-Retention sind nicht automatisch gleichgeschaltet; Paketarten wie NuGet oder npm werden von anderen Regeln gesteuert. Das Organisationsaudit hält Ereignisse grundsätzlich 90 Tage vor. Eine pauschale Einstellung „alles bleibt erhalten“ kann diese unterschiedlichen Bereiche verfehlen.

Erstellen Sie ein Datenverzeichnis mit Eigentümer, Speicherort, Aufbewahrungszweck und erforderlichem Kontext. Dazu gehören etwa Testvorgaben, Ergebnisanlagen, Fehlversuche, Abweichungsentscheidungen, Paketidentität und die dafür relevanten Änderungen. Bestimmen Sie Fristen anhand der unterstützten Tätigkeit und der geltenden Dokumentationsregeln, nicht anhand eines voreingestellten Produktwerts.

Prüfen Sie einen typischen alten Nachweis nach Export oder Wiederherstellung: Sind die Beziehungen noch verständlich, Anlagen lesbar und Versionen erkennbar? Ein Bericht als PDF kann für eine Übersicht nützlich sein. Er ersetzt die weiteren erforderlichen Daten nur, wenn deren Inhalt und Bedeutung für den vorgesehenen Zweck angemessen erhalten bleiben.

Quellen: [7] [6] [12] [11]

8. Illustratives Beispiel: 100 Prozent bestanden, aber zwei Nachweislücken

Das folgende Beispiel ist frei konstruiert und wurde nicht in einem Kundenprojekt oder einer Azure-DevOps-Organisation ausgeführt. Eine kleine GMP-Anwendung soll Materialstatus, Berechtigungen und einen Export korrekt verarbeiten. Für Build B105 sind drei Testfälle in jeweils zwei Browserkonfigurationen vorgesehen. Pro Kombination gelten dieselbe Suite und genau ein festgelegter Tester: insgesamt sechs Testpunkte.

Fünf vorhandene Ergebnisse lauten „passed“. Ein davon betroffenes Ergebnis wurde jedoch nur gegen B104 erzeugt. Die Übertragbarkeit auf B105 ist noch nicht bewertet. Der sechste Testpunkt wurde nicht ausgeführt. Die Beispielentscheidung zählt deshalb nur Ergebnisse, die unmittelbar für B105 geeignet sind.

• Fehlenden Lauf und alten Buildbezug sichtbar lassen; ursprüngliche Ergebnisse erhalten.
• Für den B104-Nachweis die Änderungswirkung bewerten und die Entscheidung über Übernahme oder erneute Prüfung begründen.
• Den fehlenden Chrome-Exporttest durchführen oder eine fachlich vertretbare Änderung des Prüfplans vor der Entscheidung begründen.
• Den abschließenden Nachweisbericht mit dem tatsächlich ausgelieferten Paket und verbleibenden Abweichungen verbinden.

Quellen: [3] [4] [11]

9. Aufwand durch einen begrenzten, betreibbaren Umfang steuern

Ein KMU sollte zuerst einen repräsentativen Nachweisprozess vollständig durchspielen. Dafür werden ein fachlicher Verantwortlicher, ein Systemverantwortlicher, Tester sowie die erforderlichen Entwicklungs- und Administrationskenntnisse benötigt. QA wirkt entsprechend ihrer festgelegten Aufgabe mit. Entscheidend sind verfügbare Entscheidungen und verständliche Nachweise, nicht möglichst viele formal benannte Rollen.

Aufwandstreiber sind vor allem individuelle Prozessvorlagen, Erweiterungen, mehrere Projekte, externe Tester, eigene Agents, verteilte Ergebnisquellen und bisher unklare Aufbewahrung. Herstellerdokumentation kann Funktionen und Grenzen belegen. Die Zuordnung zum konkreten Einsatz, die Konfiguration und die eigenen End-to-End-Prüfungen bleiben zu bearbeiten.

Im Betrieb sind Änderungen an Testvorgaben, Reportabfragen, Agent-Images, Extensions und Deployment-Rechten zu bewerten. Für Server kommen geplante Patches hinzu; bei Services müssen Dienständerungen und relevante Ankündigungen in den eigenen Änderungsprozess gelangen. Prüfen Sie betroffene Nachweisketten gezielt erneut. Ein unverändert grüner Lauf allein zeigt nicht, dass ein geänderter Bericht weiterhin dieselbe Aussage liefert.

Quellen: [1] [9] [11]

10. Checkliste vor der Verwendung als Validierungsnachweis

Die folgende Arbeitshilfe bündelt die Entscheidungspunkte. Sie ist kein Microsoft-Zertifikat und kein pauschaler Pflichtenkatalog. Jede Antwort sollte auf einen konkreten Projektstand verweisen. Offene Punkte werden mit Verantwortlichem und Auswirkung auf die beabsichtigte Nutzung festgehalten.

• Verwendungszweck und GMP-relevante Nachweisaussagen eindeutig beschrieben.
• Services oder Server sowie installierte Erweiterungen, Agents und relevante Lizenzgrenzen erfasst.
• Anforderungs-, Testfall- und Konfigurationsstände dem jeweiligen Lauf zugeordnet.
• Auswahl und Bezugsgröße der Berichte einschließlich fehlender Prüfungen verstanden.
• Build, Auslieferungspaket und Zielumgebung über die gesamte Entscheidung verbunden.
• Änderungs-, Lösch-, Bypass- und Administrationsrechte praktisch geprüft.
• Fachliche Nutzungsentscheidung von technischem Pipeline-Status unterschieden.
• Aufbewahrung für Testdaten, Runs, Pakete und relevante Historien abgestimmt.
• Export beziehungsweise Wiederherstellung mit lesbarem Nachweiskontext erprobt.
• Änderungsbewertung, Zuständigkeiten und Vertretung für den Betrieb geregelt.

Quellen: [11] [12]