Skip to main content
Get quick answers to the most common questions about TestDino. Browse through topics including getting started, API keys, test runs, integrations, and billing. Click on any question to expand the answer.

​
Getting Started

TestDino is a Playwright-focused test reporting and management platform with MCP support. It ingests Playwright results from CI or local execution and provides actionable insights.How it works:
  1. Add @testdino/playwright to the reporter array in your Playwright config
  2. Set TESTDINO_TOKEN and run npx playwright test
  3. Results stream to TestDino as tests run and link to branches/PRs
  4. View results in dashboards, track trends in Analytics, and create tickets from failures
TestDino eliminates the 6 to 8 hours teams spend weekly on manual test failure analysis.
  • Manual triage - Error grouping clusters failures by root cause
  • Scattered evidence - Aggregates screenshots, videos, traces, and logs in one place
  • No historical context - Tracks trends and flakiness across runs
  • Slow handoffs - Pre-fills Jira/Linear/Asana tickets with full context
  • Unclear readiness - GitHub CI Checks give clear pass/fail signals
To get started:
  1. Create an organization and a project
  2. Generate an API key from your project settings
  3. Install @testdino/playwright and add it to your Playwright config
  4. Set TESTDINO_TOKEN and run npx playwright test
For detailed instructions, see Getting Started.
Add @testdino/playwright to your Playwright config. It reads results directly from the run, so there is no report file to upload. Test results, metadata, and structure stream as tests finish.Artifacts stream too, when Playwright produces them:
  • Traces - For interactive step-by-step debugging
  • Videos - For visual test playback
  • Screenshots - For failure evidence
Set use.trace, use.video, and use.screenshot in your playwright.config.js to control which artifacts Playwright captures.
No. TestDino works with your existing Playwright tests without code modifications.You only need to:
  1. Add @testdino/playwright to the reporter array in your playwright.config.js
  2. Set TESTDINO_TOKEN and run your tests as usual
TestDino reads Playwright’s standard results. It doesn’t require custom annotations, special imports, or framework changes.

​
Setup and Configuration

Playwright reporters show a single run snapshot. TestDino adds:
  • Cross-run analytics: Trends and failure patterns over time
  • Error grouping: Cluster failures by error message and root cause
  • Git and PR awareness: Links test runs to commits, branches, and PRs
  • Integrations: Jira, Linear, Asana, Slack, GitHub
  • Historical tracking: Stability scores and regression detection
Playwright shows what happened. TestDino explains ‘why’ and ‘what’ to do next.
TestDino officially supports Playwright tests written in JavaScript and TypeScript via the @testdino/playwright package.Add it to your Playwright config and results stream to TestDino as tests run.
Add @testdino/playwright to your Playwright config, then run your tests. Results stream as they finish, with no separate upload step:
playwright.config.ts
To stream without editing your config, run npx tdpw test -t "$TESTDINO_TOKEN" --server-url https://reporter.testdino.com instead.
Yes. TestDino works with monorepos without special configuration.Each Playwright project in your monorepo streams to the same or different TestDino projects. Add @testdino/playwright to each package’s Playwright config, then run its tests with the matching token set. Each package streams independently:
Use separate TestDino projects if you want isolated analytics, or one project if you want unified reporting.
Yes. TestDino doesn’t require your test code and application code to be in the same repository.TestDino reads Playwright results directly from the run, not from your source code. As long as your CI runs the tests with @testdino/playwright configured, results stream to TestDino. Use environment mapping to link branches across repos if needed.For GitHub integration, install the TestDino app on the repository where tests run. PR comments and CI checks will appear there.
No. MCP (Model Context Protocol) is completely optional.TestDino works fully through:
  • Web dashboard - View test runs and analytics
  • Streaming - @testdino/playwright sends results live as tests run
  • Integrations - GitHub, Slack, Jira, Linear, Asana
MCP is an add-on for AI-assisted workflows. It lets you query test data through Cursor or Claude Desktop using natural language. You can ignore it entirely if you prefer the web UI.

​
API Keys and Authentication

  1. Go to Project Settings. API Keys
  2. Click Generate Key
  3. Name the key and set an expiration (if available)
  4. Copy the secret immediately and store it in your secret manager
  5. Set it as the TESTDINO_TOKEN environment variable, then run your tests
API Keys Management
  1. Generate a new key in Project Settings. API Keys
  2. Update CI secrets with the new key
  3. Run your tests once to confirm results stream with the new key
  4. Revoke or delete the old key
