# Product Testing: Getting started

> A Claude Code skill that tests a product the way a QA engineer would: it inventories every surface, attacks it across functionality, UI, load and security, and leaves behind a runnable test suite and an evidence-backed findings report.

Page: https://developers.zactonz.com/skills/product-testing/getting-started/

Complete documentation for this product: https://developers.zactonz.com/skills/product-testing.md

## Install

Download the skill package from the latest GitHub release and unpack it into your Claude Code skills folder. The archive contains a single `product-testing/` folder.

```bash
curl -fsSL https://github.com/zactonz/zactonz-product-testing/releases/latest/download/product-testing.skill -o product-testing.skill
unzip -o product-testing.skill -d ~/.claude/skills/
```

Or clone the repository and copy the folder, which is the same operation:

```bash
git clone https://github.com/zactonz/zactonz-product-testing.git
cp -r zactonz-product-testing/skills/product-testing ~/.claude/skills/
```

Use `./.claude/skills/` instead of `~/.claude/skills/` to scope the skill to one project. Either way, start a new Claude Code session afterwards so the skill is picked up.

## Install as a plugin

The repository is also a Claude Code plugin marketplace with one plugin in it, so Claude Code can install and update the skill itself. A plugin resolves through a marketplace, so register the marketplace first; `claude plugin install` on its own will not find it.

```bash
claude plugin marketplace add zactonz/zactonz-product-testing
claude plugin install zactonz-product-testing@zactonz-product-testing
```

The plugin installs at user scope and contains the one skill. Start a new session afterwards, as with the plain install.

## Verify the install

```bash
python3 ~/.claude/skills/product-testing/scripts/surfaces.py --help
python3 ~/.claude/skills/product-testing/scripts/loadtest.py --help
```

Both should print usage. If `surfaces.py` runs but Claude never seems to use the skill, check that `SKILL.md` sits directly inside the skill folder rather than one level down: `~/.claude/skills/product-testing/SKILL.md`.

## Requirements

| Component | Needed for |
|---|---|
| Claude Code | the skill |
| Python 3.9 or newer | the two bundled scripts |
| A browser driver | the UI dimension only, see below |

Nothing else. The scripts use the Python standard library, so there is no install step and nothing to keep up to date.

For the UI dimension the skill uses whatever is already available, in this order: the session's own browser tools; a driver the project already has (Playwright, Cypress, Puppeteer); otherwise it says so and falls back to asserting server-rendered HTML, which checks markup but not rendering. It will not install a browser without asking.

## Run a first pass

Ask in the ordinary way; the skill triggers on its own.

```
test the export endpoint before I ship it
can the API handle Black Friday traffic?
find the edge cases in the invoice form
is this upload handler safe?
full QA pass on the dashboard
```

To scope deliberately, name the dimensions: *run the load and security dimensions against the staging API*. Naming none runs all four.

## What happens, in order

1. **Scope.** It establishes what is under test, the commit or version, the URL, the environment, and settles authorization if load or security work is involved. Expect to be asked before any traffic goes at something live.
2. **Inventory.** It enumerates the product's surfaces rather than testing from whatever a code skim surfaced. This is the step that decides whether the rest is real.
3. **Plan.** A short table of surfaces and the cases chosen for each. On a large or ambiguously scoped product it will show you this before a long run.
4. **Execute.** Dimension by dimension, capturing raw output as it goes.
5. **Suite.** Tests written into the project's existing test location, in its existing idiom, wired to one command.
6. **Report.** A verdict, ranked findings with minimal reproductions, and an explicit list of what was not tested.

## What you get back

- **A report** at `test-reports/<date>-<scope>/report.md` by default, with the evidence beside it. See [Reports](https://developers.zactonz.com/skills/product-testing/reports/).
- **A test suite** where the project's tests already live. Every confirmed finding gets a test that fails today; those are the regression guards, and they flip green as each fix lands, which is a better signal that a fix worked than re-reading the diff.
- **The raw captures** the report rests on, so any claim can be checked.

Evidence files can carry real payloads and screenshots. The skill will say so and ask before committing them; decide whether that directory belongs in git.

## Scoping advice

The skill is worth reaching for on a pre-release pass, after a refactor that touched many surfaces, when inheriting an unfamiliar codebase, or when you need a defensible answer to "is this ready". It costs roughly 1.8× the tokens and 2.3× the time of testing without it (see [Evaluation](https://developers.zactonz.com/skills/product-testing/evaluation/)), which is plainly worth it for those, and not worth it for a one-line sanity check.

On a large product, scope the first run to one dimension and a handful of surfaces rather than asking for everything. A focused pass that finishes beats a broad one that runs out of room, and the inventory from the first run makes the next one cheaper.