> For the complete documentation index, see [llms.txt](https://docs.testvibe.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.testvibe.com/readme/who-testvibe-is-for.md). # Who TestVibe Is For TestVibe is for teams that care about browser-based quality, but do not want the whole testing process to depend on one person hand-writing and debugging every Playwright file. It works best when product knowledge, test intent, and engineering ownership all need to meet in one place. QA can describe what should be tested, product can clarify expected behavior, developers can review generated code when needed, and everyone can look at the same run evidence when a test fails. ## The Main Audiences
QA and test teamsCreate structured test coverage, generate browser tests, run suites, and review failures with screenshots, videos, traces, console output, and network details./pages/UxI3D69jP7OLADRoqvSd
Product teamsCapture expected behavior in clear language so important flows can become repeatable tests instead of staying in notes, tickets, or memory./pages/33UtbH87hxyFCMYvvFyo
DevelopersReview the generated Playwright code in the app, optionally sync it two-way to your own repository, and use run evidence to understand whether a failure is a product issue, test issue, or environment issue./pages/Jh6z1m5ZcGgKSkTs5Q45
Team leadsSee whether important journeys are covered, whether runs are healthy, and where the team should spend time improving coverage or stability./pages/8ZXQNue5oXlx0RsH5wHp
## What Each Role Can Do ### QA and test teams QA users can use TestVibe as the main workspace for day-to-day test work: * organize tests into groups * write test instructions in plain language * use the recorder to capture browser steps * generate Playwright tests * run one test, a group, or the full suite * inspect failure evidence and decide what to do next Start with [Create Tests](/create-tests.md), then move to [Generate Tests With AI](/ai-generation.md) and [Run Tests](/run-tests.md). ### Product teams Product users can help make tests more meaningful by describing the behavior the product should support. You do not need to write Playwright code to contribute. A strong test instruction can explain the user journey, the action to take, and the result that proves the product is working. Good product input helps TestVibe generate tests that check the right thing, not just click through a screen. Start with [Write good test instructions](/create-tests/write-good-test-instructions.md) and [Key concepts](/readme/key-concepts.md). ### Developers Developers can stay connected to the code side of testing without having to be the only people who create every test. Generated Playwright files live in your project, so developers can review them, edit them, and treat them like normal test assets — and optionally mirror them two-way to the team's own repository (GitHub, GitLab, or Azure DevOps) by connecting it in Settings → Test Files Sync. When a run fails, TestVibe gives the evidence needed to understand the failure before jumping into code. Start with [Read generated output](/ai-generation/read-generated-output.md), [Choose browser, viewport, and configuration](/run-tests/browser-viewport-configuration.md), and [Inspect failed steps](/results/inspect-failed-steps.md). ### Team leads and managers Leads can use TestVibe to understand testing progress and quality signals without having to inspect raw run logs first. TestVibe helps answer questions such as: * Which flows have tests? * Which tests are ready to run? * Which runs are passing or failing? * What evidence explains a failure? * Where should the team improve instructions, generated code, or application behavior? Start with [Review Results](/results.md) and [Understand live run status](/run-tests/understand-live-run-status.md). ## When TestVibe Is A Good Fit TestVibe is a good fit when your team wants to: * build UI test coverage faster * keep test intent readable to non-developers * generate Playwright tests with AI * keep tests, runs, and evidence together in one place * run tests repeatedly against a real site * review visual and technical evidence when a run fails It is especially useful for teams that want test creation, execution, and review to feel like one workflow instead of being spread across separate tools. ## When You May Need More Setup Some teams need a little extra preparation before TestVibe feels smooth: * The target site must be reachable from the cloud test session. Private apps need a [tunnel device](/account-settings/tunnel-devices.md). * Test credentials and other values should be added as variables and secrets in Settings before tests reference them. * The team should agree on naming, grouping, and instruction style so generated tests stay easy to maintain. If you are setting up for the first time, start with [Set Up Your Workspace](/workspace.md). ## How Teams Work Together In TestVibe The best TestVibe workflow is collaborative: 1. Product and QA describe the behavior that matters. 2. QA organizes that behavior into tests and groups. 3. TestVibe generates Playwright code from the test intent. 4. Developers review or refine generated code when needed. 5. The team runs tests and reviews results together. 6. Failures lead to a clear next step: fix the app, improve the test, update the instructions, regenerate, or re-run. ## Where To Go Next
If you are evaluating TestVibe
If you will write or review tests
If you will run and diagnose tests
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.testvibe.com/readme/who-testvibe-is-for.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.