Zum Hauptinhalt springen

Wie verbinden wir Produktentwicklung und Testberichte?

CertHub ist ein Engineering-Tool. Wenn Informationen an eine Behörde eingereicht oder von einer benannten Stelle geprüft werden, sollte CertHub die Datenautorität sein — der einzige kontrollierte Ort, an dem diese Informationen gepflegt werden.

Das heißt nicht, dass jede Datei, die dein Engineering-Prozess erzeugt, in CertHub liegen muss. Es bedeutet, dass die einreichungsrelevanten Informationen dort gepflegt werden, und alles andere dort bleibt, wo es entstanden ist — mit einem kontrollierten Link zurück.

Die praktische Aufteilung ist:

  • Behördenrelevante Daten leben in CertHub. Anforderungen, Design Inputs und Outputs, Zweckbestimmung, Risiken, Maßnahmen und die kontrollierte Verifikations- und Validierungsgeschichte werden in der Produktdatenbank gepflegt und dort getrackt.
  • Entwicklungsoutputs bleiben am Ort der Erstellung. Laborberichte, CI-Dashboards, JUnit-Bäume, generierte HTML-Reports und vollständige Testartefakte bleiben in deinem Testtool, CI-System oder Artefakt-Store. In CertHub hinterlegst du einen kurzen Nachweis-Record mit einem Link zu diesen Artefakten. Siehe Write Evidence Records für das API-Muster.

Die Entscheidung, die die meisten Teams treffen müssen​

Grundsätzlich gibt es zwei Wege, CertHub mit der restlichen IT-Landschaft zu verbinden. In vielen Fällen nutzt ein Unternehmen später beide.

1. Die API nutzen​

Wähle das, wenn dein Team Daten selbst in CertHub übertragen will.

Das ist in der Regel richtig, wenn:

  • du Anforderungen und Testnachweise jetzt nach CertHub bringen willst
  • deine IT oder dein Integrationspartner eine überschaubare Anbindung bauen kann
  • du Zeitplan und Rollout selbst steuern willst
  • du keinen tiefen täglichen Zwei-Wege-Workflow in einem bestimmten Entwicklungstool brauchst

2. Einen nativen Connector nutzen​

Wähle das, wenn du eine tiefere bidirektionale Verbindung mit einem konkreten Tool brauchst, das deine Teams täglich nutzen, zum Beispiel Jira, GitHub oder Confluence.

Das ist ein gemeinsames Projekt zwischen CertHub-Ingenieuren und deinem Team. Es geht nicht nur darum, "Daten rüberzuschieben", sondern gemeinsam festzulegen, welche Informationen synchron bleiben sollen und wie.

Es gibt kein zusätzliches Dritttool zwischen CertHub und deinem System. Gerade bei sensiblen Qualitäts- und Regulatorikdaten ist das wichtig.

Native Connectors sind nicht Self-Service

Native Connectors werden gemeinsam mit dem CertHub-Team eingerichtet. Um zu besprechen, ob ein Connector für deinen Anwendungsfall passt, wende dich an deinen CertHub-Ansprechpartner oder schreibe an support@certhub.de.

Auf einen Blick​

AnsatzAm besten geeignet fürWer baut es
APIEigene Automatisierung im eigenen TempoDein Team
Nativer ConnectorTiefere Zwei-Wege-Synchronisation mit einem konkreten ToolCertHub-Ingenieure gemeinsam mit deinem Team
hinweis

Diese Übersicht ist nicht vollständig. Wenn dein Tool oder dein Szenario hier nicht auftaucht, kann CertHub gemeinsam mit dir prüfen, was sinnvoll ist.

Was muss in CertHub eigentlich ankommen?​

Genau hier brauchen viele Teams Orientierung.

Anforderungen​

Produktanforderungen, Design Inputs, Design Outputs und die zugehörigen Nachweise sollten in der technischen Dokumentation ankommen — nicht nur in Jira, Polarion, Azure DevOps, GitHub oder einem Wiki.

Warum? Weil QM und RA eine kontrollierte Sicht darauf brauchen, was das Produkt leisten soll, wie diese Anforderung umgesetzt wurde und wie sie verifiziert wurde. CertHub ist der Ort, an dem diese kontrollierte Sicht gepflegt und eingereicht wird.

Testberichte​

Testberichte gehören als Verifikations- oder Validierungsnachweis nach CertHub, je nachdem, welche Rolle sie spielen.

CertHub ersetzt nicht dein Testtool oder den Laborablauf. CertHub schafft den kontrollierten, nachvollziehbaren Nachweis für die technische Dokumentation:

  • welche Anforderung geprüft wurde
  • welcher Test oder welche Verifikationsaktivität sie stützt
  • welche Nachweisdatei dazugehört

Der vollständige Bericht selbst — das PDF, das HTML-Dashboard, die Rohdaten — bleibt dort, wo er erstellt wurde. In CertHub pflegst du den kontrollierten Record und einen Link zu diesem Artefakt. So bleibt der Nachweis nachvollziehbar und auditierbar, ohne schwere Dateien zu duplizieren.

