Report Publishing

Overview

TestOps allows you to publish shareable, public links for any completed test run report. Recipients can view the full test results, code coverage data, error summaries, and individual test details — all without needing a TestOps account or any authentication. This makes it easy to keep stakeholders, QA leads, product managers, and external reviewers informed about test health across your projects.

Each shared link is secured with a unique, cryptographically random token. Links can be set to expire after a specific date, revoked instantly if needed, and include built-in view tracking so you know exactly who has seen the report. Whether you are sharing results in a pull request, a Slack channel, or a sprint review meeting, report publishing gives you a single link that tells the whole story.

Publishing a Report

Publishing a report takes just a few clicks. Follow these steps to generate a shareable link for any completed test run:

1. Navigate to a completed test run by going to Runs in the sidebar and clicking on the run you want to share.
2. Click the "Share" or "Publish Report" button in the run detail header. This opens the share dialog.
3. A unique shareable link is generated with a secure, cryptographically random token. Optionally set an expiration date (see below).
4. Copy the link and share it via Slack, email, PR comments, Jira tickets, or any other channel your team uses.

The generated link follows this format:

The token is a URL-safe string that uniquely identifies the shared report. Anyone with the link can view the report — no login required. The link remains active until it expires or is explicitly revoked.

What the Report Shows

The shared report provides a comprehensive, read-only view of the test run. Recipients see the same detailed information that authenticated users see on the run detail page, including:

• Run status and metadata — Project name, branch, commit SHA, trigger type (manual, scheduled, or CI), and the timestamp of the run.
• Test summary — Total test count with a breakdown of passed, failed, and skipped tests displayed as headline numbers.
• Duration and timing — Total run duration, average test duration, and slowest tests highlighted for performance awareness.
• Status distribution chart — A donut chart visualizing the pass/fail/skip ratio at a glance.
• Error summary — Grouped error messages with occurrence counts, making it easy to identify the most common failure patterns.
• Full test results list — Every individual test with its status, duration, and error details. Includes filtering by status (all, passed, failed, skipped) and a search bar to find specific tests by name.
• Code coverage — Line coverage, branch coverage, and function coverage with percentage bars showing how much of the codebase is covered.
• CI run link — If the test run was triggered by a CI pipeline, a direct link to the CI run (GitHub Actions, GitLab CI, Jenkins, etc.) is included.
• View count — A counter showing how many times the shared report has been viewed, displayed in the report header.

Setting Expiration

When creating a share link, you can optionally set an expiration date. After the expiration date passes, anyone who visits the link will see an "expired" message instead of the report content. The report data is not deleted — only the public access is removed.

Expiration is useful for time-sensitive reports such as:

• Sprint reviews — Share results for a two-week window, then let the link expire automatically after the sprint closes.
• Release approvals — Provide stakeholders with a link that is valid until the release decision is made.
• External audits — Give auditors temporary access to test evidence without leaving permanent public links.
• Client demos — Share quality metrics with a client for a limited time during an evaluation period.

If you do not set an expiration date, the link remains active indefinitely until you manually revoke it. You can always update the expiration date later from the run detail page.

Revoking Access

If you need to immediately revoke access to a shared report — for example, if a link was shared with the wrong audience or the report contains sensitive information — you can disable it instantly:

1. Go to the run detail page for the run whose report you want to revoke.
2. Find the active share link in the share panel. It will show the link URL, creation date, expiration (if set), and current view count.
3. Click "Revoke" to immediately disable the link.

Once revoked, anyone who visits the link will see a "revoked" error message. Revocation is instant and permanent — the same token cannot be re-activated. If you need to share the report again, you can generate a new link with a new token.

View Tracking

Each time a shared report is viewed, the view count increments. This helps you confirm that stakeholders have actually reviewed the test results rather than just receiving the link.

View counts are visible in two places:

• Run detail page — The share panel shows the total view count next to the active link, so you can check engagement from within TestOps.
• Shared report header — The public report page itself displays the view count, so viewers can see how many others have also seen the report.

View tracking is particularly useful in code review workflows. When you post a report link in a PR comment, you can check back later to see whether reviewers have actually looked at the test results before approving the PR.

Using Reports in CI/CD

For teams that want to automate report sharing, the TestOps API lets you create share links programmatically. This is ideal for embedding test report links directly into your CI/CD pipeline output.

Common integration patterns:

• After a test run completes, use the TestOps API to create a share link automatically.
• Post the link as a PR comment so code reviewers have immediate access to test results.
• Include the link in deployment approval workflows so release managers can verify test health before promoting a build.
• Link from your CI dashboard (GitHub Actions summary, GitLab CI job output, Jenkins build page) for easy access.

API Example— Create a share link with an expiration date:

Request:

Response:

Use the returned url field directly in your CI scripts. For example, in a GitHub Actions workflow you could use gh pr comment to post the link as a PR comment, or in GitLab CI you could echo it to the job output.

Best Practices

Follow these recommendations to get the most out of report publishing:

• Set expiration dates for external stakeholders — When sharing reports with people outside your organization (clients, auditors, contractors), always set an expiration date to limit the window of public access.
• Use permanent links for internal dashboards — For internal tools, status boards, or wikis that reference test results, create links without expiration so they remain accessible long-term.
• Share reports in PR descriptions — Including a TestOps report link in your pull request description gives reviewers immediate context about test health, coverage changes, and any new failures introduced by the change.
• Track view counts to confirm engagement — Before a release decision or sprint review, check the view count to ensure that the relevant stakeholders have actually reviewed the test results.
• Revoke links when no longer needed — Periodically review your active share links and revoke any that are no longer relevant. This reduces your public surface area and keeps your sharing history clean.
• Automate sharing in CI pipelines — Use the API to automatically generate and post report links after every test run. This removes the manual step and ensures that every PR and deployment has an associated test report.