Sprint Testing

Forbidden invocations

NEVER invoke /sdd-* skills from this workflow. SDD is an optional user-installed ceremony; this skill ships self-contained and does not chain SDD under any condition. If you need to refactor KATA, fixtures, cli/, scripts/, or api/schemas/ pipeline, exit this skill first and invoke /framework-development — which itself runs Plan → Code → Verify → Archive natively (no SDD required).

This boundary is mechanical, not advisory: scripts/lint-skills.ts rejects any /sdd- mention outside this section. See: .claude/skills/agentic-qa-core/references/skill-composition-strategy.md §4 (governs users who manually install SDD).

Sprint Testing — Plan, Execute, Report per Ticket

Drive the manual / exploratory QA loop for a single ticket during a sprint. Three stages, always in this order: Stage 1 Planning -> Stage 2 Execution -> Stage 3 Reporting. Hand off afterwards to the skills that own Stage 4, 5 and 6.

The same three-stage pipeline runs in every mode. Only the entry point and the bookkeeping differ: one ticket at a time (single-ticket), or N tickets managed by a framework file (batch-sprint).

---

Dependencies

Requires agentic-qa-core. Loads on demand:

• agentic-qa-core/references/test-design-doctrine.md — MANDATORY before designing any ATP / TC coverage from acceptance criteria. Governs the 5 principles, the floor-not-ceiling coverage model, the 1:N explode-default rule, and the formal-technique triggers.
• agentic-qa-core/references/defect-management-doctrine.md — MANDATORY before taking a Story into testing and before filing any Bug / Defect / Improvement. Governs issue-type classification (Bug vs Defect vs Improvement by feature lifecycle), the QA-Assignee self-assign + never-overwrite rule, mandatory Components, the three-axis model (parent = QA process epic · link = source Story · components = product module), and Severity→Priority auto-derive.
• agentic-qa-core/references/briefing-template.md, ./dispatch-patterns.md, ./orchestration-doctrine.md, ./session-management.md, ./preflight-gate.md, ./adr-doctrine.md — cited inline by the sections that use them.

Compact Rules

Test-design doctrine (binding — full canon: agentic-qa-core/references/test-design-doctrine.md):

• AC-pass is the FLOOR, not the goal. Coverage = AC-conformance + risk-beyond-AC (boundaries, errors, states, anomalies). Never report "% of ACs verified" as completeness.
• 1:N is the default: explode every non-trivial AC into multiple cases (EP partitions + boundaries + states + contexts). Collapsing an AC to one case requires a written "trivially atomic" justification.
• Apply techniques by trigger: EP always; BVA wherever a range / limit / length / date-window exists; State-Transition for stateful entities; Decision Table when 2+ conditions interact; Pairwise when 3+ combinable factors (log the reduction); Error-Guessing charters for experience-based risk.
• A criterion is a business assertion; a test case is a concrete exploration of it. Run the Test-Design Checklist before finalizing the ATP.

Defect-management doctrine (binding — full canon: agentic-qa-core/references/defect-management-doctrine.md):

• CLASSIFY before filing — stop hardcoding "Bug". Bug = affected feature already live above Staging (end-user visible); Defect = feature still pre-release (Staging or below), the normal output of sprint testing; Improvement = not a broken AC (an enhancement, or an under-specified/absent AC surfaced by a test-beyond-AC). Classification follows the FEATURE's lifecycle stage, not where the problem was found (Part 1).
• qa_assignee ({{jira.qa_assignee}}) = the authenticated session user (self-assign). Set it when a Story is TAKEN INTO TESTING (start_testing) and on every filed Bug / Defect / Improvement. NEVER-OVERWRITE an existing owner (read-before-write); distinct from the native dev assignee (Part 2).
• components (native, MANDATORY) = the affected product module/Epic, must pre-exist in the Jira Components module (Part 3).
• Three-axis model: parent = QA Defect Management process epic (qa.qa_epics.defect_epic, found-or-created — NEVER a product/dev epic, NEVER the Story); issue link = the source Story (traceability); components = product module (Part 4).
• priority (native) is auto-derived from {{jira.severity}} (critica→Highest, mayor→High, moderada→Medium, menor→Low, trivial→Lowest); override with a 1-line justification (Part 5.1).

Sprint-testing operational rules:

• Three stages, always in order: Stage 1 Planning → Stage 2 Execution → Stage 3 Reporting. Hand off Stages 4/5/6 to test-documentation / test-automation / regression-testing.
• Jira is source of truth. Read tickets via bun run jira:sync-issues get --include-comments, then the synced .md. NEVER acli workitem view for custom fields (returns null).
• Bugs run the veto + triage + risk-score decision tree BEFORE any ATP is written.
• Execution = smoke pass first, then trifuerza (UI/API/DB) exploration; capture evidence under the PBI folder.
• Consult domain-glossary.md (if present) before authoring the ATP, refined ACs, and TC outlines.
• On any subagent failure: STOP, report partial state, offer retry / skip-stage / abort. No auto-fix, no auto-rollback.

