Skip to main content

How do we connect product development and test reports?

CertHub is an engineering tool. If information will be submitted to an authority or reviewed by a notified body, CertHub should be the data authority — the single controlled place where that information is maintained.

That does not mean every file your engineering process produces must live inside CertHub. It means the information that matters for the submission lives there, and everything else stays where it was created with a controlled link back.

The practical split is:

  • Authority-relevant data lives in CertHub. Requirements, design inputs and outputs, intended use, risks, controls, and the controlled verification and validation story are maintained in the Product Database and traced there.
  • Development outputs stay at the place of creation. Lab reports, CI dashboards, JUnit trees, generated HTML reports, and full test artifacts stay in your test tool, CI system, or artifact store. In CertHub you keep a short evidence record with a link to those artifacts. See Write Evidence Records for the API pattern.

The decision most teams need to make​

There are generally two ways to connect CertHub to the rest of your IT landscape. In many cases, a company ends up using both.

1. Use the API​

Choose this when your team wants to send data into CertHub itself, at its own pace.

This is usually the right option when:

  • you want to bring requirements and test evidence into CertHub now
  • your IT or integration partner can build a straightforward connection
  • you want control over timing and rollout
  • you do not need a deep two-way day-to-day workflow in a specific engineering tool

2. Use a native connector​

Choose this when you need a deeper two-way connection with a specific tool your teams use every day, for example Jira, GitHub, or Confluence.

This is a joint effort between CertHub engineers and your team. The point is not just to "send data across," but to agree which information should stay synchronized and how.

No third-party middleman tool sits between CertHub and your system, which matters when you handle sensitive quality and regulatory data.

Native connectors are not self-serve

Native connectors are set up together with the CertHub team. To discuss whether a connector fits your use case, contact your CertHub representative or reach out at support@certhub.de.

At a glance​

ApproachBest forWho builds it
APIYour own automation, on your own timelineYour team
Native connectorA deeper two-way sync with a specific toolCertHub engineers together with your team
note

This overview is not exhaustive. If your tool or scenario is not listed here, CertHub can assess what is appropriate for your setup.

What should actually end up in CertHub?​

This is the part many teams need help with.

Requirements​

Device requirements, design inputs, design outputs, and related evidence should end up in the technical documentation, not only in Jira, Polarion, Azure DevOps, GitHub, or a wiki.

Why? Because QM and RA need a controlled view of what the device must do, how that requirement was implemented, and how it was verified. CertHub is where that controlled view is maintained and submitted from.

Test reports​

Test reports belong in CertHub as verification or validation evidence, depending on the role they play.

CertHub does not replace your test tool or laboratory workflow. It gives you the controlled, traceable evidence you need in the technical file:

  • which requirement was checked
  • what test or verification activity supports it
  • which evidence file belongs to it

The full report itself — the PDF, the HTML dashboard, the raw output — stays where it was created. In CertHub you maintain the controlled record and a link to that artifact. That way the evidence is traceable and auditable without duplicating heavy files.

Which option should you choose?​

Use this as the simple rule:

  • If you want requirements and test evidence to reach CertHub now, on your own timeline, choose the API.
  • If your engineering teams need a deeper day-to-day two-way workflow with a specific tool, plan a native connector with CertHub.
  • If you only need a one-time move from a spreadsheet, use import and stop there.

What not to do​

These are the most common mistakes teams make when connecting development and CertHub:

  • Do not keep the authority-relevant source of truth in Word, Confluence, or the development tool. If information will be submitted to an authority or defended in an audit, maintain it in CertHub. A copy in Jira or Confluence is not a controlled technical file.
  • Do not dump full test reports, CI trees, or dashboards into CertHub. Those outputs belong where they were created. Store them in your CI system, artifact store, or lab tool and keep a controlled evidence record with a link in CertHub. See Write Evidence Records.
  • Do not import test evidence without linking it to the requirement it supports. Unlinked evidence weakens your audit story even if the test itself was well executed.
  • Do not treat complaints, CAPAs, or audits like product-development records. Those are QMS activities driven by SOPs, Templates with Input Fields, and QM Lists — not product data. See Where does this information belong?.
  • Do not maintain a second disconnected copy of risks or requirements outside CertHub. If CertHub is the data authority, the development tool should receive a synced copy from CertHub, not the other way around.

A practical example​

Imagine your design inputs live in Jira and your verification reports are generated outside CertHub as PDFs.

The recommended setup is:

  • engineers continue working in Jira
  • the relevant requirements are transferred into CertHub — CertHub becomes the controlled source of truth for those requirements
  • when verification is complete, a short evidence record is written back to CertHub with a link to the full report in your artifact store
  • the PDF stays in your artifact store or lab system; CertHub holds the controlled pointer

This gives QM and RA a reviewable technical-file view without forcing the engineering team to abandon its normal tools, and without copying heavy files into a system that does not need to store them.

Two directions, not just one​

Most teams think about getting data into CertHub, but the connection usually works in both directions:

  • Out: export controlled requirements and verification definitions so your engineering tools can use them.
  • In: when you release, write a short evidence record back into CertHub that links to the full evidence in your CI or artifact store.

The evidence record does not need to contain the full build tree or every test result. A version number, a commit, a timestamp, a URL to the CI run, and a short summary is often enough. Keep the heavy artifacts where they belong and give CertHub the controlled pointer.

If your product includes software, see Where does the V-model live when you develop software? for a deeper look at which parts of the V-model belong in CertHub and which stay outside.

Recommendation​

If your immediate question is, "How do we get requirements and test reports into CertHub?", the answer is usually the API.

Use a native connector when the business need is broader than that and you want an ongoing two-way workflow in a specific tool.

Working example

Cadence is CertHub’s public engineering example. It implements the API approach; useblocks (Sphinx-Needs / CodeLinks / Test-Reports) is the optional last-hop toolchain in that repo. See Working example.

When you are ready to do this in CertHub​