API failures:
  • Verify your API token is set correctly (TESTDINO_TOKEN for streaming, TESTDINO_API_TOKEN for the Public API)
  • Check internet connectivity
  • Look for HTTP status codes in error messages
Run ID not found:
  • Use list_testruns to confirm the run exists
  • Verify you’re querying the correct project
  • Check if the run ID format is correct (or use the counter instead)

​
Test Runs and Results

Add @testdino/playwright to your Playwright config, then run your tests with the token exposed as a secret. Results stream during the run:
Check these:
  1. API key: Verify TESTDINO_TOKEN is set, correct, and not expired
  2. Reporter added: Confirm @testdino/playwright is in the reporter array in your Playwright config
  3. Project match: The token must have access to the target project
  4. Run output: Check the test output for TestDino errors
  5. Sync: Click the Sync button in the Test Runs view
Run with --debug (npx tdpw test --debug) for detailed streaming logs.
Test Run: One full execution of your suite, equivalent to one playwright test commandTest Run ViewTest Case: One individual test, equivalent to one test() blockTest Case DetailsSpec file: One test file that contains one or more test casesSpec File ViewSpec Tab View
It groups tests by cause with KPI tiles:
  • Failed - Assertion Failure, Element Not Found, Timeout, Network, Other
  • Flaky - Timing, Environment, Network, Assertion, Other
  • Skipped - Manual, Configuration, Conditional Test Run Summary
Detailed Analysis shows each test with status, spec file, duration, retries, failure cluster, and 10-run history preview.Filter using tokens: s: (status), c: (cluster), @ (tag), b: (browser).Detailed Analysis
Traces are accessible in two places:
  1. Test Run Summary - Each failed/flaky test case row includes a “Trace #” link. Click it to open the full Playwright trace viewer.
  2. Test Case Details > Trace tab - The interactive Playwright trace shows timeline, actions, network calls, console output, and DOM snapshots. Jump directly to the failing step for root-cause analysis.
Traces open in Playwright’s trace viewer, letting you inspect exactly what happened during test execution.Trace Viewer
Traces are interactive debugging tools. In Trace Viewer, you can see actions, network calls, console logs, and DOM snapshots. You can step through execution, inspect element states, and see exactly what Playwright did at each moment.Trace ViewerVideos are screen recordings of test execution. They show what the browser rendered, but don’t provide interactive debugging or network/console data.Trace and Video ViewerUse videos for quick visual review and, trace viewer for deep debugging of failures.
Yes. Use search and filters across Test Runs, and Errors views to:
  • Search by commit message or run number
  • Filter by status (passed, failed, flaky, skipped)
  • Filter by committer, branch, or environment
  • Group failures by error message in the Errors view Error View with Filters
Requirements:
  1. GitHub integration must be installed and connected
  2. Test runs must include commit SHA metadata
  3. The branch must be associated with an open PR
Verify:
  • Check Settings > Integrations > GitHub shows connected
  • Confirm the CI job runs in a git checkout so commit and branch metadata reach TestDino
  • Ensure PR exists for the branch

​
Flakiness and Test Health

TestDino identifies flaky tests by analyzing behavior across attempts and runs:Within a single run:
  • A test that fails initially but passes on retry is marked flaky
  • Retry attempts are tracked separately
Across multiple runs:
  • Tests with inconsistent outcomes (pass in one run, fail in another) without code changes
  • Historical stability percentage calculated as (Passed ÷ Total Runs) × 100
TestDino also sub-categorizes flaky tests by root cause: Timing Related, Environment Dependent, Network Dependent, Assertion Intermittent, or Other Flaky.
Multiple views available:
  1. Dashboard - “Most Flaky Tests” section
  2. Analytics - add the Flakiness trend widget to a dashboard
  3. Test Cases History - Stability score and “Last Flaky” tile
  4. Test Explorer - “Flaky Rate” column for all spec files and test cases
The Test Case History tab shows:
  • Stability % - (Passed ÷ Total Runs) × 100
  • Last Status Tiles - Links to Last Passed, Last Failed, Last Flaky runs
  • Execution History Table - Status, duration, retries per run (expandable for error details)
History is scoped to the current branch.GitHub CI Checks Configuration

​
Integrations

