Know your shop works, in every browser
Forge QA clicks through your website the way a customer does: open a product, add it to the cart, go to checkout. It does this in every major browser, on a schedule you choose, and shows you proof the moment something breaks.
Tested in every browser your customers use
A checkout that works in Chrome can still break in Firefox or on an iPhone. Forge QA runs the same test in all of them, so you find out before your customers do. All five browsers are included on every plan.
- Google Chrome and Microsoft Edge: the browsers most of your visitors use.
- Firefox: Mozilla's own engine, with its own layout quirks.
- Chromium: the open-source core of Chrome and Edge.
- Safari (WebKit): the engine inside Safari. It catches most Safari issues, but it is not Apple's Safari app on a Mac or iPhone.
- Phone and tablet layouts: set custom screen sizes and user agents.
- Pick any mix per test, suite or schedule. Each browser counts as one run.
- Google Chrome1440 × 900Passed
- Microsoft Edge1440 × 900Passed
- Firefox1440 × 900Passed
- Chromium1440 × 900Passed
- Safari (WebKit)390 × 844 phonePassed
When something breaks, you see exactly what happened
No guessing from a red cross. Every run keeps a screenshot after each step, a video, and the browser's own logs, so whoever fixes it starts with the cause. Share a PDF report with your team or client.
- Screenshot after every step and a video of the whole run.
- Browser logs: readable console and network logs, plus a Playwright trace for developers.
- Visual comparison: approve a baseline screenshot per test and browser. Later runs are compared with a difference threshold you set, and you get a diff image.
- PDF reports to share with your team or clients.
- Kept 7 to 60 days: 7 days in the trial, 14 on Starter, 30 on Professional, 60 on Agency. Then screenshots, video, trace and logs are deleted. Run history stays: status, steps, errors, durations and security findings. Download what you need before then.
Visual comparison and PDF reports: Professional and Agency.
- document
- theme.css
- theme.js
- POST /cart/add
- cart.svg
Site changes don't break your tests. Real bugs still do.
You update the theme and a button gets a new name. Instead of failing, the test finds the button another way, keeps going and flags the step so you can update it with one click. If the button is really gone or the cart stays empty, the test still fails, with proof.
- During the run, Forge QA first tries the step's backup ways of finding the element. If none match, AI picks the matching element on the live page.
- Healed steps are flagged in the run report, with one click to apply the fix to the test.
- Switch off AI healing for a whole test or a single step when you want a hard failure instead.
- 1Open the product page
- 2Pick size M
- 3Add to cart
- #add-to-cart · not found
- [data-test="add"] · not found
- Found button "Add to bag"
- 4Cart shows 1 item
Step 3 found its button another way.
Apply fixA security check on every run, included
While a test clicks through your shop, Forge QA also watches what the page loads and does: a script that sends card details to another site, a redirect away from your shop, a new third-party script since yesterday. Results get their own Security tab, next to the test results. It never fails your test and costs nothing extra.
- Visitors sent to another website, as happens on hijacked shops
- Scripts that read card fields, and forms that send passwords or card data to another site
- Hidden code, crypto miners and invisible frames from other sites
- Every script on the page, checked on every run and compared with the last run
- A second opinion from AI when a new third-party script appears
- MediumNew third-party script since the last run, flagged by the AI reviewcdn.chat-widget.example/loader.js
- OKNo redirects away from your shop
- OKNo card or password data sent to other sites
Checked 23 scripts (9 third-party) · the test still passed
See it in use
Two typical setups, step by step, the way they look in the test editor.
Online shop: know checkout works, every day
The test opens a product, picks a size, adds it to the cart, checks the cart count and total, and goes to checkout. It stops before payment, so no order is placed. It runs in all five browsers every night, and again after each release.
- When it fails: the run shows which step broke in which browser, with the screenshot, video and logs. On Professional and Agency you also get a Slack message or email.
- After each release: your deploy starts the test through a CI trigger (Professional and Agency).
- Theme update moved a button? Self-healing keeps the test running and flags the step.
- 1Open the product pageNavigate to URL /products/linen-overshirt
- 2Close the cookie bannerDismiss known popups
- 3Pick size MClick an element .size-chip >> "M"
- 4Add to cartClick an element button#add-to-cart
- 5Cart shows 1 itemExpect text #cart-count "1"
- 6Open the cartClick an element a[href="/cart"]
- 7Total is €68.00Expect text .cart-total "€68.00"
- 8Go to checkoutClick an element button[name="checkout"]
- 9Checkout page opensExpect URL /checkout
- Stops here, before payment.
- browsersChromium, Chrome, Edge, Firefox, Safari (WebKit)
- scheduleevery night at 02:00 UTC
- also runsafter each release
- on failureSlack and email
Agency: every client's shop checked after every update
Add each client's shop as a website and give each client its own suite. After a theme or app update, run that client's suite in every browser and send them the PDF report as proof the shop still works.
- 10 websites on Agency, each a root domain. Add up to 40 more at €9 a month each.
- A CI key per client: a trigger key can run only its own suite, so the key in one client's pipeline can't run another client's tests.
- A PDF report of each suite run, ready to send.
- Unlimited seats: invite your whole team. Everyone in a workspace sees all its websites and tests, so a client who wants their own login gets their own workspace, on its own plan. Workspaces keep websites, tests and billing apart.
- alpine-outdoor.exampleSuite: checkout + searchPassedPDF
- bakery-berlin.exampleSuite: order a cakeFailedPDF
- coastal-tea.exampleSuite: subscribe + checkoutPassedPDF
- CI keyruns only "bakery-berlin · order a cake"can't run other suites
- failedstep 4 in Safari (WebKit) · screenshot, video, logs
Create tests without writing code
Click through your shop once, or describe what to check in plain words.
Click through your shop once. That's the test.
Open the recorder and a real browser streams into the app. Click, scroll with the mouse wheel, type, press keys and paste. Product pages, size pickers, popups and cart drawers behave as they do for your visitors, and each action becomes a step with editable selectors.
- Nothing to install. The browser runs on our servers.
- Suggestions as you record, optional. The AI Buddy watches the steps you record and the live page, and suggests checks and sturdier steps as you go.
- Recorder time counts toward your plan's recorder minutes.
- 1open /overshirt
- 2click .size-chip >> "M"
- 3click button#add-to-cart
- 4expect #cart-count "1"
SuggestionCheck that the cart count is 1?
Describe a flow in plain words, get the steps
Write what the test should do, like "submit the contact form and check the thank-you message". AI drafts the steps against your real page. To change a test, ask in plain words. Every field that changed is highlighted in the editor, so you review exactly what moved before you save.
- One monthly allowance of AI actions covers writing, review, self-healing, recording suggestions and the assistant: 150 on Starter, 600 on Professional, 2,000 on Agency, 25 in the trial.
- On Agency, bring your own OpenRouter key and choose the model.
DescribeSubmit the contact form with a test address and check the thank-you message.
- open /contact
- fill #name "Test Person"
- fill #email "${TEST_SECRET_EMAIL}"
- check #newsletter
- click button[type=submit]
- expect "Thanks, we'll be in touch"
RefineAlso tick the newsletter box.
New recordings get hardened before you rely on them
When you finish a recording, it is replayed in a real browser and every element the test touches is inspected. Backup ways to find each element and better timeouts are added, so the test holds up in other browsers. Every change is highlighted, and you can undo it before you save.
- It never adds, removes or reorders steps.
- It never changes a value you typed.
- Nothing is saved until you save the test.
- In the app this is the ForgeAI review: it inspects the DOM around each target, adds fallback selectors, and shows a progress screen while it works.
Replayed 4 of 4 steps · inspected 3 targets
- step 2 selector.size-chip >> "M"
- + fallbackbutton[aria-label="Size M"]
- + fallback[data-size="m"]
- step 3 timeout5 s → 10 s
Steps, order and values unchanged.
Your tests run on their own. You see how they're doing.
Keep every test in one library, group them into suites, and let schedules do the clicking.
Organise, schedule and keep track
- Test library: every test in one place, searchable by name, description or URL.
- Suites: chain tests (log in, add to cart, check out) and they run in order in each browser. When later tests depend on earlier ones, let the suite stop at the first failure: the remaining tests for that browser are skipped.
- Schedules: run a test or suite as often as every minute, or once a night.
- Run history and pass rate: every run with its result, and your pass rate and failed runs at a glance.
Schedules use cron expressions in UTC, for example */15 * * * * for every 15 minutes.
18Tests in your library
97%Pass rate
1Failed runs
SuiteCheckout journey
- scheduleevery hour
- browsersChromium, Chrome, Edge, Firefox, Safari (WebKit)
- orderlog in → add to cart → checkout
- on failureskip the remaining tests
For the technical team
Fine control over every step, and runs started from your deploy pipeline.
Control every step, and how a test starts
Each step has its own timeout, failure mode, scrolling, AI assist and popup handling. Test setup puts the browser in the state you need before the first page loads.
- If a step fails: stop the test, mark it failed and keep going, or ignore the failure.
- Cookie banners can be dismissed once, after the first page load, instead of before every step, so your own popups and cart drawers stay open when the test needs them.
- Test setup: query parameters, request headers, cookies, localStorage and sessionStorage.
- Request headers go only to your site's own origin, never to third parties.
- Secrets like
${TEST_SECRET_PASSWORD}are stored encrypted and masked in screenshots and logs.
Step 4click button#checkout
- Timeout
- 10 s
- If it fails
- StopFail, continueIgnore
- Scroll into view
- AI assist
- Dismiss popups first
Test setup
- query?preview_theme=1042
- headerX-Test-Run: 1site origin only
- cookiecookie_consent=accepted
- localStoragenewsletter_popup=closed
- sessionStorageab_variant=b
- secret${TEST_SECRET_PASSWORD}masked as ••••••
Run tests from every deploy, with keys that can't do anything else
Create a CI trigger for a test or suite and you get a key that can run only that target and read its results. It is not an account API key, so a leaked CI secret can't touch anything else.
- Examples for GitHub Actions, GitLab CI, Jenkins, CircleCI and Bitbucket Pipelines, and curl for any other CI. The GitHub Action waits for the result.
- An idempotency key per deployment stops duplicate runs.
- Results go to Slack, signed outgoing webhooks and Jira Cloud issues. Scheduled runs can also send an email when they fail.
CI triggers, Slack and failure email: Professional and Agency. Signed webhooks and Jira Cloud: Agency.
For developers: trigger a run with curl
# Run the checkout suite after each deploy curl --fail-with-body -X POST \ 'https://app.forgeqa.io/api/triggers/<trigger-id>/run' \ -H "X-Webhook-Key: $FORGE_WEBHOOK_KEY" \ -H "Idempotency-Key: deploy-$GIT_SHA"
CI triggerCheckout journey
- targetsuite · Checkout journey
- key canrun this suite, read its resultsnothing else
- duplicatesone run per Idempotency-Key
- results toSlack · signed webhook · Jira Cloud
Every run in its own sealed box
Your tests run against real websites, so we keep each run isolated by default.
- Every run starts in its own disposable container.
- A per-run network guard lets the browser reach only the websites you approved. Private network addresses are blocked.
- Approved dependencies per website: allow only the third-party origins you list, or any public HTTPS origin for page resources.
- Passwords and secrets are masked in screenshots and logs.
- Runs leave from shared runner IP addresses you can allowlist. Agency can request a dedicated outbound IP.
Ask the app, and it does the work
The chat bubble in the app answers questions about Forge QA: setup, billing and features. It keeps its history as you move between pages and holds several threads. It can also do the work: add a website, write a test and run it on all browsers, or run a suite. Each time, it asks you to confirm first.
Write a checkout test for shop.example and run it on all browsers.
- Write a test: product page, add to cart, open checkout
- Run it on Chromium, Chrome, Edge, Firefox and Safari (WebKit) (5 runs)
Your whole team, at no extra cost
Invite everyone who should see a failing checkout. Seats are free.
- Unlimited seats on every plan.
- Workspaces keep each team's websites, tests and billing apart.
- Support chat with our team on Professional and Agency. Agency adds priority onboarding and test assistance.
- Give support temporary access to the tests you choose, for 1, 4 or 24 hours. Their edits stay drafts until you approve them.
- How to reach support
See your own site in five browsers.
100 test runs, all five browsers, no credit card.