# Testing

> Universal testing framework (frontend + backend) — a meticulous run of any testing task with evidence discipline. Use when you need to test a feature/form/build/API/service, draft a test plan, run checks, perform exploratory or regression testing, or find defects.

- **Type:** Skill
- **Install:** `agentstack add skill-akovalion-paranoid-qa-testing`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [akovalion](https://agentstack.voostack.com/s/akovalion)
- **Installs:** 0
- **Category:** [Web & Browser](https://agentstack.voostack.com/c/web-and-browser)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [akovalion](https://github.com/akovalion)
- **Source:** https://github.com/akovalion/paranoid-qa/tree/main/skills/testing

## Install

```sh
agentstack add skill-akovalion-paranoid-qa-testing
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

Master checklist "how to test anything" — frontend/UI and backend/services. Doctrine:
- **Meticulousness by default.** Cover everything yourself: happy path → negative → boundaries → rare combinations. Depth scales with risk, but never skip check classes.
- **Evidence discipline.** Pass/Fail is set ONLY from an observed artifact (screenshot, network response, log, DB dump). Didn't check — `Not tested`; couldn't — `Blocked` with a reason. No hallucinations and no "should work by logic".
- **Log every deviation immediately.** Record any mismatch with the design (Figma)/requirements at once, even a minor one (spacing, copy, color).
- **The goal is to replace manual testing.** Reliability over speed; "ran out of time / couldn't" is stated plainly.

---

## 0. Process (for any task)

**Context gathering**
- Read the ticket in full: description, AC/Gherkin, comments, attachments, linked issues (blocks/relates/epic), component, release.
- Pin the source of truth for each requirement (AC → spec/Confluence → Figma → production behavior) and the precedence on conflict.
- Check Figma: version, mode (desktop/mobile/adaptive), states (default/hover/focus/active/disabled/loading/error/empty), component variants, tokens; what is in the design vs what is "implied".
- Find existing test cases (in your TMS — Zephyr/TestRail/other) and autotests (in the project's autotest repository): reuse, identify gaps, don't duplicate.
- Capture a production/preprod baseline (how the feature works now — for regression and reproducing bugs on the current version).
- Clarify the environment: environment instance, access, test accounts/roles, feature flags, data state, build version/commit.
- Identify integrations and dependencies: external APIs, payment providers, auth, queues — what is mocked, what is real.
- Explicitly record out of scope (native apps, unsupported browsers, legacy flows).

**Requirements analysis and questions for the analyst**
- Every AC → a check; every check → a link to an AC or an explicit "extra heuristic" note.
- Surface ambiguities ("should work correctly", no concrete values, unspecified boundaries, undefined error behavior).
- Mismatches ticket ↔ Figma ↔ production ↔ docs — do NOT close with an assumption, write them up as questions.
- Record undefined behavior: empty states, network/server errors, timeouts, integration failure, concurrent actions, expired session.
- Clarify: validations (required fields, formats, masks, lengths, allowed characters, client vs server, error texts); permissions/roles (who sees/can, unauthenticated, missing permission); locale/formats (language, date/time/currency/numbers, TZ, text direction).
- All questions — as a list marked blocking/non-blocking; close blocking ones before starting.

**Prioritization and risk**
- Risk per area = defect probability × impact (money, security, data, reputation, usage frequency).
- Focus on changed code and its blast radius, not a uniform spread.
- Decide: what to automate (stable, regression-prone) vs manual checking (exploration, UX, one-off, visual).
- Carve out a smoke subset (critical for a quick build check) and a regress subset.
- Under a deadline, agree on depth explicitly, don't cut it silently.

**Plan / coverage matrix**
- Scope: what is in/out, on which environments/browsers/viewports.
- Matrix: browsers (Chromium/WebKit/Firefox) × viewports × roles × data states.
- Check classes: functional (happy/negative/boundary), UI/layout/responsive layout, validations, navigation/routing/deeplink, states (loading/empty/error/success), permissions/roles, integrations/API, data/persistence; non-functional (perf, security) where relevant.
- For each item: precondition → action → expected result → link to AC/source.
- Test data: valid/invalid/boundary, special characters, long strings, empty values, different roles/account states.
- Agree on exit criteria and report format BEFORE execution.

**Execution (evidence-based)**
- **Run scale.** Execute a large task (long multi-step flow, full screen regress, production/test comparison, release E2E) via fan-out (`references/fan-out.md`): the orchestrator drives the browser sequentially and collects artifacts, then parallel subagents (`Agent`) analyze them per axis, synthesis merges the findings. A small one (single page, smoke, one bug) — as a linear pass.
- Reproduce step by step; for each result — an observable artifact (screenshot, video, network response, console, DOM/DB dump).
- Distinguish: "works as expected" / "bug" / "question to requirements" / "not reproducible" — don't lump them together.
- Check not only the UI but also the network (status codes, payload, 4xx/5xx handling, retries, no sensitive data) and persistence (reload, re-login).
- Keep the console open for the whole run: JS errors/warnings, resource 404s, CSP/CORS.
- Verify post-action state in several layers: UI ↔ network ↔ DB/storage.
- Isolate the defect: minimal steps, frequency (always/intermittent), environment, build, preconditions; if flaky — repeat N times, record the frequency, don't mask it with a retry without understanding the cause.
- **Real input vs programmatic input.** Setting values programmatically (`fill()`, `setInputValue`, `.value=`, or an automation "type" that wraps them) may bypass the app's own event pipeline — framework `onChange`/`onBlur`, custom searchable/select components that commit only on option-click. The visible field shows text while the bound state stays empty → a false "required"/validation error (or, conversely, it masks a real one). Confirm any required/validation/selection finding with real user input (click the option, type character-by-character / `pressSequentially`, keyboard) before setting Pass/Fail. If the result depends on how the value was entered, it is not yet evidence.
- **Action map (page map) — don't re-learn the page.** The first pass over a screen is discovery; capture everything found (working selectors, order of custom controls, API endpoints, DOM quirks, the stand's console-noise baseline) into a run/project note right away. Run every subsequent check on that screen from the map with no re-discovery; wrap repeated flows (reaching step N of a wizard) into a helper script invoked as a single action. At the start of a new run, re-verify 1–2 key selectors from the map against the live page — they may have gone stale.
- **Browser tooling.** Interactive steps — via an MCP browser (Playwright / Chrome DevTools MCP). Repeated flows and page-map helper scripts — via `playwright-cli` (separate processes/profiles; scales to parallel agents, §7.8). Cross-browser: run critical scenarios (layout, scrolling, date pickers, focus/hover, file inputs) in at least two engines — Chromium + WebKit (a playwright-webkit MCP server or `playwright-cli --browser webkit`; iOS emulation when available): a sizable share of UI bugs is engine-specific and invisible in Chromium alone.
- **A workaround ≠ passing the step.** If the TC's target action cannot be performed the standard user way (click/tap/typing), that is a Fail (defect) or Blocked — even when a technical workaround exists (`focus()`, native setter, direct API call). A workaround is only allowed to unblock DOWNSTREAM checks, and it is stated explicitly in the report; the blocked step itself is never turned "green" via a workaround.

**Recording / DoD**
- Every test case with a status + evidence: Pass (artifact), Fail (bug + artifact), Blocked (reason), Not tested (why). Blocked ≠ Fail.
- Record results in the TMS strictly per the team's convention (comments, environment, attachments) — don't invent your own; evidence is kept in the run artifacts and the summary report regardless.
- Defects filed, linked to the ticket, severity/priority set, steps and artifacts attached.
- Coverage reconciled with AC: every AC covered by ≥1 check; uncovered ones — explicit with a reason.
- Run recorded: environment, build/commit, browsers/viewports, date, executor.
- Regression of affected areas done (or deliberately deferred with the risk recorded); blockers escalated; questions linked.
- New/updated test cases entered into the TMS; automation candidates flagged.
- **Done** = all non-blocked ACs checked with evidence, bugs filed, report and test case statuses up to date, residual risks and uncovered items listed honestly.

---

## 1. Test design techniques

**Equivalence partitioning (EP)** — split input into classes (valid/invalid/special: empty, null, whitespace). One representative from each valid class; EVERY invalid class separately (different messages = different classes). Numbers: negative/0/positive/fractional/over the limit. Strings: Latin/Cyrillic/digits/special characters/emoji/RTL/case. Enumerations: each option + out-of-list. Files: allowed/forbidden/empty/corrupted. Dates: past/present/future/invalid format/nonexistent (Feb 31).

**Boundary value analysis (BVA) — exact boundaries ±1.** For [min..max] check exactly: min−1, min, min+1, max−1, max, max+1 (not "small/large"). String length: 0, 1, min±1, max±1. Boundary at 0: −1, 0, 1 (counters, balances, cart). Money: 0.00, min payment, min−0.01, max, max+0.01, cent rounding. Date/time: 23:59:59→00:00:00, last day of month, Feb 29 leap/non-leap, crossing midnight/year. Pagination: 0 items, exactly one page, page+1 items, last partial page. Age/term: exactly 18 (to the day), ±1 day, expiry exactly at the moment.

**Decision tables** — for business rules with condition combinations. Conditions × rules × expected action; cover every significant combination (not all 2^n); include impossible/contradictory ones (system rejects). Apply to: discounts/tariffs/calculations, feature access (role × flag × subscription × state), submit availability (field A × field B × checkbox), mutually exclusive conditions.

**State transitions (STT)** — for an entity with a lifecycle (draft→moderation→published→archived→deleted). Check every allowed transition and EVERY forbidden one (event in an invalid state → blocked). Transitions by timeout/system event (auto-cancel, session expiry); actions invalid in the current state (edit a published item, pay a canceled one); cycles/returns; state after interruption; concurrent transitions by two users.

**Pairwise / combinatorics** — when there are >3 parameters and full enumeration is unrealistic (OS × browser × role × language × theme). Generate a set covering all pairs (PICT/allpairspy); manually add critical business combinations pairwise may miss; check the defaults of each parameter.

**Error guessing** — for mature/legacy functionality via weak spots: double/triple click, submit before validation completes, special characters/injections, very long input (10k+), pasting large text, whitespace/zero-width, emoji, autofill, slow network, Back after success, F5 on an intermediate step, editing the payload in DevTools bypassing the UI, action with an expired token.

**Additionally:** cause-effect analysis (AND/OR/NOT between conditions, cascading/dependent fields); a CRUD matrix as the base skeleton for any entity; an access matrix (role × action × resource) + server-side enforcement check. **Always:** positive (valid classes, allowed transitions) + negative (invalid classes, forbidden transitions, UI bypass).

**Technique selection:** range/limit → BVA+EP; many parameters → pairwise; condition combinations → decision table; lifecycle → STT; dependent conditions → cause-effect; entity with data → CRUD; legacy → error guessing.

---

## 2. References (`references/`) — mandatory reading per task type

Detailed checklists live in `references/`. **Before drafting the plan, read (Read) each file relevant to the task in full** — not selectively and not from memory; a plan made without reading the reference counts as incomplete.

| File | When to read | What's inside |
|---|---|---|
| `references/frontend.md` | Any task with UI | Fields/forms (masks, limits, paste/autofill), visuals and all element states, Figma comparison, tokens, overflow, responsive layout and cross-browser (canonical resolutions) |
| `references/backend.md` | API / services / DB / integrations | HTTP methods and codes, schemas/contracts, pagination, idempotency, PATCH, DB (integrity, transactions, concurrency, migrations), AuthN/AuthZ/IDOR/multi-tenancy, queues/webhooks/cron, load and resilience, OWASP API Top 10 |
| `references/cross-cutting.md` | Almost always (frontend and backend together) | Network errors and mocks, UI↔Backend consistency, sessions/storage/multi-tab, navigation/deeplink, time/TZ/i18n, perf and console, security from the frontend, files/export, search/filters, payments, analytics |
| `references/artifacts.md` | Before recording results and bugs | Evidence, HAR/console, bug report structure, severity vs priority, deviations from the design, tracker/TMS, run summary report |
| `references/common-misses.md` | Always — before the final report | "Common misses" checklist: final self-check of run completeness |
| `references/fan-out.md` | Large run: long flow, full screen regress, production/test comparison | How to split a meticulous run across parallel subagents per axis: orchestrator collects artifacts → fan-out → synthesis. About the execution method, not a check class |

Minimal sets: UI task → frontend + cross-cutting (+artifacts when filing bugs); API/backend → backend + cross-cutting; full E2E/release → all. Large run / long flow → additionally `fan-out.md` at the execution stage. `common-misses.md` — always last, before producing the report.

---

> Apply the technique and track by task context. For each real task, check against its requirements and designs, not against this list as the truth — the list reminds you of check classes but does not replace AC and the source of truth.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [akovalion](https://github.com/akovalion)
- **Source:** [akovalion/paranoid-qa](https://github.com/akovalion/paranoid-qa)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-akovalion-paranoid-qa-testing
- Seller: https://agentstack.voostack.com/s/akovalion
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.