Read full SKILL.md when: starting a sprint cold, resuming a session, or handling a bug-triage / batch-sprint flow not covered by the rules above.

---

Inputs — read these first, in this order

Canonical reading order for any AI starting cold on a sprint-testing workflow. Read in order; stop earlier when the ticket is small enough that later inputs add no signal.

1. .agents/project.yaml — project identity, env URLs, {{PROJECT_KEY}}, MCP names, active environment.
2. .agents/jira-required.yaml — canonical slug catalog (custom fields, statuses, transitions) for the active workspace.
3. .agents/jira-fields.json — slug → numeric custom-field-ID mapping for {{jira.}} resolution at runtime.
4. .agents/jira-workflows.json — workflow + transition catalog (resolves Ready For QA → In Testing → Tested for Story / Bug / Test Case work types).
5. .context/PBI/epics/EPIC--/stories/STORY--/context.md — ticket-local context: session notes, open questions (hand-authored; read if it already exists from a prior Session Start). NON-Jira file — never a Jira mirror.
6. .context/master-test-plan.md — regression Epic pointer, modality decision (Xray vs Jira-native), what to test and why.
7. .context/business/business-feature-map.md — feature catalog vocabulary; resolves "what epic owns this story" for the epics/EPIC--/ PBI folder naming (module = Epic, 1:1).
8. .context/business/domain-glossary.md (if present) — canonical domain vocabulary; consult BEFORE authoring the ATP, refined ACs, and TC outlines so test names, entity terms, and Gherkin wording use canonical terms and avoid anti-glossary banned terms. If a new or ambiguous term surfaces during testing, flag it in the Stage 3 QA comment for the PM to add via the glossary's change protocol — NEVER edit the glossary from a testing session.
9. The Story or Bug ticket itself — AC, ATP, comments — read via bun run jira:sync-issues get --include-comments, then read the synced .md files (story.md, acceptance-criteria.md, acceptance-test-plan.md, comments.md) under the STORY folder. Jira is source-of-truth; the synced .md is a read-only cache. NEVER acli workitem view for custom fields — it returns null.
10. .env — LOCAL_USER_* / STAGING_USER_* credentials. NEVER hardcode; always read at runtime.
11. kata-manifest.json — registry of existing KATA Components + ATCs. Check before proposing new ATCs in Stage 3 hand-off so the test-automation phase doesn't duplicate work.

Optional inputs. master-test-plan.md, the business maps, and domain-glossary.md frequently arrive after /project-discovery runs and may be absent — proceed without them and surface a missing_input note in the Stage 1 ATP so a later pass can fill the gap. kata-manifest.json is only load-bearing at the Stage 3 → test-automation hand-off; skip in pure manual-QA invocations.

---

Subagent Dispatch Strategy

