FAQ¶
Where does VibeTesting run?¶
VibeTesting runs in the AWS cloud using a cloud browser.
Does my app need to be public?¶
Yes — your app must be accessible over the public web for cloud execution.
Can I test any website?¶
No. You must own the application you test, or have explicit permission from the owner. VibeTesting is intended for legitimate testing of your own systems.
What test modes are available?¶
VibeTesting supports two execution types:
- Exploration — the agent freely explores your app within defined focus areas
- Guided — you provide Tests Guidelines (flow goals or step-by-step), and the agent stays on-path
See Running Tests for details on each mode.
What actions are supported today?¶
Supported:
- Click
- Right click
- Text input
- Page scroll
- Opening and using tabs and new windows during a run (as needed for navigation and your flows)
Coming soon:
- Drag and drop
- MCP support
How does exploratory testing work?¶
VibeTesting uses AI services to:
- Analyze the page and propose next actions
- Detect UI and functional issues (overlaps, broken links/pages, error states, broken flows)
- Locate the correct element to interact with at each step
Can I change the application URL?¶
Yes. Currently, VibeTesting supports one application at a time.
Which login options are supported?¶
- Credentials-based login inside your app
- SSO (single sign-on) is not supported currently
- CAPTCHA and similar bot challenges are not supported currently
Multi-session testing and browser tabs¶
Two logins in one test (multi-session)¶
When you ask for multiple users in a single test flow, VibeTesting can run up to two user-browser sessions at the same time — for example, two different accounts logged in so both can act in parallel. That helps with collaboration-style flows, buyer and seller scenarios, and similar cases. You cannot have more than two concurrent user-browser sessions in one run.
Tabs and new windows¶
During a run, the agent can use additional tabs and windows as needed. That is separate from the two-session limit above: there is no fixed cap on how many tabs or windows the agent may use for navigation and workflow.
Network and automation limits during runs¶
Browser automation applies per-run caps so the service stays stable. Typical defaults (exact values may vary by deployment):
- Request rate: about 200 requests per 10-second rolling window (a rolling window means the limit looks at the last 10 seconds, not a fixed clock interval)
- Total requests per run: about 4,000
- Distinct hosts: about 50 different hostnames contacted in one run
- Outbound data (size and speed): about 50 MB maximum for one HTTP response body; about 5 MB/s sustained download speed, with a burst of roughly 100 MB — burst means a short window where traffic can go faster before the sustained limit applies
Heavy traffic, very large downloads, or very high sustained speeds may be throttled or stopped early. Exploration-style runs are also capped on flows, steps per flow, and concurrency as described under What are the test run limits?.
If you need custom limits for your organization, email support@vibetesting.me. You can also see Contact for other ways to reach us.
What are the test run limits?¶
These are the main caps. The server may clamp higher requests or change limits over time, so treat this as guidance aligned with current product behavior.
- User-browser sessions per run: Up to 2 (two different logins at once in the same test). This is not a limit on tabs or windows — see Multi-session testing and browser tabs above.
- Flows per exploration-style request: Up to 50 distinct flows; larger numbers are clamped by the server.
- Steps per flow: Up to 100 steps (action budget per flow); a flow may finish sooner if the goal is met.
- Concurrent suite executions: Up to 10 suite executions at the same time per application. When you are at capacity, you may need to wait or stop a run before starting another.
- Parallel batches (explorations): Large explorations may be split into parallel batches of up to 5 flows per batch. The product may ask whether to run parallel batches (often faster) or a single batch.
- General run instructions: Up to about 1,000 words in a single message; longer text may be shortened on the server.
- App description / PRD in one message: Up to about 10,000 words; longer text may be clamped.
- Credits: Runs are credit-based. You need enough credits to start a run. See Pricing & Billing and your billing or account settings in the app.
For suites, parallel work is also described under Can I run tests in parallel? and Batched Execution. For network and automation caps (request rate, hosts, traffic), see Network and automation limits during runs. Custom limits may be available — contact support@vibetesting.me.
Is there an API?¶
Yes. The External API lets you trigger test executions (immediately or on a schedule), re-run suites, poll for status, stop running executions, and cancel scheduled runs — all authenticated via API keys. This enables integration with CI/CD pipelines and other external systems.
Can I see real-time logs during a test run?¶
Yes. Execution logs are streamed in real time while tests run. You can follow info and error entries as they happen, and the full log history is accessible after execution completes. See Real-Time Logs.
Can I schedule tests to run automatically?¶
Yes. You can schedule one-time or recurring test runs — daily or weekly — at any specific time. Tell the assistant when you want your tests to run (e.g., "Run my checkout tests every night at 2 AM"), or use the External API with the schedule_at, repeat (once, daily, weekly), repeat_count, and timezone parameters for CI/CD automation. Cancel any schedule at any time via the chat or the API. See Scheduling for details.
Can I run tests in parallel?¶
Yes. Tests within a suite are executed in batches of up to 5, in parallel across multiple workers — for example, 20 tests run as 4 parallel batches of 5. Large explorations may also be offered as parallel batches of up to 5 flows per batch versus a single batch; see What are the test run limits?. Details: Batched Execution.
What is PRD upload?¶
You can upload a Product Requirements Document (PRD) or describe your app in the chat. The platform processes it to generate an app summary, then proposes relevant test flows that can be executed as guided runs (with user-provided Tests Guidelines). The PRD is persisted and can be updated at any time. See PRD Upload & Test Generation.
What is the Inventory?¶
The Inventory provides a central view of all suite executions, suites, and individual tests — with execution status, timestamps, and result metrics.
Data & AI providers¶
VibeTesting uses managed AI services (including Azure OpenAI and Amazon Bedrock) to plan actions, locate UI elements, and detect issues.
- We send only the minimum information needed to run the test and generate results.
- Per common enterprise provider policies, customer prompts/outputs are not used to train foundation models and are not shared with other customers.
- Providers may apply limited retention/monitoring controls for abuse prevention and compliance.
Where do I see results and screenshots?¶
- You can view progress and outcomes in the agent chat.
- Follow execution in real time via real-time logs.
- Review execution history in the Inventory.
- If you enable email reporting, you'll receive a full report by email that includes screenshots.