A Selenium alternative that monitors your tests without a grid to keep alive.
Selenium gives you a WebDriver and a grid to run at scale, plus a lot to wire up yourself. Smoketest re-runs your tests in a real browser from one sentence and tells you the moment one breaks.
No WebDriver. No grid. Your first run in about two minutes.
Selenium is powerful. The upkeep is the problem.
Selenium is the standard for scripted browser control, but you own everything around it: the grid, the waits, the selectors, the CI.
A grid to run at scale
Cross-machine and parallel runs need Selenium Grid or a paid cloud grid, one more platform to operate and pay for.
No built-in waiting
Without auto-waiting you hand-code waits, and timing issues turn into failures that aren't real bugs.
Selectors you maintain
XPath and CSS locators break when the markup moves, and keeping them current is your job.
A platform to own
You run the tests, the grid, and the CI around them. There's an execution platform to keep healthy, not just tests.
No selectors. No test file.
Start on the login page. Log in with the test account. Open the billing page. Confirm the current plan shows as Pro.
Selenium vs Smoketest, at a glance.
Selenium or Smoketest?
Stay on Selenium if you
Cover the tests that matter.
Login
Checkout
Onboarding
Billing
Magic link
PR previews
The whole story, not just a red X.
Every failed run hands you a recording, a transcript, the result, and the downloadable Playwright trace.
Jira or Linear starts the Test.
Keep the workflow where QA already works. Smoketest adds execution, evidence, and routing without becoming another board.
Connect Jira or Linear
A workspace owner authorizes Jira or Linear once. Smoketest keeps Connection identity, permissions, token health, and webhook health visible.
Define the QA handoff
Choose the team or board, exact QA status, direct Passed and Development statuses, then set the URL, Environment, device, and access settings.
Let the ticket start testing
When a ticket enters QA, Smoketest freezes current context, enriches it from an eligible ticket-linked pull request, generates one Test, and runs it automatically.
Return the Result safely
Smoketest posts evidence to one evolving Attempt comment. Passed moves forward, Failed returns to Development, and No Result stays in QA. Newer human changes always win.
Selenium teams ask these.
No. Smoketest runs tests in a real browser through a managed agent and saves a Playwright trace with every run. There is no WebDriver to install and no grid to host.
No. You describe the test in a sentence or two and add test logins as environment variables. The agent handles waiting and reads the page itself, so there are no selectors or waits to keep alive.
Yes. Every run saves a recording, a step-by-step transcript, and a downloadable Playwright trace, so you can see exactly what happened.
Smoketest runs your tests in a real Chromium browser in the cloud. If you need to certify a wide matrix of browsers and operating systems, Selenium with a grid is still the better fit.
Most teams have their first test running in a couple of minutes: paste the URL, write the steps, run it once, then schedule it.
Move one test off Selenium.
Pick a critical journey, describe it in a sentence, and run it in a real browser. No WebDriver, no grid, no waits to hand-code.
Read the docs