TestDino supports:
  • CI/CD - GitHub, GitLab, Azure DevOps, TeamCity
  • Issue tracking - Jira, Linear, Asana, monday
  • Communication - Slack App, Slack Webhook
  1. Install the TestDino GitHub App
  2. Select repositories to grant access
  3. In Settings > Integrations > GitHub, configure:
    • Comments - Enable PR and commit comments per environment
    • CI Checks - Enable checks with pass rate thresholds
Quality Gate Settings:
  • Pass Rate - Minimum % of tests that must pass (default: 90%)
  • Mandatory Tags - Tests with these tags (e.g., @critical) must all pass
  • Flaky Handling - Strict (flaky = failure) or Neutral (flaky excluded from calculation)
  • Environment Overrides - Different rules per environment GitHub CI Checks Configuration
Most common reason: A Mandatory Tag test failed.If you configured @critical as mandatory and one critical test fails, the check fails regardless of the overall pass rate.Other causes:
  • Flaky Handling set to “Strict” and flaky tests present
  • Environment Override has stricter rules than defaults
  1. Connect the integration in Project Settings. Integrations
  2. Configure the default project (Jira) or team (Linear)
  3. Open a failed test case in TestDino
  4. Click Raise Bug or Raise Issue
  5. The issue is created with test details, error message, failure history, and links

​
Environment Mapping and Branch Management

Environment Mapping links Git branches to environments (Production, Staging, Dev) using exact names or regex patterns.Configure in Settings > Branch Mapping.Why it matters:
  • Rolls up short-lived branches (feature/*, PR branches) to the correct environment
  • Enables environment-specific CI Check rules
  • Routes Slack notifications to the right channels
  • Filters dashboards and analytics by environment
Learn more at Environment Mapping.
Environment comes from branch mapping. TestDino reads the run’s branch from git metadata and applies the matching pattern, so main can map to production and staging to staging.To route several environments from one commit, map each branch pattern to its environment. See Environment Mapping for the pattern rules.
The run appears without an environment label and may not appear in environment-filtered views.Solutions:
  • Add a catch-all pattern (e.g., .* → Development)
  • Add patterns that match your branch naming convention
  • Runs remain visible in the unfiltered Test Runs list
See Environment Mapping Best Practices for details.

​
Organizations and Projects

Organization: Top-level container for your team, users, billing, and settingsOrganization OverviewProject: One test suite or application with its own runs, keys, and integrations. Actions in one project don’t affect othersProject ViewHierarchy: Organization → Projects → Test Runs
  1. Go to your organization’s Users & Roles tab
  2. Click Invite Member and enter their email address
  3. Assign a role (Owner, Admin, Member, or Viewer)
  4. Track invitations and adjust roles as your team grows
  • Owner - Full control, can invite/update/remove anyone
  • Administrator - Manages people, projects, settings, and integrations, can’t remove Owner
  • Member - Contributes to projects
  • Billing Manager - Manages subscriptions, invoices, and payments, no test data access
  • Viewer - Read-only access
See Users & Roles for the full permission matrix.

​
Billing and Pricing

Plans are typically based on test executions and user or project limits.Usage is measured monthly. A retry counts as another execution. Track usage in Settings > Usage & Quota. Usage resets monthly on your cycle date.
A test execution is one test case run:
  • Each test case counts as one execution (skipped tests are excluded)
  • Retries count separately - A test with 2 retries = 3 executions
  • Artifacts do not affect execution count
  • Usage is tracked monthly and resets on your billing cycle date
  • Overage, if applicable, is billed on the next invoice
  • Upgrade if you consistently hit limits
  • Access continues until the current billing period ends
  • No future charges after cancellation
  • The organization moves to the Community plan
  • Retention and limits fall back to the Community plan
  1. Go to Manage Billing in your organization
  2. Click View All Plans
  3. Select the plan
  4. Confirm the change
Upgrades typically apply immediately. Downgrades typically take effect at the end of the current billing period.

​
Security and Privacy

Yes. TestDino is SOC 2 Type 2 certified, covering Security, Availability, and Confidentiality, and is also ISO 27001 certified and GDPR compliant. See Security & Compliance for the full posture, or email support@testdino.com for audit reports or a signed DPA.
Data is encrypted in transit over HTTPS with TLS 1.2 or higher, and at rest with AES-256 via Azure platform encryption. See Security & Compliance.
No. AI features run on enterprise AI providers under contractual terms that prohibit training their models on customer content. You can also disable AI per project. See AI data handling.

​
Still Have Questions?

Glossary

Look up TestDino and Playwright testing terms

Discord

Join the community for questions and updates.

Email

Contact us at support@testdino.com