Quickstart
Author a test case, run it against a target environment, and review the evidence.
This guide gets you from a product journey to a reviewed Autonomy run. Start with one narrow flow, such as signup, checkout, invite acceptance, or password reset. After the first run is reliable, attach it to pull requests or release workflows.
Before you begin
You need
- An Autonomy organization with permission to create test cases and runs.
- A target URL, staging environment, preview deployment, or mobile artifact.
- A small user journey that has an obvious pass or fail outcome.
- Nothing else — signup journeys get a throwaway inbox automatically.
1. Add an environment
Open Environments and add the target you want to test: the base URL and any configuration the journey needs. Reference those values from steps as {{env.VAR_NAME}} rather than pasting them in, so the same case can run against preview, staging, and production.
You can skip this for a first run and paste a URL directly, but you will want it before the second one.
2. Author a test case
Go to Test Cases → New Test Case. Name it, pick the platform and environment, then choose how to author it:
- Record the flow — fastest for anything longer than a few steps. Launch a hosted browser session, perform the journey once, mark your checks with the toolbar as you go, then click End & review. Autonomy drafts the steps.
- Describe the flow — write what you want tested in plain language and let Autonomy draft the steps.
- Write the steps — compose them yourself.
Whichever you pick, you land in the step editor. Keep the case specific enough to verify the outcome, but avoid baking in implementation details that will change with the UI. For example:
- Create a new account with email OTP.
- Add the starter subscription to checkout.
- Confirm the receipt email arrives.
- Verify the account shows the paid entitlement.
Leave credential fields as agent-chosen values. Autonomy generates a high-entropy password at run time and reuses it for the rest of the run — hand-written example passwords are frequently rejected by real auth providers.
3. Run against a real target
Run the case against the same surface a user or reviewer would open: a preview deployment, staging app, local tunnel, or uploaded mobile build. Use the first run to confirm access, test data, and the expected end state before adding automation.
While the run executes you can watch it live in the evidence workspace.
4. Review the evidence
Open the run evidence and check the summary first. If the run failed, use the failing step, replay, screenshots, network details, inbox messages, and generated checks to decide whether the issue is product behavior, environment setup, or test data.
5. Automate the useful path
After one run is stable, connect it to pull requests or release checks:
- Install the GitHub App and comment
@autonomy test this PR against the preview— or set a repository default so a bare command runs your smoke case. - Group related cases into a test plan and run them together.
- Route failures to Slack or a webhook.
Keep the first automated case small. Add broader flows after the team trusts the evidence format and failure routing.