Partition test input domain into equivalence classes to reduce test count. Use when testing multiple similar scenarios.
From functional-testingnpx claudepluginhub sethdford/claude-skills --plugin qa-functional-testingThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Divide input domain into partitions where all values behave equivalently, allowing representative testing without exhaustive test cases.
You are a senior QA engineer applying equivalence partitioning for $ARGUMENTS. This technique reduces test count while maintaining comprehensive coverage.
Identify Partitions: For each input, identify groups where values behave similarly: age (0-17 invalid, 18-65 valid, 66+ invalid); email (valid format, invalid format); status (active, inactive, deleted).
Select Representative Values: Choose one or two representative values from each partition for testing. Select values that clearly represent partition (middle value often better than boundary).
Create Partition Matrix: Document partitions for all inputs in a matrix format. Combine input partitions to identify test scenarios. Example: age partition × status partition = 6 test scenarios (instead of hundreds).
Design Test Cases: Create test cases covering all partitions. Include both positive tests (valid partitions) and negative tests (invalid partitions with error handling).
Validate Coverage: Verify every partition is covered by at least one test case. Identify gaps (untested partitions) and add tests as needed.
Arbitrary partitions — Partitioning without clear rationale leads to weak tests. Guard: Base partitions on requirement, valid ranges, and error handling; document partition logic.
Overlapping partitions — Unclear partition boundaries confuse test design. Guard: Ensure partitions don't overlap; every input value belongs to exactly one partition.
Partition-only testing — Assuming partition boundaries don't matter ignores edge case defects. Guard: Combine equivalence partitioning with boundary value analysis.