# 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
DevelopersKeep generated Playwright tests in the repository, review the code when needed, 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 and workflow side of testing without having to be the only people who create every test. Generated Playwright files live in the connected repository, so developers can review them, edit them, and treat them like normal test assets. 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 workflow 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 * store test files in GitHub * run tests repeatedly against a real site * review visual and technical evidence when a run fails It is especially useful for teams that already use GitHub and want test creation, execution, and review to feel like one workflow. ## When You May Need More Setup Some teams need a little extra preparation before TestVibe feels smooth: * The GitHub App must be installed for the repositories you want to test. * The target site must be reachable from the test runner. * Required API keys and repository secrets must be available before AI generation can run. * 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: 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: ``` GET https://docs.testvibe.com/readme/who-testvibe-is-for.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.