Get started with TestVibe

Create your first project, write a useful test, run it, and inspect the result.

What TestVibe does

TestVibe keeps your test descriptions, executable tests, run history and evidence together in a project.
Write a task in plain language, record browser steps, import a document, or work with existing test files. A first test can run with AI; generating Playwright code is a separate option.
Your on-prem runners and browser services must reach the application under test. AI features use the model providers configured by your administrator.

Open your organization’s TestVibe address and sign in with your local account or configured identity provider. Ask your administrator for an invitation if signup is unavailable.
On an unclaimed installation, the first signup creates the instance administrator without email verification and opens Settings → Administration. Complete that checklist first. Later signups follow the installation’s registration policy.
Choose Add your app. The first-project dialog asks “What app would you like to test?” Enter the App URL that the runners can reach.
TestVibe suggests a project name from the address. Expand Project details if you want to change it, then choose Continue. When adding another project, the action is Create project.
Follow the first-test flow to check application access. Choose No sign-in needed, Use a test account, or saved sign-in steps where available. Test-account credentials are stored as project secrets; verify sign-in before continuing.
The sidebar uses Tests for test files, Runs for execution history, Analytics for summaries, Application for application context, and Settings for project and workspace configuration.

In the first-test flow, describe one task and its expected result, then choose Create and run test. You can also choose Record steps or Import document.
For more tests, open Tests → New test. Markdown tests let you write steps and expected results in plain language; Gherkin uses Given, When and Then.
Be specific about the starting state, test data, actions and visible result. Keep passwords in project secrets rather than in the test description.
For example: “Sign in with the test account, create a customer named Alex, and check that Alex appears in the customer list.” This is more useful than “Test customers.”
Review and save the test before reusing it in an automation. If a run could not start, open the saved test or retry it instead of creating a duplicate.

You can run an editable plain-language test with AI or generate Playwright code for repeatable execution. Choose the path that fits your test.
Generation uses the selected provider, model, application context and project settings. Ask an instance administrator to configure Model providers if no suitable model is available.
Follow the progress shown with the test. Answer any request for missing information and review the resulting changes before relying on them.
Keep the application URL, test account and relevant project notes current. A model must support the tools required by the chosen workflow; a reachable endpoint alone is not enough.
Generated code is a draft to verify. Run it, inspect the evidence and improve the test when its assertions do not capture the intended behavior.

Open a saved test or select tests in the list and choose Run. Review the target environment and available browser or Playwright configuration before starting.
Watch Runs for queued, active and completed work. AI runs show activity while the model and browser are working.
If a run cannot start, read the displayed reason. Check runner availability, application access, required configuration, model credentials and license status as appropriate.
Cancel work you no longer need and wait for its terminal status. Regeneration actions become available after active test runs finish.

Open the run and select the relevant test or step. Review its status, expected result and failure message before changing anything.
Use the available screenshots, video, network and console evidence to understand what the browser actually did. Open the Playwright trace when the run provides one.
Check whether the application failed, the test expected the wrong behavior, or the environment could not be reached. Authentication failures and missing test data often explain an otherwise unclear result.
If artifact links fail while the run itself succeeded, ask your administrator to check the public Artifact URL and reverse-proxy configuration.
Share the run through TestVibe’s sharing action so your teammate receives the relevant context.

Correct the application when the evidence shows a product defect. Update the test when its instructions, assertions or data no longer describe the intended behavior.
Use the editor’s assistance or the available run actions to investigate a failure. Review proposed changes before saving or applying them.
Run the affected test again against the intended environment and compare its evidence with the previous run. A changed test should still check the original requirement.
Keep useful application behavior and testing constraints in project notes so future work has the same context.

Organize related tests into folders and use Automations when you are ready to schedule work or connect repository events.
Configure environments, variables and secrets in Settings. Use Application and repository integration features when the assistant needs application context.
Create an API key under Settings → CLI & API keys for your terminal or CI. Copy it when shown, store it securely, and follow the connection instructions displayed there.
Instance administrators manage installation-wide email, identity providers, capacity, model providers and licensing under Settings → Administration.
For installation problems, use the troubleshooting guide; for model setup, use AI providers and models.