> Orchestration & Session contracts: this skill follows ./orchestration-doctrine.md (mandatory subagent dispatch — main thread is command center) AND ./session-management.md (Phase 0 resume check, plan-first persistence at .session///, archive on completion). Phase 0 (resume check) and Phase 1 (plan write) are NOT optional. The orchestrator also applies the per-stage Definition-of-Done gates in ./stage-gates.md: verify a stage's DoD (planning stages include the Test-Design Checklist) BEFORE recording its progress checkpoint and advancing.

This skill scopes per ticket. Single-ticket mode: ` = (e.g. UPEX-123). Batch-sprint mode: = sprint-/ (one nested directory per ticket in the wave). Session state lives at .session/sprint-testing//{plan.md, progress.md} per agentic-qa-core/references/session-management.md §3 + §9. The per-ticket test-session-memory.md is a SEPARATE concern: it carries TMS modality + ticket context + stage state shared across the 4 sub-agent dispatches (domain memory). Both files coexist — plan.md indexes the session; test-session-memory.md` holds the cross-stage shared payload.

This skill is compliant with the doctrine in CLAUDE.md §"Orchestration Mode (Subagent Strategy)" and the session contract in .claude/skills/agentic-qa-core/references/session-management.md. Every dispatch follows the 6-component briefing format defined in .claude/skills/agentic-qa-core/references/briefing-template.md, and the pattern selected per stage matches the decision guide in .claude/skills/agentic-qa-core/references/dispatch-patterns.md. This skill operates in two modes (single-ticket and batch-sprint) and BOTH modes use the same four dispatch points per ticket — Session Start -> Stage 1 -> Stage 2 -> Stage 3. The only difference is that batch mode loops them once per ticket. The full briefings (Goal / Context docs / Skills to load / Exact instructions / Report format / Rules) live in references/sprint-orchestration.md §"Sub-agent prompt templates".

| Stage | Pattern | Subagent role | |----------------------------------------------------|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Session Start (per-ticket) | Single | dispatch a session-start subagent: fetch ticket from issue tracker, load .context/, create the PBI folder + context.md + test-session-memory.md, return ticket summary + AC list | | Stage 1 — Planning (ATP + draft TCs + risk triage) | Sequential | dispatch a Planning subagent: produce the ATP artifact + risk score + draft TC outlines; bug tickets get the veto + triage decision tree applied | | Stage 2 — Execution (smoke + UI/API/DB exploration)| Sequential | dispatch an Execution subagent: smoke pass first, then triforce (UI/API/DB) exploration; capture evidence under the PBI folder; surface BUG_FOUND if applicable | | Stage 3 — Reporting (ATR + QA comment + transition)| Sequential | dispatch a Reporting subagent: fill the ATR, post the QA comment, transition the issue, file bug reports if any |

> Modes are equivalent in dispatch shape. Single-ticket mode runs ONE pass through these four dispatches. Batch mode loops them per ticket. There is no longer a "single-ticket inline" path — both modes pay the same 4-dispatch cost so behavior is uniform and reviews are consistent.

> Sequential, not Parallel: each stage feeds the next (Session Start's PBI folder is read by Stage 1; Stage 1's ATP is read by Stage 2; Stage 2's evidences are read by Stage 3). Parallelism inside a single ticket would race on shared PBI state.

> On any subagent failure: STOP, report the partial state (which stages completed, what artifacts landed), present retry / skip-stage / abort options. Do NOT auto-fix nor auto-rollback. See .claude/skills/agentic-qa-core/references/orchestration-doctrine.md.

---

Scope — pick the mode first

| Mode | Input | Output | Use when | |------|-------|--------|----------| | Single ticket — User Story | One story ID (e.g. {{PROJECT_KEY}}-123) | ATP + ATR + QA comment + ticket moved to {{jira.status.story.qa_approved}}. TC artifacts depend on modality: jira-native → outlines only (regression TCs created in Stage 4); jira-xray → created + executed Tests this sprint, promoted to regression in Stage 4 (see "TC creation timing") | Full QA on one story end to end | | Single ticket — Bug | One bug ID | Triage decision, then either Code-Review-only OR ATP + ATR + verification report | Retesting a bug fix on staging | | Batch sprint | SPRINT-{N}-TESTING.md framework file | Per-ticket artifacts + updated framework file + session summary | Processing a whole sprint backlog, with interruption + resume support |

Rules for picking:

1. Story ID with status Ready-for-QA -> Single ticket / User Story.
2. Bug ID deployed to staging -> Single ticket / Bug.
3. Sprint number, "process sprint X", or an existing SPRINT-{N}-TESTING.md -> Batch sprint.
4. If the framework file does not exist yet, generate it first (see sprint-orchestration.md).

---

Workflow — one pipeline for all modes

Session Start (always first)
    -> PBI folder + context.md + test-session-memory.md
    -> Story explanation, WAIT for user OK

Stage 1 — Planning
    -> For Story: triage risk + Test Analysis + ATP/ATR + TC OUTLINES (names + 1-line precond/expected)
                  jira-native -> NO `Test` work items here (created in Stage 4, regression-worthy only)
                  jira-xray   -> CREATE + EXECUTE `Test` issues for the planned outlines at executable
                                 detail, run via a Test Execution (Xray plugin design). Stage 4 promotes
                                 the regression-worthy ones into the Regression Test Plan.
    -> For Bug:   veto check + Bug Analysis + ATP/ATR (no TCs in-sprint — the bug IS the immediate
                  retest case). If regression-worthy, Stage 4 ensures a persistent Test covers it —
                  REUSE the existing failed Test or CREATE one (golden rule; both modalities).
    -> See references/acceptance-test-planning.md and references/feature-test-planning.md
    -> TC work-item timing rule -> see "TC creation timing (modality-aware)" below

Stage 2 — Execution
    -> Smoke test is always first (Go / No-Go)
    -> Then UI / API / DB exploration per what changed
    -> Evidence into .context/PBI/epics/EPIC--/stories/STORY--/evidence/
    -> See references/exploration-patterns.md

Stage 3 — Reporting
    -> Fill ATR, post QA comment, transition ticket
    -> File bugs via bug-report template when found
    -> See references/reporting-templates.md

---> Hand off (cross-skill, NOT this skill):
       Stage 4 -> test-documentation
       Stage 5 -> test-automation

### TC creation timing (modality-aware) — AUTHORITATIVE

> Resolves the one question that decides this skill's whole shape: *when does a test case become a work item in the TMS?* Guiding principle: **a test is persisted into the REGRESSION repository because it will be re-executed (manual or automated), never to hit a count.** The mechanism differs by modality because the TMS tools differ — an Xray `Test` issue is an **execution unit**, a Jira-native `Test` issue is **documentation**.

**Key distinction:** an **execution arti

…

## Source & license

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

- **Author:** [upex-galaxy](https://github.com/upex-galaxy)
- **Source:** [upex-galaxy/agentic-qa-boilerplate](https://github.com/upex-galaxy/agentic-qa-boilerplate)
- **License:** MIT

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