Quickstart
Connect Jira or Linear and turn your QA handoff into an automated browser Test.
Move a ticket into QA. Smoketest turns it into a generated Test, runs it in a real browser, posts the Result to the ticket, and routes the ticket according to the outcome.
Prerequisites
- A Smoketest account
- A Smoketest project for the application under test
- Workspace-owner access in Smoketest to connect Jira or Linear
- A starting URL for a testable deployment
- Jira or Linear permissions to read tickets, comment, and move them directly from QA to your passed and development statuses
1. Connect Jira or Linear
Open Project Settings → Integrations, then choose Connect Linear or Connect Jira. Authorize the workspace or Jira Cloud site that owns your QA work.
- Linear comments and status changes are attributed to the Smoketest app.
- Jira comments and status changes use the connected Jira account and its permissions.
A Connection stores authorization and tenant health. It does not decide which tickets get tested.
2. Create a Test Source
Open Board → Sources and choose New Test Source. A Test Source defines one QA handoff for one Smoketest project.
Configure:
- The Jira or Linear Connection.
- The Linear team and optional project, or the Jira board.
- The exact QA/testing status. For Jira, choose the familiar QA column first; if it contains multiple statuses, choose the exact one Smoketest should listen to.
- The directly reachable passed and development statuses.
- The starting URL, Environment or saved login session, device, and any optional inbound-email or HTTP-auth settings.
Choose Validate and review. Smoketest checks Connection health, read/comment permissions, direct transitions, execution settings, and whether another active Test Source could own the same ticket.
3. Activate safely
Activation shows how many tickets are already in QA.
- Leave Include all existing eligible tickets off to listen only for new arrivals.
- Turn it on to queue every currently eligible ticket. There is no artificial batch cap, but each Test uses a credit and a Test Source processes one Attempt at a time.
After activation, move a controlled ticket into the exact QA status. It appears in the Testing column on the Board automatically.
4. Follow the Test Request
Smoketest re-fetches the latest ticket when work starts, freezes the current context, and optionally adds code context only from a pull request linked from the ticket and connected to the same Smoketest project.
It then creates one immutable generated Test for the Attempt and runs it. The Test Request detail shows preparation, live browser progress, evidence, the Result, and ticket sync.
| Result | Ticket behavior |
|---|---|
| Passed | Update the Attempt comment with evidence, then move to the configured passed status |
| Failed | Update the Attempt comment with evidence, then return to the configured development status |
| No Result | Explain what prevented a reliable Result and leave the ticket in QA |
A human status change wins. If someone moves the ticket out of QA while testing is active, Smoketest cancels the Attempt and does not route it afterward.
5. Handle another QA cycle
When the ticket enters QA again, its existing Test Request gets a new Attempt and keeps the previous history. While it remains in QA, an Owner, Admin, or assigned Tester can also start a new Attempt and add supplemental context.
Pausing a Test Source stops listening completely. Reactivating it performs a fresh scan and queues the currently eligible QA tickets.
Reusable Tests are the secondary path
Use Test Library → Tests when you need an editable Test that runs on demand, on a schedule, through the API/CLI/MCP, from GitHub, or from a deployment webhook. Ticket-generated Tests remain immutable and outside that library unless you explicitly choose Save as reusable Test.