/testing

name: testing
description: 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.
allowed-tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
  - Agent

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. Don't trust TMS statuses blindly — cross-check against the live tests: "Automated" with no existing autotest and "needs automation" on long-covered cases both happen.
• 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.
• When the scope is a specific spec: Pass/Fail verdicts only against its items; findings outside the spec go into a separate "out of scope" block (observation/question) — not a Fail and not a defect of the task.
• 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.
• **RUN SIZE IS ESTIMATED BEFORE YOU START, AND THE EXECUTION METHOD IS AGREED WITH THE USER.** Before starting, count the volume: how many test cases, how many steps, how many viewports/browsers. If the size warrants fan-out (rule of thumb: >10 cases, full screen regress, long E2E) — **propose it to the user explicitly** and name the alternative with an estimate. A ban on launching subagents on your own does not ban PROPOSING them: the decision is the user's, and asking costs ten seconds. Silently defaulting to a linear pass and running out of context halfway is a planning failure — the run stalls unfinished and the user only learns about it after the fact. The same principle applies to any constraint that can derail the task midway (no test data, the environment is down, an integration is unavailable, access is missing) — raise it at the start, not when you hit the wall.
• **A linear pass is also