Automated tests produce detailed evidence, but release communication often ends in a spreadsheet, a copied CI link, or a message assembled by hand.

That manual summary creates a second source of truth. Totals can be copied incorrectly, missing results can disappear from the story, and the report no longer proves which execution evidence somebody reviewed.

QaCockpit uses a different boundary: build the stakeholder report from the stored Test Execution or Campaign Run, review the exact content, and then create a versioned snapshot for delivery.

Start with the audience, not a blank document

The same evidence should not force every recipient to read the same level of detail. QaCockpit provides three starting templates:

  • Executive for overall state, change, top risks, and recommended actions;
  • QA / Technical for results, completeness, sources, failure clusters, and provider context;
  • Release evidence for environment, branch or ref, completeness, risk, and the facts needed for a release decision.

The sender can include or remove individual sections and add a short note. The preview is then regenerated from the selected template, sections, note, and current report source. There is no editable total that can drift away from the underlying evidence.

Keep completeness beside the pass rate

A report should not call a run healthy merely because the reported tests passed. It must also explain whether every required Test Source reported, whether the expected test scope was present, and whether required artifacts arrived.

Useful report sections therefore include:

  • total, passed, failed or error, skipped, and unknown results;
  • change from the previous comparable report;
  • expected results that were not reported;
  • source-report and artifact completeness;
  • top Failure Clusters and recommended next steps;
  • environment, release, ref, and commit evidence when available.

This is especially important for multi-source campaigns. A single percentage cannot distinguish a complete regression from a partial collection that happened to be green.

Review once, then choose the delivery channel

The review step shows the subject, next version, and rendered report before any delivery action. PDF, email, and read-only links use the selected snapshot rather than rebuilding an informal summary in each channel.

Generated QaCockpit release-evidence PDF showing version, result totals, report comparison, top risks, recommended actions, and missing expected tests.

The downloaded PDF preserves the same release conclusion and completeness evidence that was reviewed in the application.

Each completed snapshot receives a sequential version for that Execution or Campaign Run. Its rendered content and source payload are stored together, so a later product change does not silently rewrite a report that was already shared.

Treat sharing as an auditable operation

Different delivery mechanisms have different security and operational properties:

  • a PDF is generated for an authenticated user and downloaded directly;
  • email can target project-member suggestions or another validated address;
  • a read-only link expires after 1 to 30 days and can be revoked early;
  • the full secret URL is displayed only when the link is created;
  • link tokens are stored as hashes rather than recoverable plaintext;
  • delivery and link activity remains visible to authorized users and administrative actions are audited.

Email status also needs honest wording. Sent means the configured transport accepted the message; it does not claim that the recipient opened it or that every inbox accepted it.

Preserve evidence instead of creating presentation debt

The goal is not to produce a prettier spreadsheet. It is to remove the step where a human reconstructs quality state outside the system that owns the evidence.

A versioned report remains connected to:

  • the exact Test Execution or Campaign Run;
  • the imported JUnit results;
  • expected-scope and missing-result checks;
  • source, environment, branch, and commit context;
  • grouped failures and protected artifacts;
  • the person and time associated with the sharing action.

That gives QA, engineering, and release stakeholders different levels of detail without giving them different facts.

For the multi-source execution model behind these reports, read Regression campaigns without replacing your CI/CD. If your release report is still assembled by hand, request a quality-landscape review.