Glubean for QA Teams

You do not need to write TypeScript every day to use Glubean well.

Developers and IDE agents keep the durable source in git: contracts, workflows, raw tests, and load plans. QA can work from the evidence surfaces: the VS Code Result Viewer, Cloud Targets, Specifications, Explore, and the webapp Agent.

Your daily workflow

1. Review uploaded evidence in Cloud — open the Target for the service, read recent failures, and compare runs.
2. Read Specifications — check the executable API promises synced from source.
3. Use Explore — send requests, reproduce issues, and validate responses against the API model.
4. Ask the webapp Agent — explain the current page, summarize failures, or suggest missing cases.
5. Use VS Code when you need local runs — pinned tests and the Result Viewer are useful when QA works inside the verification project.

The loop is: inspect evidence, reproduce behavior, clarify the expected rule, and hand durable source changes back to the developer/IDE plane.

Pin the tests you care about

Not every test in the project matters to you daily. Pin the ones that do:

• Click the $(pin) Pin button above any test in the editor.
• The test appears in the Glubean Panel sidebar under Pinned Tests.
• Tomorrow, open the panel and click ▶. No file hunting.

Think of it as a bookmark bar for your test suite.

Reading the Result Viewer

The Result Viewer opens automatically after every run. Focus on these tabs:

• Assertions tab — the most important tab for QA. Shows each assertion with expected and actual values. Green = pass, red = fail. Start here.
• Trace tab — shows every HTTP request and response. Useful when you need to check what the API actually returned.
• Events tab — the full event stream. Useful for debugging complex flows.

You don’t need to understand the test code to read these results. They show you what the test checked and whether reality matched expectations.

Working with AI

AI is your pair — not a replacement for your judgment. You know the business logic. AI knows the syntax.

Useful prompts:

• “Why did this Target fail in the last run?” — the webapp Agent reads the current evidence.
• “Which contract promise broke?” — starts from Specifications and run links.
• “Can you turn this Explore request into a contract idea?” — creates a handoff for the source plane.
• “/glubean add a 404 contract case for this endpoint” — ask your IDE agent when the change should land in git.

You describe what should happen. The right agent helps turn that into readable evidence or source changes.

What you need to understand

You don’t need to learn TypeScript. But you do need to know:

• What the API should return — “this endpoint returns a list of active users” is enough for AI to write the right assertion.
• What changed — when a test fails, was the API updated? Did a requirement change? That judgment is yours.
• When to escalate — if AI can’t fix it, the API has a real bug. File it.

Your domain knowledge is the most important input. The code is just how it gets expressed.

How this compares to traditional QA tools

Glubean is not record-and-playback QA. The durable assets are code, stored in git, reviewed in PRs, run locally and in CI, then uploaded as structured evidence. QA does not need to own every line of TypeScript, but the team still gets a source-controlled verification system instead of a set of disconnected manual checks.

The result is verification that stays current with the product, not a test suite that rots after the first sprint.