ComposalUse cases
Where Composal fits in testing and engineering
Composal sends AI browser agents to use your running web app the way a person would, then reports what broke with recordings and steps to reproduce. It covers regression journeys, exploratory sessions and code a coding agent wrote, on pull requests, around releases and on demand. Each Finding can be sent to a coding agent.
What Composal is, in short
Composal is a QA product for end-to-end testing: it sends AI browser agents to use a web app the way a person would. It runs journeys as plain-English Scenarios, which only look around unless they are allowed to write, and explores areas nobody scripted, against staging, pull request previews or production. It fits pull request review, release sign-off, dependency and framework upgrades, and code written by coding agents. A browser Run keeps recordings, a step timeline, console errors and failed requests, and reports Findings with steps to reproduce when something breaks. Coding agents drive it with the com CLI and composal skill.
- Discovery Agents explore an undocumented app and return recordings and gaps; a separate pass saves observed journeys as Scenarios to review.
- Scenarios Regression journeys in plain English with no selectors, stored as YAML and run in parallel on pull requests or from your CI.
- Deep Scan Agents given one area and a goal try messy input, interrupted flows and unscripted paths, then report reproduced or suspected Findings.
- CLI The com CLI lets a coding agent or CI job upload Scenarios, start Runs and read Findings, guided by the composal skill.
Start with a deep dive
Eight longer pages: how a QA team, a developer or a PM uses Composal, and the jobs it does for a product.
- QA Teams Regression coverage that keeps up with every release
- Developers Know a feature works before the review starts
- Product managers See whether the release works for your users
- Continual agent verification Your app, checked on every change and after each deploy
- Regressions Find the edge cases before the big release does
- Multi-persona Many agents using your product like real users
- Software factory A verification agent that closes the loop
- QA on tap A QA team you can call on any time
Browse by situation
113 ways Composal fits, grouped by when it runs, what it covers, who uses it and what it runs against. Search them or filter by what they rely on.
113 situations
Filter by what a situation relies on
On every pull request
What happens when a pull or merge request opens: which Scenarios run, what a reviewer sees, and what is left untested.
A reviewer would normally run the branch locally and click around. Instead the relevant Scenarios run on a preview of the exact commit, and the pull request comment links to the Run and its recordings.
PR verification reads the changed files and hunks, picks the saved Scenarios that look relevant and records a reason for each choice, so a reviewer can see why one journey ran and another did not.
A Scenario the selection was not sure about is listed as untested, never as a pass. An admin who wants it can pick it from the PR page and run it against the same exact-commit preview.
A tweak to a shared button, modal or form reaches screens the author never opened. Scenarios from different features can land in the same Run, and anything the selection could not map stays listed as untested.
With the opt-in comment and label triggers turned on, a repository owner, member or collaborator can start a Run by posting /qa as the whole comment, or a custom label can start one. Drafts wait until ready.
When every changed path is one you excluded, such as docs/** or README.md, the browser is skipped and the reason is recorded. A wording change in the app still goes through normal selection.
On GitLab, a CI job hands the merge request's preview to Composal and waits. One note on the MR then carries the commit that ran, each Scenario's result, why it was chosen and links to the recordings.
Releases and deploys
Running the same Scenarios around shipping: before promotion, right after a deploy, behind a flag and after a rollback.
Keep the journeys that must never break, such as sign-in and checkout, as a small set of Scenario files. Your CI runs them with com verify scenarios run as the last step of a deploy, and the Run reports what broke, with recordings.
Before a build is promoted from staging, run the Scenarios for the main journeys against it. The person signing off reads what passed, failed or was blocked, with recordings where captured, and which Scenarios were included.
A hotfix cannot wait for a full regression pass. Run the Scenarios around the fix, plus the smoke label, against the patched Environment and watch the recordings before telling support the problem is gone.
Point the same Scenarios at a flag-on Environment and a flag-off one, or at Personas whose accounts have the flag set. A journey that works in one state and breaks in the other shows as a failed Outcome with a recording.
A rollback restores the old build but not always the old state. Run the Scenarios that passed before the release against the rolled-back Environment and read what is still broken, with recordings.
A CDN rule, proxy setting or config value changes no application code, so no pull request selects anything. Have your pipeline run a small set of Scenario files against that Environment once the change is applied.
At launch, run the read-only Scenarios against the live Environment and keep the Browsers grid open to watch each session as it goes. The team sees a break while the announcement is still fresh.
Upgrades and migrations
Changes that should leave the product looking the same to a user: dependency bumps, framework upgrades, migrations and rewrites.
A Renovate or Dependabot bump passes unit tests, then breaks a screen. Its PR runs the Scenarios the diff plausibly touches in a real browser, so a broken screen shows up on the PR as a failed Outcome with a recording.
A new major version of your framework changes routing, rendering and forms everywhere, and the diff is too wide to reason about. Run every saved Scenario against the upgrade branch's preview and read the failures with recordings.
Moving to a new service or database should change nothing a user sees. Run the saved Scenarios against the migrated stack, and a browser Run keeps the failed requests and console errors that point at what moved.
Swapping the sign-in provider changes every way into the app. Run sign-in as each Persona, member and admin, then a fresh email sign-up and a signed-out visit to a protected page, and see who lands on the wrong screen.
A component library swap or a styles rewrite touches every screen while the code still compiles. Run the journeys on the migrated preview, then aim a Deep Scan's UI and accessibility lanes at the screens that changed most.
A new bundler can leave the dev server fine and the production build broken, with a missing asset or a blank route. Scenarios run against the built, deployed preview, so they exercise the build rather than the dev server.
In a rewrite or replatform, the old app is the specification. Let Discovery map it and save its journeys as Scenarios, then run the reviewed ones on the new Environment, where a failed Outcome marks a gap to close.
Code written by agents
A coding agent says the work is done. These are the ways to check it in a browser and send what breaks back.
A coding agent opens a pull request and reports that the feature works. That report is not evidence, so the saved Scenarios the diff touches run in a real browser on that commit's preview and the results go to the PR.
A failed Scenario on the pull request comes with its steps and recording. Fix With Agent opens a prompt for Codex, Claude Code or Cursor, and a Discovery or Deep Scan report has Copy finding for any other agent.
- Coding agents for Failures handed to the coding agent
- Evidence for Failures handed to the coding agent
- Pull requests for Failures handed to the coding agent
Scenarios for Failures handed to the coding agent
Discovery for Failures handed to the coding agent
Deep Scan for Failures handed to the coding agent
Have the agent add a Scenario file in the same pull request as the feature. Steps and Outcomes are plain English, reviewed like code, linted offline in CI and uploaded, so later pull requests that touch the area can select it.
Several agents push branches in the same afternoon. Each pull request is verified on its own exact-commit preview, in its own Run in cloud browsers, so a failure is tied to the branch that caused it.
With the composal skill and the com CLI, an agent lints and uploads Scenarios, starts a Run on its preview, reads the failing step and console errors, fixes its code, and runs again.
A prototype an agent built in an afternoon looks right on the path its author tried. Point Discovery at the URL before the demo for an outside view of what each screen does and where the agents could not continue.
Connect the Composal MCP plugin and the Verify app opens inside Codex or another MCP client. The agent starts a Run on your staging URL and the results and recordings stay in the same session.
Regression testing
Old flows break quietly when something near them changes. These are the habits that keep them in front of a browser.
The bug that reached production once, or one a customer ticket described, should not get there twice. Write its steps to reproduce as a Scenario with the correct behavior as the Outcome, so later pull requests can select it.
A developer says the checkout bug is fixed. Retry the failed Run to repeat the same Scenarios on the same Environment, then read the Outcomes and recording instead of taking the fix on trust.
Run the same plain-English Scenario against staging, a pull request preview and read-only production by choosing another Environment. Each Run pins the Environment, Scenario version and runner, so a difference can be traced.
The coupon works and the plan upgrade works, but not together. One Scenario can carry a journey across both features, so a pull request that touches either one can select it.
When a stakeholder asks how stable checkout has been, each Scenario shows its recent Runs and success rate over the past month, with the pull request that triggered each. A journey that went red after one merge stands out.
Exploring the unknown
Sometimes nobody has written down what the app does yet. These are the ways to go and find out, with evidence.
You took over an app with little written down. Start a Discovery with a URL and an account to sign in with, and agents return the screens, the connected journeys, and the roles and setup each one needs, with recordings.
Give the scan an observable goal, such as cancelled edits must not change saved content, and say what the QA account may change. Agents try messy input and interrupted flows and report reproduced and suspected Findings.
The launch is close and the happy path has only been walked by the people who built it. Sweep the whole product before it ships: Deep Scan the main flows across functionality, UI, UX and accessibility, then review Findings with steps to reproduce.
Saved Scenarios cover what someone remembered to write. A Discovery maps what the app offers, and its authoring pass saves the observed journeys as new Scenarios for you to review next to yours.
An error page with no way back, an empty state with no action, a setup that stalls halfway. Discovery reports the issues agents hit and the places where they could not continue.
Deep Scan the module before the refactor and keep the report to see what already misbehaves. Scan again afterwards: a Finding that appears only the second time is a lead to check against the change, not proof.
Knowledge holds short guides to the main product areas: what they do, how to reach them and which roles can use them, learned from earlier Runs. A new hire reads them, or asks a coding agent through com knowledge.
Everyday user flows
The flows nearly every product has, from sign-up to settings, written as Scenarios in plain English and run in a real browser.
A new visitor signs up and meets the product for the first time. The Scenario uses the sign-up Persona and its own inbox, reads the sign-up email, and ends with the Outcome that onboarding lands on the right screen.
Every other journey starts with getting in. A Scenario per Persona signs in and lands on the right screen, and one more submits the forgot-password form as a signed-out visitor and states what the page must say.
A change near the cart can quietly break the payment form. In staging, the Scenario fills it with the provider's test card and ends on two Outcomes: the order total is right and the confirmation screen appears.
Required fields, bad formats and server-side errors appear all over a product. The Scenario submits a form empty, then with a bad value, and the Outcome is a message next to the field that caused it.
A filter that resets on page two, or a sort that ignores the search term, is easy to miss. Scenarios apply each control in turn and page through, with the Outcome that every row matches what was asked for.
Preference changes are easy to save and easy to lose. As a member, the Scenario edits a profile field and a notification option, saves, and the Outcome is that the change shows where it is used, such as the header.
Changing plan touches billing, limits and the interface at once. As a paying Persona, a Scenario switches the billing period, upgrades, then downgrades, with Outcomes for the price shown and the plan the account reports.
An import that chokes on a real invoice only fails when someone uploads one. The Scenario attaches the file as a fixture, picks it in the app's own file picker, and ends with the imported rows in the list.
Roles, accounts and teams
Products behave differently for each role and account, and Personas let Scenarios check what each person can reach and do.
Admin, member and viewer each get a different interface. Each role becomes a Persona with its own stored Credentials, and a Scenario per role records what that person can actually do in a real browser.
A viewer who finds an Edit button, or a member who reaches billing, is an easy regression to ship. Scenarios sign in as the lower role and state the Outcome: the control is missing or the page refuses.
An admin invites a member by email and the member accepts. A multi-actor Scenario gives each person a Persona and a distinct working account, and walks both sides in order with evidence from each browser.
A free account should hit the limit and a paid one should not. Personas on each plan, including the one a customer reported a problem on, try the same feature, and Scenarios state which gets through and which sees an upgrade prompt.
An owner shares a document and the teammate has to see it. A multi-actor Scenario creates the item as one Persona, opens it as another, and ends with the Outcome that both reach the same item in their own sessions.
A new account gets a welcome prompt and a setup checklist, an established one a busy dashboard. Starting conditions name the state a Scenario needs, so each gets its own Scenario and an account kept in that state.
One customer must never see another's data. With accounts in two workspaces and authorization for that scope, aim a Deep Scan's security lane at the boundary and review what it reaches as reproduced or suspected Findings.
Edge cases and failure modes
The moments that break products in practice: empty screens, repeated clicks, reloads, odd input and failed requests.
A blank table or a raw error page is what a user sees when data is missing or a request fails. Scenarios use an account with no records and an unknown page address, and state the Outcome: a message that says what to do next.
Reports, imports and assistant replies arrive after a pause. A Scenario states how long to wait and what must appear, and the Run recording shows what the screen did in between.
A pasted link to a filtered list, or the Back button after a form, should not land somewhere wrong. Scenarios open the link as a signed-out visitor and as a member, press Back, and state which page and filters must show.
A wizard half filled in, then the tab reloads. A Scenario reloads mid-flow with the Outcome that the draft survives, and Deep Scan tries the interruptions nobody scripted, with a recording of where the person landed.
A second click on Pay or Save can create two orders or two records. Give Deep Scan the goal that a repeated submit must not duplicate a record, and any duplicate it finds comes back as a Finding with steps and a recording.
A very long name, an emoji, a stray quote or a pasted paragraph is where form handling breaks. Deep Scan aims at one form and reports what breaks, with the exact input used and what the screen showed.
The screen looks right while a background request fails or the console fills with exceptions. A browser Run keeps the console errors and failed requests next to the recording, so they can be read even when a Scenario passed.
Beyond the browser
Desktop apps and Android builds get Scenarios, recordings and Findings like a website does, with clear limits.
Upload a standalone APK and each Scenario installs that exact build in a fresh Android emulator, then taps and swipes through the flow. Sign-ins and app data start clean every time.
A native app launches on a disposable Linux desktop, and Scenarios drive it through its windows, menus and dialogs as a person would. Every Scenario gets a fresh desktop, so no profile or sign-in carries over.
Discovery and Deep Scan work on desktop and Android builds too, each tester in its own desktop or emulator. Recordings, screenshots and Findings appear in the same Run pages as a website, without console or network tabs.
Export or save from a desktop app and the Scenario can end on the file itself. The Outcome names an allowed output path and the text it must contain, and text and ODT files can be read.
Desktop means Linux on X11, and mobile means an Android emulator without Google Play services. Mac and iOS apps, Wayland desktops and Android App Bundles are not covered, and browsers remain the main product.
QA teams
How a QA team covers a large product, keeps expected behavior written down and triages from evidence.
The release plan is a spreadsheet of numbered cases, or a backlog waiting for an engineer to script it. QA writes each row as a Scenario in plain English, with no selectors, and the plan runs in parallel in cloud browsers.
What checkout should do lives in old tickets and one tester's memory. A Scenario writes down its starting conditions, steps and Outcomes in plain English, so the next person to change checkout has something to read first.
A handful of testers cannot walk every screen each release. Steer a Discovery with a goal toward the areas nobody reaches, such as admin and billing, and review what its agents observed before deciding what to cover.
The Findings list holds every Scenario failure and every bug a Discovery or Deep Scan reported, highest priority first, each linked to the Run that last saw it. Resolve or ignore one and it moves to Closed.
Before an audit or a launch, aim a Deep Scan's accessibility lane at one flow, such as sign-up or checkout. Findings arrive with steps to reproduce and recordings, and a human review still decides compliance.
Release week goes to re-walking the same flows. Saved Scenarios can run those flows in parallel, and a Deep Scan on the new feature gives testers Findings to start their exploratory sessions from.
Engineering teams
Where Composal fits in an engineering team's week: before review, on the pull request, in a monorepo and when something breaks.
Your unit tests and scripted end-to-end suite stay where they are. Scenarios cover journeys nobody has scripted, written in plain English and run in a real browser on the pull request's preview.
A scripted Playwright suite needs locator fixes whenever the markup moves. Scenario steps are prose, such as Open Settings, then Members, so a file holds no selectors, though you still edit it when the behavior changes.
Without a QA role, whoever merges last does the smoke pass, or nobody does. The relevant saved Scenarios run on each pull request, so verification stops being a rotating chore and the results sit where the team already works.
Before opening the pull request, run the Scenario for your feature in Chrome on your own machine against localhost, with your own model access. You see where it stops while the change is still yours.
A pull request that collects many pushes keeps a Verification History: each commit that ran with its outcome and setup reason, and results from an older commit marked as an earlier revision.
In a monorepo, a change under a shared package may not name the apps that use it. PR verification compares the changed paths and hunks with your saved Scenarios and leaves anything it cannot map untested.
An alert or a one-line report says a flow is broken, with no steps. Give Deep Scan that line as its goal against staging, and it reports what it could reproduce or suspects, with expected versus actual and a recording.
The deploy console or service catalog a platform team runs has no QA and sits on a private network. Once the Environment is reachable, a few Scenarios cover the actions the team relies on, such as opening a deploy.
Product, design and support
How PMs, designers, support and sales teams see what users actually get, with Scenarios written in plain English.
Sign-off means clicking through staging with the ticket open. Write the acceptance criteria as a Scenario's Outcomes in plain English, run it on the preview, and sign off from the Run's results and recordings.
The mock shows an empty state, an error message and a disabled button. Describe each as an Outcome, and a Scenario walks to the screen and reports what is actually visible, with a screenshot when it differs.
A help article says click Billing, then Invoices, and the menu has moved. Write the article's steps as a read-only Scenario, and a Run shows where the documented path stops matching the app.
A content edit goes live and the pricing link leads nowhere, or a page lost its sign-up button. A read-only Scenario as a signed-out visitor follows the key pages after each publish, started from the CLI in your pipeline.
A stale seed or a broken integration shows up in front of the prospect. Run the demo Scenarios as the demo Persona just before the call: they only look around by default, and a read-only demo account makes that firm.
By kind of product
How Composal fits the web apps teams build most, from storefronts and dashboards to admin consoles and chat apps.
One failing panel can hide on a mostly loaded dashboard, because tiles, charts and tables each come from their own query. Name the panels that must show data as Outcomes, and the Run's failed requests point at the one that did not.
Product pages share one template, but a sale price, a size variant or a sold-out state changes what each one shows. Scenarios open one of each signed out and state the price, button and message it must show.
A refund tool or support console has many write buttons and no test suite. Scenarios only look around unless their file allows writes, and Discovery's read-only goal is an instruction, so give it a read-restricted account.
A seller publishes a listing and a buyer has to find it, then the seller unpublishes it. A multi-actor Scenario signs in both sides in order, and the Outcome is what the buyer sees, recorded from the buyer's browser.
An amount typed on a transfer form must read the same on the review step, the confirmation and the activity list. Scenarios follow it across screens in staging, while the ledger itself stays with your own tests.
A booking holds a slot until it is cancelled, then the slot must be offered again. Book and cancel as a member in a Scenario, then let a Deep Scan work the picker with the back button, a reload and a changed date.
A theme or template change touches every page type at once. Scenarios open an article, a category page, search and the home page signed out, and state the headline, byline and links each one must show.
The console around an API has a short list of jobs: create a key, rotate it, add a webhook endpoint. An admin Persona does each one and the Outcome is what the screen shows, while the API itself stays with your own tests.
Lessons become available in order and assignments take file uploads. A Scenario acts as a learner, attaches a fixture file to a submission, and states that the next module opens and the progress bar moves.
Assistant replies never read the same twice, so an Outcome that quotes exact text is brittle. State what must be visible instead, such as a reply under the question, a source link, or the thread saved in history.
Environments and access
Where Runs point and how they get in: previews, staging, production, private networks and the accounts they sign in with.
Your CI hands over the preview URL, a GitHub or GitLab deployment is discovered, or Composal deploys a preview itself. Whichever you choose, Composal will not substitute an older deployment or a shared environment.
Staging is where a Scenario may create, change and delete data. Set allowed_actions to writes in that Scenario, give it staging's own accounts, and spell out the starting data it expects to find there.
Register production as an Environment and keep its Scenarios read only, the default, signing in with a synthetic account to look around the live product. For enforced write prevention, use an account restricted to reads.
Passwords, authenticator seeds, saved sessions and passkeys live encrypted in a project's Credentials, never in Scenario files or prompts. A Run is handed only the account it needs, and the agent sees references.
When login asks for an authenticator code or an emailed one, the authenticator key stays encrypted, the agent generates a fresh code at each sign-in, and an inbox the Run can read covers emailed codes and links.
When sign-in needs a person, such as SSO or a push approval, sign in yourself once and save the app session for Runs to start from. It is tied to one origin and expires, and some providers reject automated browsers.
An internal preview, or a dev server on your laptop shared with Tailscale Serve, stays off the public internet. Each browser sandbox joins your tailnet as an ephemeral device and reaches only what your policy grants.
The frontend is public but the API sits behind an internal load balancer in your VPC. A split-tunnel Client VPN connection lets the browser reach the private API while public services stay on the internet.
When a firewall or Cloudflare WAF rule blocks unknown browsers, your account manager can arrange dedicated static outbound IPs for your hosted browsers to allowlist, though Bot Fight Mode cannot be skipped by a WAF rule.
Evidence and hand-off
What a Run leaves behind, and how a Finding travels to the person or coding agent who has to fix it.
A failed Scenario keeps its session on video where one was saved, with the step timeline beside it. The ticket can point at the recording instead of a paragraph of steps written down from memory.
In a Discovery or Deep Scan report, Copy finding puts the steps to reproduce, what was expected and the evidence links on the clipboard as text, ready to paste into an issue tracker.
A failure is being argued over in a thread. Copy Link shares the selected session and recording step, so teammates in your organization open the same moment, and with the Slack app installed a Run link can show a result card.
Some time after a release, someone asks what was actually verified. Each Run pins the Scenario versions, Personas, Environment and runner it used, and keeps its Outcomes and evidence.
Deep Scan labels each Finding reproduced or suspected, so triage knows what to fix now and what to look at first. Rerun a suspected one in a fresh browser to see whether it repeats.
A Scenario that cannot proceed because an account, a teammate or an inbox is missing is reported as blocked, with the reason and evidence, rather than as a failed Outcome, so a setup gap is not read as a bug.
When a Discovery or Deep Scan hits a bug the project already tracks, it is recorded as another occurrence, not a new Finding. Memory from earlier Runs helps agents work around quirks and never changes what a Scenario expects.
Questions teams ask
- What is Composal used for in testing and engineering?
- Composal sends browser agents to use a running web app the way a person would, then reports what broke with recordings and other evidence. Teams use Composal to verify pull requests, run saved Scenarios from the com CLI in their CI, explore an app without writing steps first, and hand Findings to a coding agent. A project can start from just a URL, and connecting a repository is optional.
- How does Composal verify a pull request?
- When a pull request or merge request opens or gets a new commit, Composal compares the changed files with the project's saved Scenarios, selects the relevant ones and records a reason for each. The selected Scenarios run in parallel in cloud browsers against a ready preview of that exact commit, and one results comment or note on the request links the evidence. Scenarios Composal was not confident about stay listed as untested, never as passed. The result appears as a check on that commit, and whether a failure blocks merging is set by your source provider's branch protection.
- Does Composal replace Playwright, Cypress or unit tests?
- No, Composal does not replace unit tests or Playwright and Cypress suites. It checks a running app at the level of user journeys: browser agents carry out Scenarios, written as plain-English steps and Outcomes, on an Environment such as a pull request preview. Discovery and Deep Scan can also explore paths nobody has written down. Existing suites can stay in place for what they already cover.
- What is a Scenario, and how is it different from a test script?
- In Composal, a Scenario is one user journey written in plain English: a name, starting conditions, ordered steps and the Outcomes that must hold. It can be edited as a YAML file, linted offline and uploaded, so people and coding agents maintain it like code. A scripted browser test spells out how to drive the page; a Scenario states what a person does and what they must see, and its authored Outcomes decide whether it passed.
- What kinds of apps and environments can Composal run against?
- Composal runs against any URL a remote browser can reach: staging, a pull request preview, production with synthetic accounts and data, or another app you operate. Private apps are reachable through Tailscale or AWS Client VPN, and an app on your own computer through Tailscale Serve. Composal can also drive a native Linux desktop app on X11 and a standalone Android APK in an emulator without Google Play services. Mac and iOS apps are not covered.
- How does Composal find bugs nobody wrote a Scenario for?
- Composal has two ways to look for bugs nobody wrote a Scenario for. Discovery sends browser agents to explore the app with the access you give them, returns recordings, observations, potential issues and gaps, and saves what they observed as Scenarios you can review and run. Deep Scan aims a team of agents at one area with an observable goal, and they challenge input boundaries and state transitions across functionality, UI, UX, accessibility and authorized security boundaries.
- How do coding agents use Composal?
- Composal installs a composal skill into a project with com skills install, so a coding agent such as Codex, Claude Code or Cursor can write Scenario files, lint and upload them, start a Run and read the failing step with its console errors and failed requests through the com CLI. Findings can be handed to the agent with Fix With Agent or Send to Agent. A hosted MCP connector also lets an assistant configure projects, launch Runs and read results.
- What does Composal's output look like?
- A Composal Run reports each Scenario as passed, failed, blocked, cancelled or timed out, and keeps its recording, step timeline, console errors, failed network requests and screenshots, with a replay player to step through them. Each Finding states what was expected, what happened and the steps to reproduce it. Deep Scan separates reproduced bugs from suspected ones, so triage knows which Findings are leads.
- What does Composal not do?
- Composal exercises a running app through its interface in a browser, reports Findings with evidence, and hands them to your coding agent or team to fix. It does not edit your source code, and it is not a unit-test runner, an API-only tool, a load or performance testing tool, a security scanner or penetration test, or a pixel-diff screenshot comparison. A pass covers the selected Scenarios in that Run, and a finished Run or Deep Scan shows what was covered and what was blocked. It is not proof that every bug was found or that the whole app passes.
Terms on this page
- Project
- The product under verification. It owns its Scenarios, Personas and Environments.
- Environment
- The URL a Run points at: staging, a pull request preview, production or a private app.
- Persona
- Who a Scenario acts as, such as a signed-out visitor, a member or an admin.
- Scenario
- One user journey in plain English: a name, starting conditions, ordered steps and the Outcomes that must hold.
- Outcome
- An observable result that must hold for a Scenario to pass.
- Run
- One execution of chosen Scenarios against an Environment. Each Scenario passes, fails, is blocked, is cancelled or times out.
- Finding
- One bug, written as a report someone can act on, with steps to reproduce and evidence.
Not on the list?
If a person can do it in a browser, you can usually write it as a Scenario. Tell us how your team ships and where checking it takes the time, and we will show you how it would run.