Welche Option solltest du wählen?​

Nutze diese einfache Regel:

  • Wenn Anforderungen und Testnachweise jetzt und nach eurem eigenen Zeitplan nach CertHub kommen sollen, wähle die API.
  • Wenn deine Entwicklungsteams einen tieferen täglichen Zwei-Wege-Workflow mit einem konkreten Tool brauchen, plane einen nativen Connector mit CertHub.
  • Wenn du nur einmal eine Tabelle übernehmen willst, nutze den Import und belasse es dabei.

Was du nicht tun solltest​

Das sind die häufigsten Fehler, die Teams bei der Verbindung von Entwicklung und CertHub machen:

  • Behalte die behördenrelevante Quelle der Wahrheit nicht in Word, Confluence oder dem Entwicklungstool. Wenn Informationen an eine Behörde eingereicht oder im Audit verteidigt werden sollen, pflege sie in CertHub. Eine Kopie in Jira oder Confluence ist keine kontrollierte technische Dokumentation.
  • Kippe keine vollständigen Testberichte, CI-Bäume oder Dashboards in CertHub. Diese Outputs gehören dorthin, wo sie erstellt wurden. Speichere sie in deinem CI-System, Artefakt-Store oder Labor-Tool und halte in CertHub einen kontrollierten Nachweis-Record mit Link. Siehe Write Evidence Records.
  • Importiere keine Testnachweise, ohne sie mit der Anforderung zu verknüpfen, die sie stützen. Unverknüpfte Nachweise schwächen deine Audit-Story, selbst wenn der Test gut durchgeführt wurde.
  • Behandle Beschwerden, CAPAs oder Audits nicht wie Produktentwicklungsdaten. Das sind QMS-Aktivitäten, die durch SOPs, Templates mit Input Fields und QM Lists gesteuert werden — keine Produktdaten. Siehe Wo gehört diese Information hin?.
  • Pflege keine zweite, unverbundene Kopie von Risiken oder Anforderungen außerhalb von CertHub. Wenn CertHub die Datenautorität ist, sollte das Entwicklungstool eine synchronisierte Kopie aus CertHub erhalten, nicht umgekehrt.

Ein praktisches Beispiel​

Stell dir vor, deine Design Inputs liegen in Jira und deine Verifikationsberichte entstehen außerhalb von CertHub als PDFs.

Der empfohlene Aufbau ist:

  • die Entwicklung arbeitet weiter in Jira
  • die relevanten Anforderungen werden nach CertHub übernommen — CertHub wird die kontrollierte Quelle der Wahrheit für diese Anforderungen
  • nach Abschluss der Verifikation wird ein kurzer Nachweis-Record nach CertHub geschrieben, mit einem Link zum vollständigen Bericht im Artefakt-Store
  • das PDF bleibt im Artefakt-Store oder Labor-System; CertHub hält den kontrollierten Verweis

So erhalten QM und RA eine prüfbare Sicht auf die technische Dokumentation, ohne dass das Engineering seine gewohnten Werkzeuge aufgeben muss, und ohne schwere Dateien in ein System zu kopieren, das sie nicht speichern muss.

Zwei Richtungen, nicht nur eine​

Die meisten Teams denken daran, Daten nach CertHub zu bringen, aber die Verbindung funktioniert in beide Richtungen:

  • Hinaus: Exportiere kontrollierte Anforderungen und Verifikationsdefinitionen, damit deine Engineering-Tools sie nutzen können.
  • Hinein: Schreibe beim Release einen kurzen Nachweis-Record zurück nach CertHub, der auf den vollständigen Nachweis in deinem CI- oder Artefakt-Store verweist.

Der Nachweis-Record muss nicht den gesamten Build-Baum oder jedes Testergebnis enthalten. Eine Versionsnummer, ein Commit, ein Zeitstempel, eine URL zum CI-Lauf und eine kurze Zusammenfassung reichen oft aus. Behalte die großen Artefakte dort, wo sie hingehören, und gib CertHub den kontrollierten Verweis.

Wenn dein Produkt Software enthält, lies Wo lebt das V-Modell bei Softwareentwicklung? für einen tieferen Blick darauf, welche Teile des V-Modells nach CertHub gehören und welche außerhalb bleiben.

Empfehlung​

Wenn deine unmittelbare Frage lautet: "Wie bekommen wir Anforderungen und Testberichte nach CertHub?", dann ist die Antwort meist über die API.

Plane einen nativen Connector dann, wenn der fachliche Bedarf größer ist und ihr einen fortlaufenden Zwei-Wege-Workflow in einem konkreten Tool wollt.

Funktionierendes Beispiel

Cadence ist CertHubs öffentliches Engineering-Beispiel. Es setzt den API-Ansatz um; useblocks (Sphinx-Needs / CodeLinks / Test-Reports) ist der optionale Last-Hop-Toolchain in diesem Repo. Siehe Working example.

Wenn du das jetzt in CertHub umsetzen willst​