[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71Q4BDPCCDJP7RVEYGCARVZ":3,"skill-same:01M71Q4BDPCCDJP7RVEYGCARVZ":88},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M71Q4BDPCCDJP7RVEYGCARVZ","test-planning",null,"Build a single sprint or release test plan. Covers feature decomposition into testable scenarios, requirements-to-test coverage mapping, effort estimation by test type, prioritization matrices (risk × effort), resource allocation, and scheduling with buffers. Use when: \"sprint test plan,\" \"release test plan,\" \"what to test this sprint,\" \"test estimation,\" \"coverage mapping.\" Not for: multi-quarter strategy — use `test-strategy`. Not for: ranking areas by risk — use `risk-based-testing`. Not for: the go\u002Fno-go decision itself — use `release-readiness`. Related: test-strategy, risk-based-testing, release-readiness.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-planning\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"planning","test","test planning","mapping","go","allocation","release","test coverage","decomposition","plan","prioritization","when","estimation","ranking","decision","testing","resource allocation","effort estimation","sprint","coverage","2026-11-10 13:02:02",false,"---\nname: test-planning\ndescription: >-\n  Build a single sprint or release test plan. Covers feature decomposition into\n  testable scenarios, requirements-to-test coverage mapping, effort estimation by\n  test type, prioritization matrices (risk × effort), resource allocation, and\n  scheduling with buffers. Use when: \"sprint test plan,\" \"release test plan,\"\n  \"what to test this sprint,\" \"test estimation,\" \"coverage mapping.\" Not for:\n  multi-quarter strategy — use `test-strategy`. Not for: ranking areas by risk —\n  use `risk-based-testing`. Not for: the go\u002Fno-go decision itself — use\n  `release-readiness`.\n  Related: test-strategy, risk-based-testing, release-readiness.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: strategy\n---\n\n\u003Cobjective>\nCreate actionable test plans for sprints and releases. A test plan answers four questions: what to test, how deeply, who does it, and when it must be done. The output is a living document that tracks progress, not a bureaucratic artifact filed and forgotten. A plan that schedules 100% of available time fails the moment the first bug is found — buffer and prioritization are what make it survive contact with reality.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Plan a single sprint | Steps 1-6 below, then the 1-page sprint template in `references\u002Fplan-documents.md` |\n| Plan a release | Release template in `references\u002Fplan-documents.md`; the go\u002Fno-go decision itself belongs to `release-readiness` |\n| Track an in-flight plan \u002F feed results back | `references\u002Ftracking-formats.md` (daily status + retrospective) |\n| Decide what to cut when over capacity | Step 4 prioritization matrix |\n\n---\n\n## Discovery Questions\n\nBefore writing a test plan, gather context. Check `.agents\u002Fqa-project-context.md` first -- if it exists, use it as the foundation and skip questions already answered there.\n\n### Scope\n\n- What is the scope? (single sprint, release, hotfix, feature)\n- Which features are new vs. changed vs. unchanged?\n- Which features are being released for the first time?\n- Are there infrastructure or dependency changes (database migrations, API version bumps, third-party provider switches)?\n- Is there a requirements document, PRD, or set of user stories to map against?\n\n### Time and Resources\n\n- What is the testing window? (days, hours available)\n- Who is available for testing? (SDETs, manual testers, developers)\n- Are there shared resources that could bottleneck? (staging environments, test accounts, devices)\n- Is there a hard deadline that cannot move, or is the release date flexible?\n\n### Risk Context\n\n- Which areas changed the most in this cycle?\n- What broke in the last release or sprint?\n- Are there known fragile areas or tech debt that increase risk?\n- For risk-based prioritization methodology, see `risk-based-testing`.\n\n### Existing Coverage\n\n- What automated tests already exist for the in-scope features?\n- What is the current pass rate of the automated suite?\n- Are there known gaps in automation that require manual testing?\n- When was the last exploratory testing session on these features?\n\n---\n\n## Core Principles\n\n### 1. Coverage-Driven: Map Every Requirement to at Least One Test\n\nA test plan without traceability to requirements is a guess. Every user story, acceptance criterion, or requirement must map to at least one test case. Gaps in this mapping are untested requirements -- the most dangerous kind of risk.\n\n### 2. Time-Boxed: Plan Fits the Available Window\n\nTesting expands to fill available time if unbounded. Set a time box for each activity and stick to it. When the window is too short, the prioritization matrix determines what gets cut -- not gut feeling.\n\n### 3. Prioritized: Not Everything Gets Equal Depth\n\nA payment flow change and a tooltip fix do not deserve equal effort. Use the risk x effort matrix to allocate depth: some features get full regression, others a smoke test, some nothing if low-risk and unchanged.\n\n### 4. Buffered: Leave Room for the Unexpected\n\nPlans that schedule 100% of available time fail when bugs are found. Allocate only 70-80% of the testing window to planned work and explicitly reserve the remaining 20-30% for bug verification, re-testing, and unplanned investigation. If buffer is not a named line in the plan, you do not have one.\n\n### 5. Visible: The Plan Is a Communication Tool\n\nDevelopers need to know what gets tested to write testable code. Product managers need coverage visibility to make release decisions. Publish the plan where the team can see it.\n\n### 6. Entry and Exit Criteria Are First-Class\n\nThe most-reused part of any plan is its gate. Make it explicit, not buried: **entry** = code-complete on staging + existing suite green + test data seeded; **exit** = every HIGH-risk area covered + no open P0\u002FP1 + zero unexplained GAP rows in the coverage matrix. Everything else is detail around these two checkpoints.\n\n---\n\n## Workflow\n\nThe six workflow steps each have a fill-in-the-blank scaffold. The decision prose stays here; the copy-paste templates (decomposition, coverage matrix, estimation worksheet, prioritization matrix, allocation table, schedule) live in `references\u002Fworkflow-templates.md`.\n\n### Step 1: Feature Analysis and Decomposition\n\nBreak each in-scope feature into testable units. A \"testable unit\" is a specific behavior that can be verified with a clear pass\u002Ffail outcome. Walk every feature against these scenario categories so none gets skipped:\n\n- **Happy path** — the primary success flow.\n- **Validation** — required fields empty, format violations, boundary values.\n- **Error conditions** — server 5xx, network timeout, rejected input.\n- **Edge cases** — unicode, oversized payloads, unsupported formats.\n- **Concurrency \u002F race conditions** — two users edit the same record simultaneously, double-submit, retry-after-timeout. These hide the worst data-corruption bugs and are the category most often missed.\n- **Integration points** — behavior across each boundary the feature crosses.\n\nSee `references\u002Fworkflow-templates.md` for the decomposition template and a worked \"User Profile Edit\" example that exercises all six categories.\n\n> **AI decomposition cross-check.** When an agent decomposes features, have it immediately map its own scenarios back against the Step 2 coverage matrix. Any requirement with no scenario, or any scenario category above with no entry, is a decomposition gap the agent must surface before estimation — this is how you catch the agent's blind spots, not after CI does.\n\n### Step 2: Requirements-to-Test Coverage Mapping\n\nCreate a traceability matrix that maps every requirement to its test cases. See `references\u002Fworkflow-templates.md` for the coverage matrix template.\n\nRules for the coverage matrix:\n- Every requirement must appear in the matrix (target: 100% mapping)\n- \"GAP\" status triggers a decision: write a test, accept the risk, or defer\n- Automated tests get test IDs that link to the actual test file\u002Ffunction\n- Manual tests reference the test case document or charter\n\n### Step 3: Effort Estimation\n\nEstimate effort for each test type using historical data. If no historical data exists, use the reference estimates below and calibrate after the first sprint.\n\n**Estimation reference (per test case):**\n\n| Test Type | Write Time | Execute Time | Maintenance (per quarter) |\n|-----------|-----------|-------------|--------------------------|\n| Unit test | 0.5 hr | \u003C 1 sec | 5 min |\n| Integration test | 1 hr | 5-30 sec | 15 min |\n| E2E test (Playwright\u002FCypress) | 2-3 hours | 30s-2 min | 30 min |\n| Manual test case (write) | 0.25 hr | 5-15 min per execution | 10 min |\n| Exploratory session (charter) | 15 min | 1.5 hrs per session | N\u002FA |\n| Accessibility review (manual) | 0.5-1 hr per area | included in write | 15 min |\n| Visual regression test | 30-60 min | 10-30 sec | 20 min (baseline updates) |\n| Performance test (k6 script) | 2-4 hours | 5-30 min per run | 30 min |\n| Prompt regression \u002F LLM eval | 30-60 min per case | 30 sec - 2 min (with API cost) | 20 min |\n| Setup & test data (per feature) | 0.5-2 hrs | one-time | re-seed per env |\n\nWrite Time is authoring only. The \"Setup & test data\" row is the line planners most often omit — environment, fixtures, and mock configuration routinely run 20-40% of total effort, so budget it as a real line rather than discovering it mid-sprint.\n\n> **AI authoring trade-off.** Using an agent to author tests cuts *Write Time* by roughly 40-60%, but add a *Review Time* line of similar size per case — Bolton's \"AI productivity paradox\" (2026) is that the speed-up evaporates when an agent ships plausible-but-broken tests that pass a casual review and fail in CI. See `ai-test-generation` Step 7 for the review checklist and `ai-qa-review` for the smell taxonomy.\n\n> **Test-smells review.** ISTQB's CTAL-AT v2.0 (May 2026) names test smells as a planning concern. Budget a recurring 30-min \"test-smells review\" per sprint against the taxonomy in `ai-qa-review` — cheap, and it finds maintenance debt before it compounds.\n\nUse the sprint estimation worksheet in `references\u002Fworkflow-templates.md` to roll per-case estimates up to a capacity-utilization figure (target: 70-80%, leaving 20-30% buffer).\n\n### Step 4: Prioritization Matrix (Risk x Effort)\n\nWhen the estimated effort exceeds available capacity (it usually does), use the risk x effort matrix to decide what to cut. See `references\u002Fworkflow-templates.md` for the full matrix grid.\n\nFor each test case, plot it on the matrix using the risk score from `risk-based-testing` and the effort estimate from Step 3, then consume capacity in priority order: **DO FIRST → DO SECOND → DO THIRD → DEFER → SKIP**.\n\n**Tie-break rule:** within HIGH risk, low-effort beats high-effort — a HIGH-risk \u002F low-effort test (DO FIRST) outranks a HIGH-risk \u002F high-effort test (DO THIRD), because it buys the most risk reduction per hour. Medium-risk items defer before you cut any HIGH-risk coverage; low-risk items defer or skip entirely. Never cut buffer to fit more planned work.\n\n### Step 5: Resource Allocation\n\nAssign testing work based on skill match and availability.\n\n**Allocation principles:**\n- Automated test writing goes to SDETs or developers with framework experience\n- Exploratory testing goes to the person who understands the feature best (often the developer or product manager, not just QA)\n- New feature testing benefits from fresh eyes -- assign someone who did not build it\n- Critical path testing should not have a single point of failure -- two people should be able to cover it\n- Each person's load stays at 70-80% utilization, not 100% — the rest is their buffer\n- Buffer is distributed per person, not lumped into one tester's block: every assignee carries their own buffer line so a blocker on one person does not consume everyone's slack\n\nSee `references\u002Fworkflow-templates.md` for the allocation table format.\n\n### Step 6: Schedule with Buffers\n\nMap testing activities to the sprint timeline. Testing should not be back-loaded to the last two days. See `references\u002Fworkflow-templates.md` for the 2-week sprint schedule template.\n\n**Key scheduling rules:**\n- Testing starts as soon as features are code-complete, not at sprint end\n- Environment setup and test data preparation happen on Day 1, not Day 3\n- Bug verification is continuous, not batched\n- The last day is for confirmation, not for starting new testing\n\n---\n\n## Plan Documents\n\nFull copy-paste plan documents live in `references\u002Fplan-documents.md`:\n\n- **Sprint Test Plan (1-Page)** — scope, coverage summary, effort budget, entry\u002Fexit criteria, plan risks. Keep a sprint plan to one page.\n- **Release Test Plan** — aggregates sprint plans and adds release-specific concerns (full regression, cross-browser, perf benchmark, security scan, smoke test) plus go\u002Fno-go criteria. The go\u002Fno-go *decision* itself belongs to `release-readiness`.\n- **Feature Coverage Matrix** — per-feature scenario list with priority, test type, location, and status.\n- **Test Estimation Worksheet** — new-test development, existing-suite execution, manual testing, and a summary delta vs. available capacity.\n\n---\n\n## Tracking Progress During the Sprint\n\nA test plan is useless if nobody checks it after Day 1. Track progress daily, and feed the results back into future planning at sprint end.\n\n- **Daily test status** — completed, blocked, bugs found, tomorrow's plan, coverage percentage, and buffer consumed. See the format in `references\u002Ftracking-formats.md`.\n- **Sprint retrospective inputs** — estimation accuracy broken out by test type, coverage delta, bug counts by severity, and lessons. See the format in `references\u002Ftracking-formats.md`; feed these data points into the next sprint's estimates.\n\n---\n\n## Anti-Patterns\n\n### Planning Without Risk Assessment\n\nTreating every feature with equal depth wastes effort on low-risk areas and under-tests critical paths. Always run the prioritization matrix (Step 4) before allocating effort. For the full risk methodology, see `risk-based-testing`.\n\n### No Buffer for Bug Discovery\n\nScheduling 100% of available hours for planned activities leaves no time for verification when bugs are found. Reserve 20-30% as buffer and track consumption daily.\n\n### Back-Loading Testing to Sprint End\n\nLeaving all testing for the last two days rushes coverage and surfaces bugs too late to fix. Start testing as features become available; continuous testing beats batch testing at sprint end.\n\n### Test Plan as Compliance Artifact\n\nA 30-page plan filed and forgotten helps nobody. The plan should be one page for a sprint, actively tracked, and updated daily. If the plan is not changing, nobody is using it.\n\n### Estimating Without Historical Data\n\nEffort estimates pulled from thin air are unreliable. Track actual time spent — broken out by test type — and use that data for future estimates. After 2-3 sprints, estimates become reliable.\n\n### Ignoring Environment and Data Setup\n\nEnvironment setup, test data creation, and mock configuration can consume 20-40% of testing effort. Include the \"Setup & test data\" row from Step 3 in the estimate or the plan will always run over.\n\n### Single-Person Coverage on Critical Path\n\nA single tester covering all critical-path work is a failure point. Ensure at least two people can cover critical-path testing.\n\n---\n\n## Verification\n\nOpen the produced plan and confirm: every in-scope ticket ID from the sprint board appears in the Scope table; the coverage matrix has zero unexplained GAP rows (each GAP carries an accept\u002Fdefer note); allocated capacity sums to 70-80% with a named buffer line; and the entry\u002Fexit criteria checklists are filled, not placeholder. If any of these fails, the plan is not done.\n\n## Done When\n\n- [ ] A sprint or release test plan document exists (1-page sprint template or release template) with scope table, coverage summary, effort budget, and entry\u002Fexit criteria all filled in — no placeholders\n- [ ] Every in-scope feature is decomposed into specific testable scenarios with pass\u002Ffail criteria, covering happy path, validation, error, edge, and concurrency categories\n- [ ] A requirements-to-test coverage matrix exists with no unexplained GAP entries (every GAP has an accept-risk or defer note)\n- [ ] Each scenario is estimated and plotted on the risk x effort matrix, with deferred items explicitly listed\n- [ ] Allocated capacity is 70-80% with 20-30% buffer explicitly reserved as a named line\n- [ ] Test data requirements, environment details, and resource allocation are documented in the plan\n\n## Reference Files (in `references\u002F`)\n\n- **workflow-templates.md** — Fill-in scaffolds for the six workflow steps: decomposition template + example, coverage matrix, sprint estimation worksheet, risk×effort matrix grid, allocation table, and 2-week schedule.\n- **plan-documents.md** — Full copy-paste documents: 1-page sprint test plan, release test plan, feature coverage matrix, and estimation worksheet.\n- **tracking-formats.md** — Daily test status format and sprint retrospective inputs format (with per-test-type variance).\n\n## Related Skills\n\n- **test-strategy** -- The broader QA strategy that test plans execute against; strategy defines the approach, plans implement it per sprint.\n- **risk-based-testing** -- Deep methodology for risk assessment that feeds into the prioritization matrix in Step 4.\n- **release-readiness** -- The go\u002Fno-go decision that the release test plan's exit criteria feed into; this skill builds the plan, that one makes the ship call.\n- **qa-metrics** -- Metrics like defect escape rate and estimation accuracy that improve future test plans.\n- **exploratory-testing** -- Structured exploratory sessions referenced in the manual testing sections of the plan.\n- **qa-project-context** -- The project context file that provides baseline answers to discovery questions.\n","\u003Cobjective>\nCreate actionable test plans for sprints and releases. A test plan answers four questions: what to test, how deeply, who does it, and when it must be done. The output is a living document that tracks progress, not a bureaucratic artifact filed and forgotten. A plan that schedules 100% of available time fails the moment the first bug is found — buffer and prioritization are what make it survive contact with reality.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Plan a single sprint | Steps 1-6 below, then the 1-page sprint template in `references\u002Fplan-documents.md` |\n| Plan a release | Release template in `references\u002Fplan-documents.md`; the go\u002Fno-go decision itself belongs to `release-readiness` |\n| Track an in-flight plan \u002F feed results back | `references\u002Ftracking-formats.md` (daily status + retrospective) |\n| Decide what to cut when over capacity | Step 4 prioritization matrix |\n\n---\n\n## Discovery Questions\n\nBefore writing a test plan, gather context. Check `.agents\u002Fqa-project-context.md` first -- if it exists, use it as the foundation and skip questions already answered there.\n\n### Scope\n\n- What is the scope? (single sprint, release, hotfix, feature)\n- Which features are new vs. changed vs. unchanged?\n- Which features are being released for the first time?\n- Are there infrastructure or dependency changes (database migrations, API version bumps, third-party provider switches)?\n- Is there a requirements document, PRD, or set of user stories to map against?\n\n### Time and Resources\n\n- What is the testing window? (days, hours available)\n- Who is available for testing? (SDETs, manual testers, developers)\n- Are there shared resources that could bottleneck? (staging environments, test accounts, devices)\n- Is there a hard deadline that cannot move, or is the release date flexible?\n\n### Risk Context\n\n- Which areas changed the most in this cycle?\n- What broke in the last release or sprint?\n- Are there known fragile areas or tech debt that increase risk?\n- For risk-based prioritization methodology, see `risk-based-testing`.\n\n### Existing Coverage\n\n- What automated tests already exist for the in-scope features?\n- What is the current pass rate of the automated suite?\n- Are there known gaps in automation that require manual testing?\n- When was the last exploratory testing session on these features?\n\n---\n\n## Core Principles\n\n### 1. Coverage-Driven: Map Every Requirement to at Least One Test\n\nA test plan without traceability to requirements is a guess. Every user story, acceptance criterion, or requirement must map to at least one test case. Gaps in this mapping are untested requirements -- the most dangerous kind of risk.\n\n### 2. Time-Boxed: Plan Fits the Available Window\n\nTesting expands to fill available time if unbounded. Set a time box for each activity and stick to it. When the window is too short, the prioritization matrix determines what gets cut -- not gut feeling.\n\n### 3. Prioritized: Not Everything Gets Equal Depth\n\nA payment flow change and a tooltip fix do not deserve equal effort. Use the risk x effort matrix to allocate depth: some features get full regression, others a smoke test, some nothing if low-risk and unchanged.\n\n### 4. Buffered: Leave Room for the Unexpected\n\nPlans that schedule 100% of available time fail when bugs are found. Allocate only 70-80% of the testing window to planned work and explicitly reserve the remaining 20-30% for bug verification, re-testing, and unplanned investigation. If buffer is not a named line in the plan, you do not have one.\n\n### 5. Visible: The Plan Is a Communication Tool\n\nDevelopers need to know what gets tested to write testable code. Product managers need coverage visibility to make release decisions. Publish the plan where the team can see it.\n\n### 6. Entry and Exit Criteria Are First-Class\n\nThe most-reused part of any plan is its gate. Make it explicit, not buried: **entry** = code-complete on staging + existing suite green + test data seeded; **exit** = every HIGH-risk area covered + no open P0\u002FP1 + zero unexplained GAP rows in the coverage matrix. Everything else is detail around these two checkpoints.\n\n---\n\n## Workflow\n\nThe six workflow steps each have a fill-in-the-blank scaffold. The decision prose stays here; the copy-paste templates (decomposition, coverage matrix, estimation worksheet, prioritization matrix, allocation table, schedule) live in `references\u002Fworkflow-templates.md`.\n\n### Step 1: Feature Analysis and Decomposition\n\nBreak each in-scope feature into testable units. A \"testable unit\" is a specific behavior that can be verified with a clear pass\u002Ffail outcome. Walk every feature against these scenario categories so none gets skipped:\n\n- **Happy path** — the primary success flow.\n- **Validation** — required fields empty, format violations, boundary values.\n- **Error conditions** — server 5xx, network timeout, rejected input.\n- **Edge cases** — unicode, oversized payloads, unsupported formats.\n- **Concurrency \u002F race conditions** — two users edit the same record simultaneously, double-submit, retry-after-timeout. These hide the worst data-corruption bugs and are the category most often missed.\n- **Integration points** — behavior across each boundary the feature crosses.\n\nSee `references\u002Fworkflow-templates.md` for the decomposition template and a worked \"User Profile Edit\" example that exercises all six categories.\n\n> **AI decomposition cross-check.** When an agent decomposes features, have it immediately map its own scenarios back against the Step 2 coverage matrix. Any requirement with no scenario, or any scenario category above with no entry, is a decomposition gap the agent must surface before estimation — this is how you catch the agent's blind spots, not after CI does.\n\n### Step 2: Requirements-to-Test Coverage Mapping\n\nCreate a traceability matrix that maps every requirement to its test cases. See `references\u002Fworkflow-templates.md` for the coverage matrix template.\n\nRules for the coverage matrix:\n- Every requirement must appear in the matrix (target: 100% mapping)\n- \"GAP\" status triggers a decision: write a test, accept the risk, or defer\n- Automated tests get test IDs that link to the actual test file\u002Ffunction\n- Manual tests reference the test case document or charter\n\n### Step 3: Effort Estimation\n\nEstimate effort for each test type using historical data. If no historical data exists, use the reference estimates below and calibrate after the first sprint.\n\n**Estimation reference (per test case):**\n\n| Test Type | Write Time | Execute Time | Maintenance (per quarter) |\n|-----------|-----------|-------------|--------------------------|\n| Unit test | 0.5 hr | \u003C 1 sec | 5 min |\n| Integration test | 1 hr | 5-30 sec | 15 min |\n| E2E test (Playwright\u002FCypress) | 2-3 hours | 30s-2 min | 30 min |\n| Manual test case (write) | 0.25 hr | 5-15 min per execution | 10 min |\n| Exploratory session (charter) | 15 min | 1.5 hrs per session | N\u002FA |\n| Accessibility review (manual) | 0.5-1 hr per area | included in write | 15 min |\n| Visual regression test | 30-60 min | 10-30 sec | 20 min (baseline updates) |\n| Performance test (k6 script) | 2-4 hours | 5-30 min per run | 30 min |\n| Prompt regression \u002F LLM eval | 30-60 min per case | 30 sec - 2 min (with API cost) | 20 min |\n| Setup & test data (per feature) | 0.5-2 hrs | one-time | re-seed per env |\n\nWrite Time is authoring only. The \"Setup & test data\" row is the line planners most often omit — environment, fixtures, and mock configuration routinely run 20-40% of total effort, so budget it as a real line rather than discovering it mid-sprint.\n\n> **AI authoring trade-off.** Using an agent to author tests cuts *Write Time* by roughly 40-60%, but add a *Review Time* line of similar size per case — Bolton's \"AI productivity paradox\" (2026) is that the speed-up evaporates when an agent ships plausible-but-broken tests that pass a casual review and fail in CI. See `ai-test-generation` Step 7 for the review checklist and `ai-qa-review` for the smell taxonomy.\n\n> **Test-smells review.** ISTQB's CTAL-AT v2.0 (May 2026) names test smells as a planning concern. Budget a recurring 30-min \"test-smells review\" per sprint against the taxonomy in `ai-qa-review` — cheap, and it finds maintenance debt before it compounds.\n\nUse the sprint estimation worksheet in `references\u002Fworkflow-templates.md` to roll per-case estimates up to a capacity-utilization figure (target: 70-80%, leaving 20-30% buffer).\n\n### Step 4: Prioritization Matrix (Risk x Effort)\n\nWhen the estimated effort exceeds available capacity (it usually does), use the risk x effort matrix to decide what to cut. See `references\u002Fworkflow-templates.md` for the full matrix grid.\n\nFor each test case, plot it on the matrix using the risk score from `risk-based-testing` and the effort estimate from Step 3, then consume capacity in priority order: **DO FIRST → DO SECOND → DO THIRD → DEFER → SKIP**.\n\n**Tie-break rule:** within HIGH risk, low-effort beats high-effort — a HIGH-risk \u002F low-effort test (DO FIRST) outranks a HIGH-risk \u002F high-effort test (DO THIRD), because it buys the most risk reduction per hour. Medium-risk items defer before you cut any HIGH-risk coverage; low-risk items defer or skip entirely. Never cut buffer to fit more planned work.\n\n### Step 5: Resource Allocation\n\nAssign testing work based on skill match and availability.\n\n**Allocation principles:**\n- Automated test writing goes to SDETs or developers with framework experience\n- Exploratory testing goes to the person who understands the feature best (often the developer or product manager, not just QA)\n- New feature testing benefits from fresh eyes -- assign someone who did not build it\n- Critical path testing should not have a single point of failure -- two people should be able to cover it\n- Each person's load stays at 70-80% utilization, not 100% — the rest is their buffer\n- Buffer is distributed per person, not lumped into one tester's block: every assignee carries their own buffer line so a blocker on one person does not consume everyone's slack\n\nSee `references\u002Fworkflow-templates.md` for the allocation table format.\n\n### Step 6: Schedule with Buffers\n\nMap testing activities to the sprint timeline. Testing should not be back-loaded to the last two days. See `references\u002Fworkflow-templates.md` for the 2-week sprint schedule template.\n\n**Key scheduling rules:**\n- Testing starts as soon as features are code-complete, not at sprint end\n- Environment setup and test data preparation happen on Day 1, not Day 3\n- Bug verification is continuous, not batched\n- The last day is for confirmation, not for starting new testing\n\n---\n\n## Plan Documents\n\nFull copy-paste plan documents live in `references\u002Fplan-documents.md`:\n\n- **Sprint Test Plan (1-Page)** — scope, coverage summary, effort budget, entry\u002Fexit criteria, plan risks. Keep a sprint plan to one page.\n- **Release Test Plan** — aggregates sprint plans and adds release-specific concerns (full regression, cross-browser, perf benchmark, security scan, smoke test) plus go\u002Fno-go criteria. The go\u002Fno-go *decision* itself belongs to `release-readiness`.\n- **Feature Coverage Matrix** — per-feature scenario list with priority, test type, location, and status.\n- **Test Estimation Worksheet** — new-test development, existing-suite execution, manual testing, and a summary delta vs. available capacity.\n\n---\n\n## Tracking Progress During the Sprint\n\nA test plan is useless if nobody checks it after Day 1. Track progress daily, and feed the results back into future planning at sprint end.\n\n- **Daily test status** — completed, blocked, bugs found, tomorrow's plan, coverage percentage, and buffer consumed. See the format in `references\u002Ftracking-formats.md`.\n- **Sprint retrospective inputs** — estimation accuracy broken out by test type, coverage delta, bug counts by severity, and lessons. See the format in `references\u002Ftracking-formats.md`; feed these data points into the next sprint's estimates.\n\n---\n\n## Anti-Patterns\n\n### Planning Without Risk Assessment\n\nTreating every feature with equal depth wastes effort on low-risk areas and under-tests critical paths. Always run the prioritization matrix (Step 4) before allocating effort. For the full risk methodology, see `risk-based-testing`.\n\n### No Buffer for Bug Discovery\n\nScheduling 100% of available hours for planned activities leaves no time for verification when bugs are found. Reserve 20-30% as buffer and track consumption daily.\n\n### Back-Loading Testing to Sprint End\n\nLeaving all testing for the last two days rushes coverage and surfaces bugs too late to fix. Start testing as features become available; continuous testing beats batch testing at sprint end.\n\n### Test Plan as Compliance Artifact\n\nA 30-page plan filed and forgotten helps nobody. The plan should be one page for a sprint, actively tracked, and updated daily. If the plan is not changing, nobody is using it.\n\n### Estimating Without Historical Data\n\nEffort estimates pulled from thin air are unreliable. Track actual time spent — broken out by test type — and use that data for future estimates. After 2-3 sprints, estimates become reliable.\n\n### Ignoring Environment and Data Setup\n\nEnvironment setup, test data creation, and mock configuration can consume 20-40% of testing effort. Include the \"Setup & test data\" row from Step 3 in the estimate or the plan will always run over.\n\n### Single-Person Coverage on Critical Path\n\nA single tester covering all critical-path work is a failure point. Ensure at least two people can cover critical-path testing.\n\n---\n\n## Verification\n\nOpen the produced plan and confirm: every in-scope ticket ID from the sprint board appears in the Scope table; the coverage matrix has zero unexplained GAP rows (each GAP carries an accept\u002Fdefer note); allocated capacity sums to 70-80% with a named buffer line; and the entry\u002Fexit criteria checklists are filled, not placeholder. If any of these fails, the plan is not done.\n\n## Done When\n\n- [ ] A sprint or release test plan document exists (1-page sprint template or release template) with scope table, coverage summary, effort budget, and entry\u002Fexit criteria all filled in — no placeholders\n- [ ] Every in-scope feature is decomposed into specific testable scenarios with pass\u002Ffail criteria, covering happy path, validation, error, edge, and concurrency categories\n- [ ] A requirements-to-test coverage matrix exists with no unexplained GAP entries (every GAP has an accept-risk or defer note)\n- [ ] Each scenario is estimated and plotted on the risk x effort matrix, with deferred items explicitly listed\n- [ ] Allocated capacity is 70-80% with 20-30% buffer explicitly reserved as a named line\n- [ ] Test data requirements, environment details, and resource allocation are documented in the plan\n\n## Reference Files (in `references\u002F`)\n\n- **workflow-templates.md** — Fill-in scaffolds for the six workflow steps: decomposition template + example, coverage matrix, sprint estimation worksheet, risk×effort matrix grid, allocation table, and 2-week schedule.\n- **plan-documents.md** — Full copy-paste documents: 1-page sprint test plan, release test plan, feature coverage matrix, and estimation worksheet.\n- **tracking-formats.md** — Daily test status format and sprint retrospective inputs format (with per-test-type variance).\n\n## Related Skills\n\n- **test-strategy** -- The broader QA strategy that test plans execute against; strategy defines the approach, plans implement it per sprint.\n- **risk-based-testing** -- Deep methodology for risk assessment that feeds into the prioritization matrix in Step 4.\n- **release-readiness** -- The go\u002Fno-go decision that the release test plan's exit criteria feed into; this skill builds the plan, that one makes the ship call.\n- **qa-metrics** -- Metrics like defect escape rate and estimation accuracy that improve future test plans.\n- **exploratory-testing** -- Structured exploratory sessions referenced in the manual testing sections of the plan.\n- **qa-project-context** -- The project context file that provides baseline answers to discovery questions.\n",{"name":5,"license":15,"metadata":49,"description":7},{"author":50,"version":51,"category":52},"kindlmann","2.0","strategy","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Ftest-planning","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add pattanation\u002FNorvik --skill test-planning",{"tool":66,"command":67},"bunx","bunx skills add pattanation\u002FNorvik --skill test-planning",{"tool":69,"command":70},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill test-planning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-planning\u002FSKILL.md",true,[74,80,84],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fplan-documents.md","REFERENCE","参考文档",4522,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-planning\u002Freferences\u002Fplan-documents.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Ftracking-formats.md",1839,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-planning\u002Freferences\u002Ftracking-formats.md",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fworkflow-templates.md",5773,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-planning\u002Freferences\u002Fworkflow-templates.md",[89,118,144,167,188,203],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":94,"sourceHtmlUrl":95,"categories":96,"keywords":101,"publishedAt":44},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[97,98],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[102,39,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117],"webapp","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":122,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":44},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[125],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},[127,128,129,114,130,131,132,104,133,134,107,135,136,137,138,139,140,141,142,143],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":148,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":44},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[151],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},[153,154,155,156,157,158,159,160,161,162,163,164,165,166],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":171,"sourceHtmlUrl":172,"categories":173,"keywords":176,"publishedAt":44},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[174,175],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},[177,39,178,164,179,113,25,180,181,159,182,104,183,184,185,136,186,165,187],"vue testing best practices","testing best practices","best practices","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":192,"sourceHtmlUrl":193,"categories":194,"keywords":196,"publishedAt":44},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[195],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},[197,164,198,179,199,181,200,159,186,201,202],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":207,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":44},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[210],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},[212,164,179,213,156,214,215,216,197,217,218,219,220,221,222,104,223,136,224,225],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]