Automated QA testing in a real browser
In shortAfter a big change, MonstarX offers a QA plan. Click Run QA and its QA agent reads your code, then tests up to 24 key journeys (sign up, book, pay…) in real cloud browsers, each with a fresh test account and a real inbox. You get a report in the chat with a recording of every test, and a diagnosis of anything that fails. With Report only you choose what to fix; with Auto fix MonstarX fixes and retests by itself. QA uses credits and never starts without you.
QA (quality assurance) means checking that an app really works: that a visitor can sign up, book a slot, pay, get the email and see what they should. Doing that by hand after every change takes hours.
MonstarX has a QA agent that does it for you. It reads your app’s code to see what was built, then clicks through your app in real web browsers in the cloud, like a careful tester would. You get a clear report in the chat, a video of every test, and help fixing what fails.
How is QA different from the build checks?
Section titled “How is QA different from the build checks?”Every build ends with Automatic build checks. They run by themselves and protect the preview: the code has to work before a build is done. See Follow a build.
Browser QA goes further: it uses the app like a person would, journey by journey, and checks that each one does what you asked for. It takes a few minutes and uses credits, so it always asks first.
When does QA run?
Section titled “When does QA run?”QA never starts a paid run on its own. It suggests one, and you decide.
After the first build and after bigger changes, a card appears in the chat: QA plan ready. It says what MonstarX will check. Click Run QA to start, or Later to skip it. You can always run QA later from QA in the top bar.
The card’s plan, What MonstarX will check, tells you:
- Focus areas: the parts of your app the change touched.
- In the browser: up to 24 key journeys, checked in small batches.
- What you’ll get: a clear report of what works, what needs attention, and what could not be checked.
- If QA finds problems: whether it will only report them or also fix them (see below), and that QA uses credits.
If the app changes after the plan was made, Run QA asks for a fresh plan, so QA always tests the code you have now.
How do I choose when QA is suggested?
Section titled “How do I choose when QA is suggested?”Click QA in the top bar (under When to suggest browser QA), or open SettingsGeneralBrowser QA (under When to suggest QA). Pick one:
| Setting | What happens |
|---|---|
| After substantial changes (the default) | A plan appears after larger changes, and waits for your choice. |
| On request | No suggestions. A plan is shown only when you open QA. |
| After every build | A plan appears after every change to the app. |
What does QA do while it runs?
Section titled “What does QA do while it runs?”-
Code review. The QA agent reads your app’s code and compares it with what you asked for and with your feature plan. It sorts every feature into built, partly built or not built yet, and notes anything claimed as done but unfinished. The card shows this as Code review 5 built · 1 partly built.
-
Test plan. It writes up to 24 short browser tests that follow the real buttons and pages in your code: sign up, book a 30-minute walk, cancel it.
-
Browsers. Each test runs in its own cloud browser, several at once. The card says Testing 6 flows at once… 2 of 6 done. Click Watch live to watch a test while it runs. When the card is taller than the chat, its headline and what it is doing now stay pinned at the bottom of the chat as you scroll.
-
Results. Each test is ticked off as it finishes, with how long it took and a Replay button for its recording.
A few things make the tests realistic:
- Every test signs up with its own fresh test account, so tests never trip over each other’s data.
- Test accounts have real inboxes. When your app sends an email, such as a sign-up confirmation or a password reset, the tester opens it and follows its link, just like a customer.
- QA tests its own copy of your app. You can keep using your preview while it works. If you start a build, QA stops and, once the build is done, offers to test the finished app instead.
- Test accounts are removed afterwards, together with what they made, so your app’s data stays clean.
How do I read the results?
Section titled “How do I read the results?”The QA card in the chat sums up the run in its headline, for example All 7 tests passed or 5 of 7 tests pass.
Under the headline you see:
- Each test, with a tick or a cross, the time it took, and a Replay of its recording. The first failure’s replay opens by itself.
- For a failed test: the step that went wrong (At “Book a walk”) and what the page showed, word for word.
- Not tested: a test that could not finish (for example, the browser stopped making progress) says why. A run is never called a pass when a test could not run.
- Needs keys: a journey that reaches a service you have not connected yet (like Stripe) is tested up to that step and marked with a key icon, needs Stripe keys and a Connect Stripe link. It does not count as a failure. See Connectors.
- Feature plan: 4 of 5 tested features work: how the results map onto your plan.
In the feature plan, features get a badge: Verified (checked in a real browser), QA failed or Needs keys.
What happens when a test fails?
Section titled “What happens when a test fails?”QA works out why. It traces the failing journey through your code, logs and data, and lists the problems under What is wrong, each with a label:
| Label | Meaning |
|---|---|
| Bug | The app does something wrong. |
| Not built | The feature is not there yet. |
| Test issue | The app works; the test itself was wrong. QA corrects the test and tries again. |
| Preview issue | The preview was down or slow. QA restarts it and tests again. |
| Needs you | Something only a person can check: real payments, an inbox that is not the test’s own, a third-party sign-in, a CAPTCHA. |
Each problem also says how sure QA is (Confirmed, Likely or Unclear), the cause, and the fix. Open Technical details for the evidence.
Report only or Auto fix?
Section titled “Report only or Auto fix?”You choose what QA does next under When QA finds a problem, in the QA menu or SettingsGeneralBrowser QA:
- Report only (recommended). QA shows its findings and asks before each fix. The card offers Fix this problem (or Fix these 3 problems), Test again for a test or preview issue, or Later. Nothing changes in your app until you click.
- Auto fix. QA sends the diagnosed problems to the builder, checks the change, and tests again by itself. This uses more credits.
A fix works like any build request: it appears in the chat as QA · fix attempt 1 of 3, keeps a version you can go back to, and then QA checks each problem (Fixed, Partly fixed or Not fixed) and runs the same tests again.
After three fix attempts, or when what is left needs a person, the card says Please check these yourself and gives you a checklist: the steps, what should happen, what automated testing saw and the suspected cause. Try one more fix gives the builder one more go.
What is the wrap-up card?
Section titled “What is the wrap-up card?”When everything in your feature plan is built, the chat shows a wrap-up card. Its headline tells you where you are:
- Everything is built and tested: every feature is built and QA passed.
- Everything on the plan is built, with QA hasn’t tested this version in a real browser yet: QA has not run on this version. Click Review QA plan, then Run QA.
- Everything on the plan is built — 1 problem still open: QA finished with something left. The Still open section offers Try one more fix, or asks you to describe what you see.
Under Ideas for what’s next, MonstarX suggests three to five features that fit your app. Click Add (or Add all) to put them in your feature plan, then Build it or Build them.
How do I stop or restart QA?
Section titled “How do I stop or restart QA?”- Cancel on the QA card stops a run at once, keeping what it found. A fix that had not started yet never starts.
- Run QA now in the QA menu starts a new run.
- The QA menu also shows how the last run went.
Only the project’s owner can start QA. People you share the project with see the QA cards, without the buttons.
Frequently asked questions
Section titled “Frequently asked questions”Does QA run by itself and spend my credits?
No. QA only suggests a plan and waits for you to click Run QA. With Auto fix switched on, a run you started can go on to fix and retest by itself, which uses more credits.
How many journeys does QA test?
Up to 24 per run, in small batches of cloud browsers running side by side. For a larger app, another run can check more of the remaining areas.
Can QA test emails my app sends?
Yes. Each test account has a real inbox, so QA can open a confirmation or password-reset email and follow its link. Only an inbox that is not the test's own is left for you to check.
Can QA test payments or Google sign-in?
Not end to end. A journey that reaches a service you have not connected is marked Needs keys. Real payments, third-party sign-ins and CAPTCHAs are listed under Needs you for a person to check.
Can I keep building while QA runs?
You can keep using your preview, because QA tests its own copy of your app. If you start a build, QA stops its run. When the build is done, it offers to test the finished app, and you choose Run QA or Later.
Will QA leave test accounts in my app?
No. Once a run is over, its test accounts are removed together with what they created.