Cat-Inspector: Rethinking Backend QA Without a Parallel Test Suite — beta version

A no-code platform for testing real server logic — now in public beta

The gap most teams already feel

If you have ever watched a release stall because “only the developers can run that check,” you know the pattern.

Backend logic lives in services, handlers, and pipelines. QA needs to validate it deeply — edge cases, return shapes, error paths — but the tools in front of them are often shallow: manual clicks, Postman collections that go stale, or tickets that bounce back to engineering.

On the other side, developers maintain Jest or Mocha suites that duplicate what product and QA already care about: same inputs, same expectations, written twice — once for CI, once informally for humans. When the API changes, someone updates the code and chases the test file and explains the new shape to QA. That drift is expensive, and it gets worse as the team grows.

Cat-Inspector is built to close that gap: a no-code QA platform for Node.js backends, paired with an SDK that lets engineers expose a safe, documented surface — and lets QA run real checks from forms and scenarios, not from scripts in your repository.

What Cat-Inspector is

Cat-Inspector is a product in two parts:

1. The host SDK (@gloocan/cat-inspector) — embedded in your Node.js / Express application. Developers register or annotate which functions and HTTP-style units are allowed to be discovered and invoked. Metadata (parameters, return hints, optional JSON Schema, labels) feeds a live catalog.
2. The QA web platform — a tenant workspace where testers connect to a host, browse the catalog, author test cases from auto-generated forms, run pipelines/scenarios, and read structured pass/fail results with enough detail to know what failed, not only that something failed.

You are not replacing Express, your database, or your architecture. You are adding a controlled, allowlisted inspection layer that QA tools and automation can trust.

The biggest advantage: one surface, not two codebases

This is the point worth stating plainly, because it is why many teams adopt the model in development first.

When you use Cat-Inspector during dev, you do not need to maintain a separate test file for the same scenarios your QA UI already runs.

Traditional flow:

• Developers write unit/integration tests in TypeScript.
• QA (or PM) asks for the same cases in the product UI or via ad-hoc API calls.
• Two representations of the same truth — and they diverge.

Cat-Inspector flow:

• Developers register the functions that are safe and meaningful to call (decorators like @Cat, helpers like cat(), modules, Express pipelines).
• The catalog becomes the contract: stable function ids, parameter metadata, return labels.
• QA authors and runs cases in the platform — forms built from that metadata, assertions on structured results.
• The registered handler is the test target. There is no parallel *.test.ts file duplicating every payload and expectation for work that already lives in the QA workspace.

That does not mean “never write automated tests again.” Unit tests for pure algorithms, CI gates, and browser E2E still have their place. It means that for exposed business logic — the surface you intentionally publish to QA — you stop paying the tax of maintaining two worlds (repo tests + informal QA scripts) that always fall out of sync.

One source of truth for what can be tested, how it is described, and how it is executed.

How it works (high level)

Think of three roles and one wire between them:

Role : Responsibility

Backend developer : Wire the SDK, bootstrap the registry, register allowlisted units, configure transport (WebSocket, Socket.IO, etc.).

QA / product : Connect to the host, use the catalog, build cases and scenarios, run pipelines, review results in the Live Inspector.

Platform : Multi-tenant workspaces, API keys, saved cases, run history, pipeline domains — without testers cloning your repo.

Invocation path: QA client → versioned protocol → RPC pipeline on the host → validate args → run registered function → serialize result or typed error → structured UI (including inspector-style events for visibility).

Only registered entries appear in the catalog. There is no “call arbitrary code from the wire” design — the allowlist is the product.

What QA actually does (no code in your app language)

Testers do not need to learn your internal module graph or install your toolchain.

Typical workflow:

1. Connect — API key, host URL, transport (status badges show connect → catalog → scenario → done).
2. Browse the catalog — readable names, parameters, return metadata, tags.
3. Author cases — fill forms generated from schemas; set expectations (type match, JSON equality, field checks, and richer assertions over time).
4. Organize scenarios — group cases into pipelines/domains for regression-style runs.
5. Run and inspect — execute selected scenarios; use the Live Inspector to see per-step RPC outcomes, payloads, fnKey, and assertion results.

Compared to a generic API client, the difference is starting from developer-approved units with guided inputs and explainable failures tied to a named function, not a mystery 500 on a route nobody documented.

What developers integrate (SDK highlights)

The published package is @gloocan/cat-inspector on npm. Integrators typically:

• Register functions (@Cat, cat(), catModule(), class/service helpers, instance registration where needed).
• Bootstrap the registry (optional AST scan to enrich types from TypeScript sources).
• Expose transport — embedded WebSocket inspector, Socket.IO attach for playgrounds, remote bridge for split deployments.
• Align with Express — pipelines, correlation headers, HTTP bridge routes where HTTP and RPC meet.
• Apply policy — pre-invoke hooks, rate limits, audit events, serialization limits.

Return labels (Return, Throw, ApiReturn, etc.) let tooling and QA UIs understand labeled outcomes without changing your business semantics at runtime.

Full integrator documentation: **https://docs.cat-inspector.gloocan.com**

Security and intent (production-minded from day one)

Cat-Inspector is designed for teams who care about surface area:

• Allowlist only — if it is not registered, it is not invokable.
• Authentication on the transport — unauthenticated invoke should be rejected outside dev.
• Validation — parameters can be checked against JSON Schema before invoke.
• Tenant isolation — workspaces separate organizations, keys, and data.
• Operational hygiene — do not put production secrets in test payloads; use sandbox data and read-only contexts where appropriate.

This is inspection and QA against chosen entry points — not a replacement for your security review or pen test program.

What Cat-Inspector is not

Clarity helps set expectations:

• Not a replacement for Playwright/Cypress — it does not click every pixel in the browser. UI E2E stays with UI tools.
• Not “run anything on the server” — only registered units; that is a feature, not a limitation.
• Not a finished enterprise product yet — see beta note below.

What you do get: fast, repeatable, metadata-driven checks against real handlers in real process context, with QA-visible structure.

Who should care

• Backend / platform engineers tired of translating every QA question into a one-off script.
• QA leads who want depth without forcing testers into the repo.
• Engineering managers watching release friction from catalog drift and duplicate test maintenance.
• Teams on Node.js / Express (or similar) shipping APIs and services where logic validation matters as much as UI smoke.

If your pain is “only devs can run the real check,” Cat-Inspector is aimed at you.

Public beta — try it, break it, tell us

Cat-Inspector is live for early access in beta. That means:

• Features and UI will evolve.
• You may hit bugs, incomplete polish, or rough edges.
• It is not positioned yet as a fully hardened production SKU for every enterprise control.

We want real feedback from people who try it in anger — workflow fit, catalog clarity, pipeline runs, docs gaps, performance on your stack.

Links

Resource URL Platform (sign up & try) :https://cat-inspector.gloocan.com

Documentation : https://docs.cat-inspector.gloocan.com

SDK on npm : https://www.npmjs.com/package/@gloocan/cat-inspector

**Source & Issues :** https://github.com/gloocan/cat-inspector

Found a bug or something confusing? Please open a GitHub Issue with steps to reproduce (category, what you expected, what happened). That is the fastest way for us to prioritize fixes — better than scattered DMs.

A simple picture of the value

Before: Backend logic → hidden behind APIs → QA uses generic tools or asks devs → devs maintain separate test files → drift and delay.

After: Backend logic → registered catalog → QA uses forms and scenarios on the same surface → structured results and Live Inspector → no parallel test file for that same exposed surface in dev.

The win is not only speed. It is visibility: named units, structured errors, traceable steps — so “the checkout API failed” becomes “OrdersService.placeOrder failed validation on field X in case #12,” and the whole team moves faster.

Closing

Software quality improves when the people closest to the business can run the checks that matter — without waiting for a developer to write another test file for every scenario they already described in words.

Cat-Inspector is our attempt to make that practical for real backends: allowlisted, metadata-driven, no-code for QA, SDK-first for engineering.

If you are exploring better ways to bridge dev and QA on Node services, create a workspace, connect a host, and tell us what you think. Beta is the right time to shape the product with you.

Thank you for reading — and for any issue you file or feedback you share.

Attention : Do not use this as production. so data was not stay in permanent. this is only for testing until production release.

About the author

Chamodh is the Founder of Gloocan, where he builds tools that help engineering teams ship with more confidence and less friction between development and QA.

Cat-Inspector started from a simple observation: teams were maintaining the same checks twice — once in code as test files, and again informally for QA — while testers still couldn’t run deep backend validation on their own. Gloocan’s mission is to close that gap with practical, developer-first products that keep security and clarity at the center.

If you try the beta, Chamodh welcomes direct feedback — especially on workflow fit, catalog usability, and whether the “no separate test file” model matches how your team works today.Public beta — try it, break it, tell us

Cat-Inspector is live for early access in beta. That means:

• Features and UI will evolve.
• You may hit bugs, incomplete polish, or rough edges.
• It is not positioned yet as a fully hardened production SKU for every enterprise control.

We want real feedback from people who try it in anger — workflow fit, catalog clarity, pipeline runs, docs gaps, performance on your stack.