From Bug0
Move managed AI QA goals into self-serve Smoketest tests.
Bug0-style coverage is often already described as goals or generated browser tests. That makes migration mostly about ownership: decide which goals you want to run yourself, then recreate them as Smoketest tests you can edit, schedule, and trigger from your own project.
If you have generated Playwright tests, use the Playwright migration guide. If you only have a test list or QA reports, start from that inventory.
Translate the concepts
| Bug0-style coverage | Smoketest |
|---|---|
| Test goal or QA checklist item | One test |
| Generated Playwright test | Test steps written in words |
| Smart selector or generated locator | Not needed in the test text |
| PR check | GitHub trigger or deployment webhook |
| Slack failure report | Slack, Discord, or email notification |
| Scheduled regression set | Preset schedules or triggered runs |
| Managed triage | Run history, screenshots, recording, and team review |
What to migrate
Migrate goals that represent durable product behavior: account creation, login, checkout, payment plan changes, project setup, admin workflows, and the highest-value regression checks.
Skip goals that depend on a human QA analyst making subjective calls unless you can rewrite them as a clear observable outcome.
Build an inventory
Create a local file if the coverage does not live in your repo:
# bug0-migration.md
## New user can create first project
Start URL: https://staging.example.com/signup
Expected outcome: the user lands in the dashboard with a created project.
Notes: uses a disposable test email and a staging workspace.Quick migration prompt
Use $smoketest-explore to migrate the Bug0-style QA goals in this repo to Smoketest.
1. Check Smoketest CLI install and auth first.
2. Read generated Playwright specs, goal documents, QA reports, or files such as bug0-migration.md.
3. Convert each durable browser goal into one .smoketest/explore test draft.
4. Express the user's actions and expected outcome in words.
5. Use Smoketest environments for credentials and staging values.
6. Skip vague goals that do not have an observable browser outcome.
7. Validate and dry-run the manifest, then ask before applying.Example test
## Create first project
- Open the signup page.
- Sign up with the test user.
- Create a project with the staging URL.
- Verify the dashboard shows the new project and the empty tests state.After migration
- Run the migrated tests manually first.
- Use recordings and step logs to triage failures directly.
- Add GitHub triggers or deployment webhooks for the release checks that previously ran outside your control.