Issue-driven testing

Jira or Linear remains the system of record for issue workflow. Smoketest owns testing execution, evidence, and synchronization history.

The lifecycle

1. A Connection authorizes one Jira Cloud site or Linear workspace.
2. A project Test Source selects the team or board, exact QA entry status, optional Passed and Rejected destinations, and browser settings.
3. A ticket entering QA creates or reopens one durable Test Request.
4. Each QA cycle or authorized retry creates an Attempt.
5. The Attempt freezes current context and owns one immutable generated Test.
6. One or more Runs may execute that Test. A classified infrastructure retry can create one extra Run without spending another credit.
7. The final Result is Passed, Failed, or No Result.
8. Ticket sync updates the Attempt comment and, when safe, moves the ticket.

Either outcome destination can be left unset. Tests and result comments still run, but Smoketest does not move the ticket for that outcome. Leave both unset to test in QA without changing provider statuses. Existing mappings keep working until you edit them.

The Result and ticket sync are separate. A Passed or Failed Result stays true even if a comment or transition needs attention and must be retried.

Board and execution ownership

Only one active Test Source can own a ticket within a workspace. Each Test Source processes one Attempt at a time in QA-entry order.

The read-only Smoketest Board shows Rejected, Testing, and Passed. Tickets appear after entering the Smoketest queue through a configured QA status or a manual Attempt. The latest Attempt determines the column: queued, preparing, or running is Testing; a completed pass is Passed; failed, No Result, or cancelled work is Rejected with its specific outcome label. A new Attempt returns the ticket to Testing. Provider status changes or delayed ticket sync do not change the recorded outcome. Jira or Linear remains authoritative for the displayed status, assignee, priority, and ordering. Cards open their Test Request and retain a link to the provider.

The default All active scope combines active Sprints or Cycles and includes recorded Test Requests for Kanban Sources, retaining tested tickets even after they move outside the configured Jira or Linear statuses. Manual Attempts also appear in the default view, even outside current Sprints or Cycles. Current, previous, and historical iteration selections, date ranges, and Board filters stay in the URL.

Queued work consumes no credit and creates no ticket comment. When credits return, Smoketest revalidates the ticket, Connection, and Test Source before resuming automatically.

Start a manual Attempt

Choose Manual attempt in the Board header to test a ticket without moving it into QA.

1. Select a Jira or Linear Connection and search by ticket key or text. Search includes any board, team, or status available through that Connection.
2. Choose the ticket, then set the starting URL, Environment, and device. Optionally enable inbound email, HTTP authentication, or add testing context.
3. Select Start Attempt. The ticket appears in Testing and uses the normal Attempt pipeline and testing credits.

Smoketest posts the result on the ticket and leaves its Jira or Linear status unchanged. Manual Attempts use the settings you choose in the modal. If the ticket already has an active Attempt, Smoketest keeps that Attempt and shows a link to it. Its previous Attempt history is preserved.

This action is available to Owners, Admins, and Testers with access to all sources in the project. A ticket already assigned to another Smoketest project must be tested in that project.

Context and code

The frozen context can include bounded ticket text, recent human comments, captured ticket-file metadata and bounded supported image previews, execution settings, and supplemental context supplied for a manual new Attempt.

Code enrichment happens only when the ticket links to a pull request whose repository is connected to the same Smoketest project. Missing code access is recorded but does not block testing.

Safety

• Exact Jira or Linear status IDs decide automatic eligibility; manual Attempts can start from any status.
• Automatic Passed and Failed transitions must be directly reachable from QA. Manual Attempts never request a transition.
• No Result does not move the ticket.
• A newer human status change overrides automation.
• One Attempt uses one evolving ticket comment rather than posting progress spam.
• Evidence links require authenticated Smoketest access.
• Paused Test Sources do not listen; reactivation scans the current QA status again.

Generated Tests never activate reusable-Test schedules, GitHub triggers, deployment webhooks, or result-follow-up automations. Saving one as reusable creates an independent editable copy.

Attempt flow and files

Each step shows its recorded status and outcome. Expand it for inputs, outputs, origins, warnings and retries. The flow separates Persona selection, file preparation and saved-sign-in readiness. Historical milestones without saved evidence show History unavailable. A completed step may produce a Failed or No Result outcome.

After ticket enrichment, Analyze linked PRs uses explicit PR links from the ticket and eligible human comments to inspect connected GitHub changes. Expand the step for cited testing insights, captured revisions and any limits or skipped PRs. Optional code enrichment failures do not block testing; the step explains when it continues with ticket context. GitHub setup and permissions.

Smoketest captures direct ticket attachments and provider-hosted files in descriptions and eligible human comments. Its own reports and ordinary external links are excluded. Limits are 50 files and 100 MiB per Attempt, with 25 MiB per file. Missing permissions, inaccessible files and limit exclusions remain visible. Required unavailable files produce No Result, never a product failure.

After selecting the Persona, Smoketest freezes the selected Environment files, Persona files and captured ticket files. Preparation resumes and automatic Run retries use these versions. The New Attempt action captures current inputs. Retry with saved snapshot, beside a completed Attempt's Result reason, creates a separate Attempt using its saved ticket, PR content, Persona and file versions. It redoes analysis and test generation without fetching newer ticket or PR data, even if the ticket has moved out of QA. Normal Run charges apply, and the browser tests the current application with current variables and saved sign-ins. Saved file contents must still be available; if they have expired, create a New Attempt instead. Attempt history identifies which saved snapshot was reused. File details distinguish availability, scenario references, model metadata handoffs, inspection and upload activity, with links to the corresponding Run.

Ticket copies do not count toward managed-file storage. They remain for 30 days after the Attempt completes or is cancelled, longer while unfinished work references them. Metadata and recorded evidence remain afterward; previews and downloads then show File contents no longer available. Project and Test Source visibility apply even when no Run starts.

A reusable fork does not inherit ticket-file access. Replace any retained ticket references with managed Environment or Persona file references before running it.