What is the output of the test planning phase?

A full test plan tagged by category and visible in your dashboard and in the PR comment. After execution, you get a complete report: tests run, issues found with severity classification, reproduction steps, video evidence, screenshots, and the specific lines of code responsible for each failure.

How are issues classified?

When Ito finds a problem, it is classified independently by severity based on business impact (Critical, High, Medium, Low) and by whether it is attributable to the current PR or pre-existing in the base branch. PR-attributable failures determine pass/fail status. Pre-existing issues surface as additional findings without failing the PR.

Can we control what Ito tests?

Yes. Add plain-English instructions at the org or repo level to tell Ito which flows to prioritize, deprioritize, or skip on specific PR types. Individual engineers can also name specific tests directly in the PR description to focus a run, and can ask Ito to run additional tests after a run completes.

Targeted Test Plans

Before any test runs, someone has to figure out what is worth testing.

On most teams, that work falls on a senior engineer who ends up acting as the QA for every PR: reading the diff, mapping it to the journeys it could break, and turning that judgment into test cases that go stale the next time the markup moves. More time goes into maintaining that coverage than into catching real bugs, and the bottleneck hits hardest when velocity should be highest.

AI made that bottleneck worse. Six months ago your team was merging ten PRs a week. Now it is thirty. The code output tripled, and the process for deciding what to test stayed the same. Someone still has to connect the diff to the risk surface, and when the volume outpaces that person, things slip through without anyone noticing.

Reading the diff shows what changed, not what breaks when it runs.

Reading the diff, whether a code review tool or person, tells you which files changed. It does not tell you which user journeys the change puts at risk, which edge cases are now live, or what the rest of the codebase assumed about the behavior that moved.

When coverage depends on a human connecting a diff to a user journey, what gets tested depends on who reviewed the PR that day, not on what the change put at risk. That is the gap Ito fills.

How it works.

Set up once: connect your repo and add any plain-English instructions about what matters most to your team. From there, every PR runs on its own.

Step 1

Ito reads the PR

When a PR opens, Ito reads the full diff as its primary source, along with the PR description. If the description names specific tests to run, Ito runs those. When a linked ticket is available, it uses that as added context. Ito builds a picture of what this change was intended to do, not only which files it touched.

Step 2

Ito builds the test plan

Ito decides what to test in three ways:

The change itself. The diff and PR description, with no setup required. This works on the first PR, before you have configured anything. The plan is weighted toward what the change actually touches, so a PR that touches authentication gets different coverage than one that touches a billing flow. No two plans are the same.
Your priorities. Instructions set at the repo, user, or organization level for what matters most: security, accessibility, mobile usability, performance, whatever your team prioritizes.
What Ito has learned. Which bugs your team fixes, which you close as won't fix, and the feedback you give on past plans. Ito uses that signal to weight what it tests on future PRs, so teams that ship auth-heavy changes get sharper auth coverage over time. The plans get more accurate the more you use it.

Step 3

Tests start running right away

As soon as the plan is built, tests begin executing, each one tagged by category. You can watch the plan and its progress in the PR comment and in the Ito dashboard. If you want Ito to cover something more, you can ask for additional tests after the run. What happens during execution is covered in the next section.

How it works.

Set up once: connect your repo and add any plain-English instructions about what matters most to your team. From there, every PR runs on its own.

Step 1

Ito reads the PR

When a PR opens, Ito reads the full diff as its primary source, along with the PR description. If the description names specific tests to run, Ito runs those. When a linked ticket is available, it uses that as added context. Ito builds a picture of what this change was intended to do, not only which files it touched.

Step 2

Ito builds the test plan

Ito decides what to test in three ways:

The change itself. The diff and PR description, with no setup required. This works on the first PR, before you have configured anything. The plan is weighted toward what the change actually touches, so a PR that touches authentication gets different coverage than one that touches a billing flow. No two plans are the same.
Your priorities. Instructions set at the repo, user, or organization level for what matters most: security, accessibility, mobile usability, performance, whatever your team prioritizes.
What Ito has learned. Which bugs your team fixes, which you close as won't fix, and the feedback you give on past plans. Ito uses that signal to weight what it tests on future PRs, so teams that ship auth-heavy changes get sharper auth coverage over time. The plans get more accurate the more you use it.

Step 3

Tests start running right away

As soon as the plan is built, tests begin executing, each one tagged by category. You can watch the plan and its progress in the PR comment and in the Ito dashboard. If you want Ito to cover something more, you can ask for additional tests after the run. What happens during execution is covered in the next section.

What Ito plans on every PR

The categories are not a fixed checklist. A PR that modifies an auth flow gets adversarial tests, permission boundary checks, and session handling edge cases. A PR that touches a billing calculation gets logic tests focused on pricing rules, state transitions, and role-based gating. A UI-only change gets happy-path coverage and UX checks. Some example categories are:

Happy-path tests
The core user journeys still work end to end: signing in, completing a key action, submitting a form, navigating between pages.
Edge case tests
Unusual but valid inputs real users will hit: empty states, very long strings, special characters, expired sessions, slow connections, browser back and forward, refresh mid-flow.
Adversarial tests
The ways a careless or impatient user will break things: double submits, rapid repeated clicks, navigating to states that should not be reachable, attempting actions without permission.
Logic tests
The business rules behind the UI: pricing math, conditional display, role-based gating, state transitions, totals and counters reflecting the right values.
Accessibility tests
Keyboard navigation, focus order, ARIA labels, color contrast, screen reader behavior on interactive elements.
Mobile tests
The same journeys under a mobile viewport: responsive layout, touch targets, and mobile-specific behaviors like sticky headers or bottom navigation.
UX tests
The things a careful reviewer would catch by eye: confusing copy, broken affordances, layout regressions.

Questions teams ask before using Ito.

Common questions from engineering managers, senior engineers, and QA leads.

Three ways, and all three work together. First, the diff and PR description: this is zero-shot and works with no setup, on the first PR. Second, instructions your team sets at the repo, user, or organization level to prioritize what matters most, like security, mobile usability, or accessibility. Third, what Ito learns over time from the bugs your team fixes or closes as won't fix and the feedback you give on test plans. The result is a plan targeted at the real risk surface of that change, personalized to your team and sharper with every run.