Häufig stellt sich beim Thema „Werkzeug Validierung“ die Frage, ob man auch Testwerkzeuge (z.B. N/JUnit) und ALM-Tools (z.B. MedPack, JIRA, Microsoft TFS) validieren bzw. verifizieren muss.
Und falls die Antwort ja wäre, müsste man dann die zu dieser Validierung bzw. Verifizierung eingesetzten Werkzeuge selbst wieder prüfen? Da würde sich ja ein Teufelskreis auftun.
Dieser Artikel gibt einen Überblick über die regulatorischen Anforderungen und gibt Praxistipps zur Werkzeug Validierung.
Update: Aktuelle Erfahrungen, wie in Audits die Werkzeug-Validierung adressiert wird (mehr »)
Die Werkzeug Validierung ist ein Teilaspekt der Validierung von Software, die im Rahmen des QM-Systems eingesetzt wird. Klicken Sie hier, um mehr zur Computerized Systems Validation zu lesen.
Regulatorische Anforderungen an die Werkzeug-Validierung
Unterschätzen Sie nicht die regulatorischen Anforderungen und die Überprüfung derer durch Auditoren! Ich habe mir selbst schon Minor-Non-Conformities wegen mangelnder Tool-Validierung „eingefangen“.
Die Validierung von (Entwicklungs-)Werkzeugen ist gesetzlich vorgeschrieben
Die Anforderungen an die Werkzeug Validierung finden Sie v.a. in den Regularien mit Bezug zum Qualitätsmanagement.
1. Anforderung der ISO 13485 an die „Tool Validierung“
a) Kapitel 4.1.6 (Neu seit ISO 13485:2016)
Seit der 2016-er Ausgabe der ISO 13485 fordert die Norm explizit, dass die Hersteller Verfahren zur Software-Validierung für Software festlegen müssen, die das Qualitätsmanagementsystem nutzt. Diese Validierung sei risikobasiert durchzuführen.
Der Technical Report ISO 80002-2 gibt konkretere Hinweise,
- auf welche Software diese Anforderungen zutreffen,
- wie eine solche Validierung erfolgen kann und
- wie der Grad dieser Validierung mit dem Risiko korrelieren sollte.
Dieses neue Kapitel übernimmt teilweise die Forderungen der ISO 13485:2012 aus den Kapiteln 7.5.2.1 und 8.2.3.
b) Kapitel 7.6: Messmittel
Im Kapitel 7.6 (Lenkung und Erfassung von Messmitteln) schreibt die ISO 13485:
„Die Organisation muss Verfahren für die Validierung der Anwendung von Computersoftware dokumentieren, die für die Überwachung und Messung von Anforderungen eingesetzt wird. Derartige Softwareanwendungen müssen vor der ersten Verwendung validiert werden und, soweit angemessen, nach Änderungen an dieser Software oder deren Anwendung.“
D.h. Entwicklungswerkzeuge sind dann zu validieren, wenn Sie ein Messmittel darstellen.
Beispiele für diese Werkzeuge finden Sie weiter unten.
c) Kapitel 8.2.5: „Prozess-Messwerkzeuge“
Weiter lesen wir in Kapitel 8.2.5 „Überwachung und Messung von Prozessen“: „Die Organisation muss geeignete Methoden zur Erfassung und, soweit angemessen, Messung der Prozesse des Qualitätsmanagementsystems anwenden. Diese Methoden müssen darlegen, dass die Prozesse in der Lage sind, die geplanten Ergebnisse zu erreichen.“
D.h. Werkzeuge, die zur Messung von Prozessen des QM-System (z.B. des Entwicklungsprozesses) genutzt werden, müssen Sie ebenfalls der Werkzeug Validierung unterziehen.
Beispiele für diese Werkzeuge finden Sie weiter unten.
d) Kapitel 7.5.6: Werkzeuge mit Auswirkungen auf die Güte von Produkten und Prozessen
Im Kapitel 7.5.6 zur „Validierung der Prozesse zur Produktion und zur Dienstleistungserbringung“ finden Sie folgende Forderung (fast gleichlautend mit der in Kapitel 7.6):
„Die Organisation muss Verfahren für die Validierung der Anwendung von Computersoftware dokumentieren, die bei der Produktion und Dienstleistungserbringung eingesetzt wird. Derartige Softwareanwendungen müssen vor der ersten Verwendung validiert werden und, soweit angemessen, nach Änderungen an dieser Software oder deren Anwendung.“
D.h Sie müssen auch sonstige Werkzeuge validieren, die eine Auswirkung auf die Güte der Produkte haben.
Beispiele für diese Werkzeuge finden Sie weiter unten.
Validieren Sie alle Software, die einen Einfluss auf die Konformität Ihrer Produkte oder Ihres QM-Systems haben können. Führen Sie diese Validierung risikobasiert durch.
2. Anforderungen der FDA an die Validierung
Die FDA enthält in mehreren Teilen des 21 CFR Anforderungen an die Validierung von Software, von Messmitteln und sonstigen Werkzeugen. Dazu zählt auch der 21 CFR part 11 mit den elektronischen Unterschriften und Aufzeichnungen. Wie diese Validierung zu erfolgen hat, beschreibt die FDA im Guidance Document „Software Validation“, das sowohl auf Software anzuwenden ist, die Teil des Medizinprodukts ist, als auch auf Prozess-Software.
Klicken Sie auf diesen Link zum 21 CFR part 11.
Beispiele für Werkzeuge, die validiert werden müssen
Wohlgemerkt, wir sprechen hier nicht von der Software, die Teil des Medizinprodukts wird wie Datenbanken, Betriebssysteme, Bibliotheken und sonstige SOUPs, sondern von Werkzeugen.
1. Werkzeuge die der Messung des Produkts dienen
- Unit-Test-Werkzeug
- Werkzeug für die statische Code-Analyse wie Code-Metriken
- Automatische GUI-Tests
- Software im Prüfstand
- Werkzeug zum Auswerten von Fragebögen
Eine IDE muss nicht per se validiert werden, es sei denn sie enthält Messfunktionen, beispielsweise die eben genannten. Andere Werkzeuge wie Versionsverwaltungssysteme oder UML-Modellierungswerkzeug müssen Sie als Messsystem(!) nicht nicht validieren, als Prozesswerkzeug ggf. schon (s.u.).
2. Werkzeuge, die der Messung von Prozessen dienen
Viele Hersteller nutzen ALM- und Ticketing-System auch zur Messung der Prozessgüte um z.B. folgende Größen zu bestimmen:
- Anzahl der Fehler pro Zeiteinheit
- Verhältnis und Trends kritischer und unkritischer Fehler
- Zeiten zum Beheben von Fehlern
- usw.
3. Werkzeuge, die einen Einfluss auf die Güte von Produkten oder Dienstleistungen haben
Es gibt Werkzeuge, die einen direkten Einfluss auf die Güte von Produkten oder Dienstleistungen haben, die nicht den Messwerkzeugen zugeordnet werden können:
- Build-und Continuous Integrationsserver
- Versionsverwaltungssystem
- Byte-Code-Modifikation
- Compiler
- Produktionssteuerung
Wenn man argumentieren kann, dass Fehler in diesen Werkzeugen mit ausreichender Wahrscheinlichkeit erkannt würden oder hinreichend unwahrscheinlich sind, kann ggf. auf eine Validierung verzichtet werden.
4. Werkzeuge, die unter die Anforderungen des 21 CFR part 11 fallen
Diese Forderungen entstammen zwar der FDA, allerdings gehen viele europäische Auditoren analog vor. Sie müssen daher nachweisen, dass die elektronischen Unterschriften und elektronischen Dokumente nicht verfälscht werden können und sich die Autoren/Ersteller eindeutig und unabstreitbar identifizieren lassen.
Auch diese Werkzeuge — genau gesagt die Teile dieser Werkzeuge der den Messungen dienen — wären zu validieren.
5. Sonderfall Compiler
Compiler haben sicher auch einen Einfluss auf die Qualität der Software. Sie sind aber erst dann ein Messwerkzeug, wenn Sie den Compiler nicht nur nutzen, um einen Quellcode in ein binäres Artefakt zu überführen, sondern wenn Sie die Ergebnisse der statischen Code-Analyse nutzen, die so ein Compiler zweifelsfrei auch durchführt.
Wie bzw. wie intensiv sollten Sie ihren Compiler validieren? Hier gibt es sicher keine allgemeingültige Regel. Außer vielleicht den folgenden:
- Je weniger verbreitet Ihr Compiler ist, desto intensiver müssen Sie ihn validieren.
- Wenn Sie in Ihren Richtlinien Vorschriften an das Compiler-Level stellen, dann sollten Sie (zumindest exemplarisch) prüfen, ob der Compiler die mit diesem Compiler-Level verbundenen Prüfungen durchführt und Verstöße gegen diese Prüfregeln tatsächlich erkennt.
Tipps für die Validierung von Werkzeugen
Der Begriff Verifizierung in diesem Kontext erscheint bei Software etwas problematisch. Eigentlich ist es eine Validierung, nämlich eine Prüfung, ob das Werkzeug den Nutzungszweck tatsächlich erfüllt. Bei einem Testwerkzeug müsste beispielsweise geprüft werden, ob Fehler tatsächlich gefunden werden und ob das Werkzeug bei fehlerfreier Software auch keine Fehler meldet.
1. Auswahl der zu validierenden Werkzeuge begründen und dokumentieren
Zuerst sollten Sie bewerten, ob ein Werkzeug zu validieren ist – oder nicht. Dafür eignet sich am besten eine Checkliste, mit Sie charakterisieren, in welche Klassen von Typen (siehe oben) eine Software fällt. Die Hersteller nennen dieses Dokument unterschiedlich, beispielsweise „CSV Decision Matrix“ (CSV steht für Computer System Validation). Identifizieren und charakterisieren Sie in dieser Tabelle die Werkzeuge anhand folgender Punkte:
- Typischer Name des Werkzeugs
- Version des Werkzeugs
- Hersteller
- Art des Werkzeugs
- kurze Beschreibung des Einsatzzweckes bzw. eine Referenz darauf
- Typ(en) (siehe oben)
2. Anforderungen an die zu validierenden Werkzeuge beschreiben
Falls ein Werkzeug validiert werden muss, sollten Sie beschreiben, wozu Sie das Werkzeug einsetzen wollen. Man nennt das häufig eine User Requirements Specification URS. Wenn Sie das minimal kurz halten wollen, können Sie das auch in der oben genannten Tabelle dokumentieren. Wir haben diese Angaben auch schon in Test-Spezifikationen gefunden. Gleich wo, Sie müssen das dokumentieren.
Mein Tipp: Beschränken Sie den Aufwand für die Verifizierung/Validierung der Messwerkzeuge (zumindest solange diese bereits im Markt bewährt sind), indem Sie v.a. die absolute und für Sie relevante Kernfunktionalität sowie die Bereiche der Software prüfen, die Sie durch Konfiguration für sich spezifisch gestaltet haben (Customizing). Sie wollen die Qualitätssicherung ja nicht zum Selbstzweck machen, sondern für sich (und den Auditor) weitgehend sicherstellen, dass die Werkzeuge ihren Zweck erfüllen. Die Wahrscheinlichkeit einen Fehler in einem 100.00-fach eingesetzten Werkzeug wie NUnit, CPPUnit oder JUnit zu finden, ist eher gering.
Wie gesagt, fokussieren Sie sich auf den für Sie spezifischen Teil des Werkzeugs („Customizing“) und die eigene Software selbst. Die Wahrscheinlichkeit in der eigenen Software einen Fehler zu haben, ist um Größenordnungen höher als bei kommerziellen oder Open-Source Werkzeugen. Eine Werkzeug Validierung kann in 30 Minuten abgeschlossen sein.
3. Test spezifizieren (Plan für Werkzeug Validierung beschreiben)
Eine Testspezifikation für ein Werkzeug unterscheidet sich nicht notwendigerweise von einer, die Sie für die Verifikation des Produkte verwenden. Sie können also das gleiche Template verwenden. Es sollte enthalten:
- Eine eindeutige Referenz auf das Werkzeuges, das geprüft wird
- Die Testdaten
- Die Vorbedingungen für den Test (die Werkzeug Validierung)
- Das Vorgehen beispielsweise welche Daten in welcher Reihenfolge wo einzugeben sind
- Ggf. andere Werkzeuge, die Sie zum Validieren des Werkzeuges nutzen
- Die Nachbedingungen, d.h. die erwarteten Testergebnisse einschließlich von Pass-Fail-Kriterien
Als Premium-Mitglied im Auditgarant können Sie sich so ein Template direkt herunterladen.
Achten Sie darauf, dass Ihre Tests alle Anforderungen, die Sie unter 1. bzw. 2. formuliert haben, auch wirklich geprüft werden.
4. Werkzeug Validierung durchführen und dokumentieren
Der Testreport dokumentiert die Ausführung des Tests insbesondere die Testergebnisse. Er lässt die Beurteilung zu, ob gemäß der Testspezifikation validiert wurde und ob die tatsächlichen Ergebnisse den erwarteten entsprechen. Idealerweise enthält der Testreport auch die Entscheidung, ob das Werkzeug auf Grund der durchgeführten Tests als validiert gilt. Sonst benötigen Sie eine separates Dokument dafür.
Der Testreport enthält auch Meta-Informationen wie den Tester, das Datum und die Unterschrift.
Zusammenfassung
Sie benötigen somit folgende Dokumente bzw. Informationen
- Liste der Software-Werkzeuge
- Für jedes Software-Werkzeug eine Entscheidung, ob es validierungspflichtig ist
- Für jedes validierungspflichtige Werkzeug die Anforderungen, die das Werkzeug erfüllen muss
- Für jedes validierungspflichtige Werkzeug eine Testspezifikation und
- einen Testreport inklusive bzw. sowie
- eine Entscheidung, ob die Validierung des Werkzeugs erfolgreich war
Werfen Sie einen Blick in die ISO 80002-2, die die Validierung von Software für das QM-System und andere Prozesse beschreibt.
Weitere Gedanken und Tipps
- Denken Sie an die Dokumentenlenkung! Packen Sie alles in ein Versionsverwaltungssystem oder auf eine CD. Wiederholen Sie diese Prüfung, wenn Sie Ihr Werkzeug updaten.
- Sie müssen natürlich nicht über den Source-Code des Werkzeugs verfügen. Die Verifizierung/Validierung ist ein Blackbox-Testing.
- Die Werkzeuge, die Sie zur Prüfung der Werkzeuge einsetzen, müssen Sie nicht selbst validieren/verifizieren (es sein denn, Sie setzen diese Werkzeuge auch zum Prüfen des eigentlichen Produkts/Prozesses ein). Andernfalls käme man ja in einen unendlichen Zyklus.
Bei den Audits, die ich selbst über mich ergehen ließ oder bei denen ich meine Kunden unterstützte, war es meist entscheidend, dass das Werkzeug überhaupt und sei es noch so minimal geprüft und dies auch dokumentiert wurde. Der Umfang dieser Prüfungen wurde nie bemängelt. Falls dies doch erfolgen sollte, empfehle ich, den Auditor auf die Wahrscheinlichkeiten aufmerksam zu machen, einen Fehler in einem Werkzeug und im eigenen Code zu finden. Er soll bitte seinen Auditschwerpunkt darauf zu legen, wo die Fehler am wahrscheinlichsten sind. Und das bleibt nun mal der eigene Code.
Tool-Validierung im Audit
Seit meiner Tätigkeit als Auditor bei einer benannten Stelle, habe ich viele Auditoren-Kollegen beobachten können, wie diese die Werkzeug-Validierung adressieren:
- Die Validierung der Tools ist bei fast jedem Audit ein Thema!
- Bei Software-Testwerkzeugen ziehen die Auditoren eher das Kapitel 7.5.6 der ISO 13485 als das Kapitel 7.6 (Messmittel) heran. Damit sind die Anforderungen etwas höher: Die Hersteller müssen nicht nur die Eignung eines Messmittels nachweisen, sondern eine explizite Software-Validierung durchführen.
- Verstöße gegen diese Normkapitel werden meist als Minor-Nonconformity bewertet. D.h. das Zertifikat wird nicht ausgesetzt, aber der Hersteller muss nach einem Audit einen Plan vorlegen, wie und wann er diese Normabweichung beheben wird. Die Norm sagt dazu „ohne ungerechtfertigte Verzögerung“…
Lieber Christian,
ich habe eben Deinen Blog gelesen. Mich nervt der Zwang zur Validierung von Testwerkzeugen nicht. Es beschwert sich ja auch keiner, dass Messwerkzeuge kalibriert werden müssen. Und ich halte beides für vergleichbar. Gut, ich gebe zu, es gibt sicherlich Trivialfälle, wie eben Dein JUnit.
Aber häufig ist es eben nicht dieser Fall. Mittlerweile werden hochkomplexe Werkzeuge für Test eingesetzt. Einer meiner Kunden führt Komponententests aus, bei dem Test auf der Basis von LabView geschrieben werden, ein anderer verwendet Open Source-Tools zur Unit-Tests von VHDL-Code, ein weiter verwendet selbst geschriebene Simulatoren in Kombination mit einen kommerziellen Testwerkzeug. Sollen alle unterstellen, dass die Werkzeuge schon tun, was wir von ihnen erwarten?
Besser nicht. Vor zwei Wochen ist es immerhin schon im dritten Anlauf gelungen, ein Testwerkzeug zu validieren. Die beiden vorherigen Male schlugen fehl, weil der Anwender falsche Vorstellungen darüber hatte, wie sich das Werkzeug verhielt bzw. verhalten sollte.
Als Fazit: Ja, manchmal ist es lästig. Trotzdem sollten wir keinesfalls auf die Validierung verzichten.
Liebe Grüße
Bernhard
Hallo Christian,
besonders ist der Markt an ALM Tools so unheimlich groß. Wenn man die Auswahl an Tools für die komplette Toolkette anschaut, noch riesiger. Da kommt man aus der Evaluierung, wenn man alles abdecken will, fast gar nicht mehr raus.
Danke für den ausführlichen Artikel!
LG
Jochen
Hallo Herr Johner,
warum müssen Ihrer Meinung nach Versionsverwaltungssysteme nicht validiert werden? Ich würde diese in die Kat. „Werkzeuge, die einen Einfluss auf die Güte von Produkten oder Dienstleistungen haben“ einstufen. Beispielsweise werden einerseits (typischerweise) Änderungen protokolliert (Check in Comments) andererseits Baselines gezogen (für alle Releases) oder auch die vollständige Rückverfolgbarkeit / Wiederherstellung von alten Konfigurationen gewährleistet.
Liebe Grüße
Udo Klinger
Lieber Herr Klinger,
der Beitrag war an der Stelle missverständlich: Es geht in dem Kapitel um Messwerkzeuge. Üblicherweise ist ein Versionsverwaltungssystem kein Messwerkzeug.
Ein Versionsverwaltungssystem ist aber ein Prozesswerkzeug. Da man sich bei der Konfigurationsverwaltung eines Software-Systems sich darauf verlassen muss, dass es funktioniert, wäre es als Prozesswerkzeug zu validieren.
Ich habe Dank Ihrer Anregung dies im Artikel überarbeiten können. Danke für Ihre hervorragende Frage!
Beste Grüße
Christian Johner
würden Sie C++ Compiler als validierungspflichtig einstufen?
Den Compiler nicht notwendigerweise, aber die Compiler-Settings würde ich prüfen. Die sollten auch unter Versionskontrolle sein.
Moin Moin!
Zunächst möchte ich mich für diese zahlreichen, sehr ausführlichen und informativen Blog-Beiträge bedanken!
Und dann habe ich noch eine kurze Frage bezüglich Softwarevalidierung (13485:2016 betreffend). Für z.B. Tabellenkalkulationen kann ich mir da ja was einfallen lassen, die Mängel von Excel sind ja bekannt und gut dokumentiert.
Aber wie sieht es z.B. mit der Auslesesoftware von (kalibrierten) Dataloggern aus? Wir haben einige Geräte, die ein LCD besitzen und Temperatur- und Luftfeuchte anzeigen (aktuell sowie Min/Max). Da kann ich regelmäßig mir mal Werte notieren und nach dem Auslesen der Logger einen Vergleich vornehmen. Aber es gibt auch Modelle ohne Interface, nur mit USB-Anschluß. Was kann man da machen? Oder reicht ein Zertifikat vom Softwarehersteller, solange man die Spezifikationen an die Computerhardware einhält? (Gibt es überhaupt Loggerhersteller mit solchen Zertifikaten?)
Liebe Grüße
W. Kürschner
Sie müssen an die Produkte Anforderungen stellen und deren Erfüllung prüfen. Das macht man i.d.R mit Tests. Natürlich können Tests nicht die Korrektheit beweisen. Das ist auch nicht verlangt. Wenn Sie bei dem Logger wie beschrieben vorgehen, ist das gut. Schauen Sie nur, dass alle Anforderungen and den Logger geprüft werden, die relevant sind — z.B. Performanz.
Software ohne jede Schnittstelle kenne ich nicht. Bei einem USB-Anschluss liegt eine Schnittstelle vor — es ist ja ein Bussystem. Was über diesen Bus ausgetauscht werden soll, gilt es zu spezifizieren und verifizieren. Lassen Sie die Kirche im Dorf und agieren Sie „risk based“.
Zertifikate von Herstellern benötigen Sie nicht.
Hallo Herr Johner,
hat sich eigentlich durch die ISO 13485:2016 die Tool-Validierung nicht vereinfacht? Das Kapitel 4.1.6 spricht ja von einer risikobasierte Validierung. Der Grad der Validierung ist mir noch nicht ganz klar. Vielleicht können Sie mich ein bisschen aufschlauen?
Liebe Grüße,
Philipp Ott
Lieber Herr Ott,
in der Tat dürfen und sollten die Aufwände für die Validierung risikobasiert sein. Validierung ist allerdings nicht nur als Prüfung zu verstehen, ob Anforderungen erfüllt sind. Validierung ist hier im breiteren Kontext zu verstehen, die ggf. den ganzen Software-Lebenszyklus umfasst.
Im Artikel zur CSV finden Sie weitere Details. Zudem arbeite ich gerade daran, eine mehrteilige Serie dazu für den Auditgarant zu entwickeln.
Weitere Infos gerne auch vorab per E-Mail.
Danke für Ihre wichtige Anmerkung, herzliche Grüße und beste Grüße
Christian Johner
Ich bin nicht ganz sicher ob ich die Frage und das Akronym „OP“ richtig verstehe.
Wenn Sie eine validierungspflichtige Software ändern, muss zumindest diskutiert werden, weshalb eine Revalidierung nicht oder nur in Teilen notwendig ist. Solche Überlegungen müssen risikobasiert und in der Regel unter Bezugnahme der SW-Architektur erfolgen.
Über die Frage, ob die Überprüfung eine Verifizierung oder Validierung ist, lässt sich trefflich streiten. Der Begriff „Validierung“ ist doppelt belegt. Mehr dazu lesen Sie im Beitrag über Verifizierung und Validierung.
Das Testen von Cloud-Anwendungen birgt immer gewissen Herausforderungen. Dennoch ist es immer möglich.
Es tut mir leid, dass ich ob der Frage nicht spezifischer antworten kann.
Hallo,
was ist mit zB Partikelmessgeräten? gehören die auch Validiert oder reicht da eine Kalibrierung?
Vielen Dank
mfg
B. Ruhdorfer
Sehr geehrte Frau Ruhdorfer,
eine Kalibrierung genügt nicht, zumindest nicht, wenn man den Begriff in der Definition der QM-Welt versteht. Diese Definition finden sie hier.
In Ihrem Fall wäre wahrscheinlich eine Kalibrierung und eine Justierung notwendig. Zudem müssen Sie sicherstellen, dass die Werkzeuge kalibriert bleiben.
In der Hoffnung geholfen zu haben und mit vielen Grüßen, Christian Johner
Hallo,
mir stellt sich immer noch die Frage, wie denn die Validierung von Test Tools wie NUnit/JUnit oder Tools für automatisierte GUI Tests wie beispielsweise Selenium konkret aussehen soll.
Würde es am Beispiel NUnit ausreichen, einen NUnit Test für eine fehlerhafte Klasse zu schreiben und als Pass Criterium zu definieren, dass der Test fehlschlagen soll?
Oder ist es so, dass alle Funktionalitäten die NUnit mitbringt und die zum Testen eingesetzt werden, einzeln validiert werden müssten? Und falls letzteres zutrifft; setzt die Norm dann hier nicht völlig falsche Anreize, nachdem es für Hersteller dann vermutlich einfacher wäre, eigene Test-Tools (die am Ende dann eh die Funktionalitäten von Open Source Tools wrappen) zu validieren, die ja wie im Artikel auch schon erläutert tendenziell fehleranfällig sind als weithin genutzte Open Source bzw kommerzielle Tools?
Muss die Validierung dann mit jedem Versionsupdate von NUnit wiederholt und ggfs erweitert werden?
Und nachdem meist mehrere Tools zum automatisierten Testen eingesetzt werden; wie sollen die Hersteller eigentlich den damit verbundenen Overhead stemmen?
Danke schonmal.
Sehr geehrte Frau Bachem,
eine sehr wichtige Frage, die Sie stellen! Hier ein paar Gedanken dazu:
In der Hoffnung, etwas geholfen zu haben, und mit herzlichen Grüßen
Christian Johner
Sehr geehrter Herr Prof. Dr. Johner,
nach der Teilnahme am tollen Seminar CSV und jetzt der praktischen Umsetzung im Unternehmen, bin ich noch auf eine Stolperfalle gestoßen.
Beim Evaluieren, welche Tools im Haus denn so genutzt werden und in welcher Version, erhielt ich u.a. die Rückmeldung Software: Android Studio Version: ongoing developer updates.
Meine Frage: Wie geht man mit solchen „ongoing updates“ um? Für mich als QM-Manager ist es eigentlich nicht möglich, hier permanent alles im Blick zu haben. Ob die Entwickler immer darauf achten und informieren, wenn es ein Mini-Update gab, bezweifle ich.
Somit ist hier die eigentlich die Kontrolle der Versionierung der Cloud-basierten Tools fast nicht mehr machbar.
Gibt es Ansätze/ Ideen zur Lösung dieses Problems?
Kann man aus Ihrer Sicht mit Maßnahmen zur Minimierung des Risikos (Validierung der mit dem Tool erstellten Software) argumentieren, dass eine 1000% Versionskontrolle nicht notwendig ist?
Herzliche Grüße aus Frankfurt
Dr. Nina Rählert
Liebe Frau Rählert,
vielen Dank für Ihr positives Feedback und Ihre Frage!
Ich gebe Ihnen die Antwort von einem unserer Experten weiter:
„Liebe Frau Rählert,
vielen Dank für das Feedback zum CSV Seminar – das motiviert uns, die verschiedenen CSV Themen weiter zu vertiefen und einfache, praktische Lösungen für die verschiedenen Fragestellungen zu entwerfen.
Genau in jene Kategorie fällt Ihre Frage und darum, vielen Dank dafür! Bzgl. Entwicklungswerkzeugen und kontinuierlicher Updates würde ich unterscheiden, ob es tatsächlich eine cloud basierte Umgebung ist oder aber ein Werkzeug, das einfach in sehr kurzen Abständen Updates erhält. Android Studio gehört z.B. in letztere Kategorie. Ich würde das so handhaben, dass ich zu einem Zeitpunkt im Projekt die Version meiner Werkzeuge fixiere und diese in meiner Buildbeschreibung festhalte. In der Regel haben auch über Cloud ausgerollte SaaS Lösungen eine Versionsnummer. Haben Sie ein cloudbasiertes Werkzeug im Einsatz – z.B. für Ticketverwaltungz.B. Jira oder Microsoft Azure DevOps, haben Sie keine Einflussmöglichkeit auf Updates des Werkzeugs. Bewertung des Lieferanten, regelmässige Security Scan Berichte des Lieferanten und Kontrollen, z.B. Releasenotes, in regelmässigen Abständen – je nach Kritikalität z.B. alle 3 oder 6 Monate, wäre ein Ansatz einer kontinuierlichen Validierung.
Bei Tools mit häufigen Updates können Sie durchaus die Version zum Build Zeitpunkt aufbewahren. Ich würde aber im Rahmen der Weiterentwicklung die Toolversionen ebenfalls nachziehen. Sie müssen z.B. den Einfluss der Werkzeuge auf die IT Sicherheit Ihrer Produkte bewerten und im Blick haben und Entwickler wollen idR gerne die neuesten Funktionen verwenden. Das erfordert auch eine Validierung der Werkzeuge alle paar Monate. In aktuellen Projekten fahren wir diesbezüglich einen Ansatz aus Critical Thinking und Automatisierung: Wir bewerten z.B. den Einfluss des Werkzeugs auf unser Produkt und den Verbreitungsgrad. Haben wir genug Vertrauen, schliessen wir die Validierung an dieser Stelle ab. Für Tools mit hohem Einfluss versuchen wir Validierungstests nach Möglichkeit zu automatisieren oder in einer übergeordneten Prüfung der Toolchain unterzubringen, die aber auf die durch uns vorgenommenen Einstellungen beschränkt ist.
Bringt Sie das so schon einmal weiter?
Freundliche Grüße
Urs Müller“
Melden Sie sich gerne, wenn Sie weitere Unterstützung bei dem Thema benötigen.
Herzliche Grüße
Tea Bodrusic