Certyn separates what to run (tests) from how/when to run it (processes).
Tests (test cases)
A test is a reusable natural-language check. Tests should be:
- focused on one workflow
- explicit about expected outcomes
- written against stable test data
Example:
Go to the login page.
Sign in using LOGIN_USERNAME and LOGIN_PASSWORD from the environment variables.
Verify the dashboard loads and shows the user menu.
Processes (suites)
A process is a suite definition that:
- selects tests by tags (for example:
smoke,checkout,p0) - optionally runs on a schedule (daily/weekly/cron)
- can trigger when an environment version changes
This is how you build "always-on" coverage without manually deciding what to run each time.
Process kinds
Not every process runs native Certyn tests. A process has a kind, which decides where its cases come from and who executes them. All four report into the same run history and the same test health numbers.
| Kind | Cases come from | Executed by |
|---|---|---|
| Suite | Certyn test cases, selected by tag | Certyn |
| Agent | Nothing to author; the agent explores from a goal | Certyn |
| External suite | TestRail, Zephyr Scale, Xray, or Azure Test Plans, pulled fresh at run time | Certyn, with results written back to your tool |
| Automation | Your own Playwright, Cypress, Jest, or JUnit suite | Your CI. Results are pushed to POST /api/ci/results and ingested as already-finished runs |
An Automation process is created automatically on first push, one per suite slug you send. It has no schedule and no trigger, because your pipeline decides when it runs. See Bring Your Test Framework and Connect a Test Management Tool.
Custom process MVP (hidden agent)
Custom processes use a simplified model where the agent is hidden behind process settings. You configure:
namegoal(required) — what the agent should testtrigger(Manual only in MVP)
The agent always runs in exploratory mode. You do not configure tools, model, or prompt internals directly for MVP.
MVP limitations
- Custom process trigger is manual-only
- Anthropic native memory is disabled. Project memory is wiki-backed and editable from the Wiki page.
Standard processes (created automatically)
New projects come with standard processes already created:
| Process | What it does | When it runs |
|---|---|---|
App Explorer (app-explorer) | Explores the app, records memory, proposes bugs, and creates or updates test cases | Starts after onboarding completes, runs every 12 hours (UTC), and triggers on deploy |
Smoke Suite (smoke-suite) | Quick critical path verification | On deploy; selects smoke and critical tags |
Regression Suite (regression-suite) | Comprehensive suite | Daily (UTC); selects regression tag |
You can edit schedules/triggers, change tag selection, or disable any standard process.
Typical processes
| Process | Tag selection | When to run |
|---|---|---|
| Smoke | smoke | after every deploy |
| Regression | regression | nightly |
| Checkout | checkout, p0 | before release |
Overlap is normal
A single test can match multiple processes (for example tagged smoke and checkout). This is intentional: processes are filters, not folders.
Schedules and triggers
In a process settings page you can configure:
- Schedule: manual, daily, weekly, cron
- Automatic triggers: run when an environment's version changes
If your deployment pipeline updates the environment version (and changelog), processes can automatically run verification at the right moment.