/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.
• **Open and read every attachment, don't just note it by file name.** docx/pdf/xlsx - extract the text (unzip + XML, pdftotext, openpyxl), images - look at them. Wiki/spec pages linked from the ticket - together with their attachments and the pages they link to (parameter definitions, glossaries).
• **List the sources you actually read in your first reply** ("ticket, 2 comments, 2 docx, spec page + 2 screenshots, 2 linked pages"). Anything that failed to open or wasn't read - say so right away with the reason, not after the user asks "did you even look at the files?".
• Pin the source of truth for each requirement (AC → spec/Confluence → Figma → production behavior) and the precedence on conflict.
• **Migration to a new stack (frontend rewrite, framework change) - production is the only reference.** Rendering and behavior must match production; a mockup or old test-case ERs that diverge from production are not the reference. Matches production - Pass, even if the test case says otherwise (update the case afterwards); differs - a defect of the task; a difference "for the better" - a separate line for the user to decide, not a defect. Compare in pairs: same widths, same data and states in production and on the test environment.
• 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.
• **Pick run axes from the change's diff, not from habit.** Before the run, open the task's diff (commits, MR) and choose the axes from it. Safari - if the change touches what engines render differently: flex/gap, sticky, `@font-face` and font formats, `100vh`, scrolling and scroll-lock, date pickers and date inputs, focus/hover, file inputs, `backdrop-filter`; several mobile widths - if it touches media queries or layout, otherwise one is enough; a single-property fix - the fix itself plus its neighbors, no full regress. Thoroughness applies to the classes of checks per AC, not to multiplying environments. The converse holds too: a large feature is walked through a checklist covering every block of the page, and "done" is said only after that.
• 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