Skip to main content

​
Talk to sales and book a demo

If you’re evaluating Checksum, start by talking to our team. In the demo we walk through your application and testing goals, then agree on a POV scope: which product areas, which environment, and what success looks like.

Book a demo →

Meet the Checksum team and see the agent on an app like yours.

Contact your Checksum team

Add a project, environment, or repository, or expand your POV scope.

​
What is a Proof of Value?

A POV is a time-boxed evaluation where Checksum builds and maintains real tests against your application, so you can judge the results on your own code rather than a sample app. Most of the work in a POV is ours. Your team’s main job is to unblock access before kickoff, so the evaluation window goes to results instead of waiting on credentials or firewall changes.
1

Demo

We learn about your application, stack, and testing pain points.
2

Scoping

We agree on the product areas, environment, and success criteria for the POV, and set a kickoff date.
3

Pre-kickoff access

You complete the access checklist below. Before kickoff, we verify our Playwright bot and AI can reach your site and that the codebase connection works.
4

Kickoff

We walk through the plan, confirm test users and roles, and start detection on the agreed areas.
5

POV period

Checksum detects flows, generates tests, runs them, and heals them. Tests arrive as pull requests, and bugs appear in the Feature Health Dashboard.
6

Decision

We review results against the success criteria together.
Why set up before kickoff?If the access below is in place before the kickoff date, nothing blocks the decision period or our deliverables. The most common cause of a slow POV start is an environment behind a VPN or firewall that hasn’t allowlisted our IPs.

​
Pre-kickoff checklist

This is everything we need from your team.
  • Shared the UAT (test) environment URL
  • Shared user credentials for logging in to that URL (one per role you want tested)
  • If behind a VPN/firewall: allowlisted Checksum’s IP addresses
  • Confirmed nothing blocks automated browsers (bot protection, CAPTCHA, WAF rules) on the UAT environment
  • Connected the front-end repository with read-only access (GitHub App approved, or token details sent)
  • Identified someone with owner/admin rights on the VCS organization to approve the connection

​
1. Access to the testing environment(s)

To begin testing, we need access to your UAT (test) environment: Before kickoff, we verify that our Playwright bot isn’t blocked and that our AI can reach the site without issues. Please resolve access blockers early, ideally before the POV kickoff date, so they don’t delay our deliverables or your evaluation.

​
If your environment is behind a VPN or firewall

If your UAT environment sits behind a VPN or similar protection, allowlist Checksum’s IP addresses so our AI traffic can reach the site. Your Checksum contact will send you the addresses to allowlist as part of pre-kickoff planning.

​
2. Connecting your codebase

Checksum needs read-only access to your front-end repository. Our AI agents use the source code as context when they detect and generate new E2E tests, and when they update existing tests that fail at runtime. Without it, the agents can only see the rendered UI. With it, they ground tests in your actual components, routes, and data flows.

​
Supported version control systems

​
GitHub

Select the repositories that contain the front-end codebase from the Checksum interface:
1

Log in

Sign in at app.checksum.ai.
2

Open Settings → Git Integration

Go to Settings, then the Git Integration tab.
3

Click Connect

Below Codebase repository, click Connect and follow the walkthrough.
4

Approve the GitHub App

Approve the Checksum bot (GitHub App) request on GitHub. This may require a user with owner-level permissions.
Permissions requested by Checksum’s GitHub bot:
  • Read access to metadata and repository hooks
  • Read and write access to actions, code, issues, and pull requests
Why write access if the codebase is read-only?The same GitHub App also serves your tests repository, where Checksum opens pull requests with generated and healed tests. Checksum never writes to your code repository. On a code repo, the effective access is Metadata: Read, Contents: Read, Pull requests: Read. You can limit the app to specific repositories at install time. See the full permissions table.
On GitHub Enterprise Cloud with data residency (*.ghe.com)? Follow GitHub Enterprise instead.

​
GitLab

  1. Provide the repository Project ID.
  2. Create a Personal Access Token (PAT) with the minimum permissions:
    • Scopes: read_api, read_repository
    • Role: Reporter
Reference: GitLab: project access tokens

​
Azure DevOps

  1. Provide the Organization name.
  2. Provide the Project name.
  3. Create a Personal Access Token (PAT) with the minimum permissions:
    • Code: Read
Reference: Microsoft: use personal access tokens
Azure DevOps is supported for code repositories only. Checksum-managed tests repositories aren’t supported on Azure DevOps today, so the tests repository lives with another provider. We’ll agree on where during scoping.

​
Bitbucket

  1. Provide the Workspace name.
  2. Provide the Repository name.
  3. Create an Access Token (AT) with the minimum permissions:
    • Repositories: Read
    • Pull requests: Read
Reference: Atlassian: repository access tokens
That’s everythingOnce the criteria above are met, Checksum can begin. Questions? Reach out to your Checksum contact.

​
What Checksum sets up for you

Once access is in place, the Checksum team does the initial project setup. You don’t need to install anything to get started.

​
After kickoff: what your team does

  • Review pull requests. Generated and healed tests arrive as PRs in your tests repository. Review and merge them like any other code. See Review and merge.
  • Answer the agent’s questions. Deep-mode sessions ask clarifying questions and wait for you to approve a plan. See Agent Sessions.
  • Triage bugs. When the agent classifies a failure as an application bug, it appears in the Feature Health Dashboard for you to confirm or dismiss.
  • Invite teammates and add users. Add more test users or environments as scope grows. See Environments & Test Users.
  • Wire up CI and notifications when you’re ready. See CI/CD Integration and Notifications & Slack.

​
FAQ

The pieces are documented (Test Repository & Config, Git Integration, Environments), but new projects are created and configured by the Checksum team. Start with a demo.
No. A POV runs against your UAT/test environment. You can add more environments (e.g. staging) later.
The requirement is read-only access to the front-end repository. That’s what grounds selectors, routes, and flows.
Microsoft Entra ID sign-in is supported. See Microsoft Entra ID SSO for what your IT team needs to approve.