domain-testing

Designs equivalence-partition domain test cases for software features step by step.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/DuyITLOR/group05_eshop --skill domain-testing-duyitlor
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-testing
Source: https://github.com/DuyITLOR/group05_eshop/tree/main/HW/week03/NhutDuy/submission/agent-skills/domain-testing
Command: npx skills add https://github.com/DuyITLOR/group05_eshop --skill domain-testing-duyitlor

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designing systematic test cases from a feature specification is error-prone when done ad hoc. This Skill walks you through the Domain Testing technique one disciplined step at a time, producing a complete partition table and test-case table grounded in the actual spec. ## Core Features & Use Cases - Structured 7-step workflow: Identify input variables and outputs, define domains, partition into equivalence classes, pick representative points, design one-variable-at-a-time test cases, document the rationale, and review with a human checkpoint. - Duplicate reduction (B5): Automatically scans the final test suite and removes cases whose Input and Expected Output are identical. - Output domain coverage: Partitions not just inputs but also outputs (success vs. each error/reject category) so expected results map cleanly to spec behavior. - Use Case: Given a registration feature with email, password, and confirm-password rules, produce a DT-FR01-xxx test-case table covering valid and invalid partitions for every variable, saved to test-cases/feature-<X>/domain-testing.md. ## Quick Start Apply domain testing to feature FR-01 registration using the spec in this repository and produce the partition and test-case tables.

Frequently Asked Questions about domain-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design equivalence partition test cases for a feature?▼

Identify each input variable and output, define valid domains and constraints, split each domain into disjoint valid and invalid partitions, then pick representative values. Design test cases varying one variable at a time while holding others at valid values.

What is the one-variable-at-a-time rule in domain testing?▼

Each test case varies only the variable under test across its partitions while all other variables stay at valid in-domain values. This isolates faults to a single variable and keeps expected results traceable to the specification.

How does domain testing relate to boundary value analysis?▼

Domain testing partitions input domains into equivalence classes; when a partition is bounded, representative points are classified as in, on, off, or out. Those boundary points are flagged for a dedicated boundary-value-analysis technique.

When should I not use equivalence partitioning for test design?▼

Avoid it when a feature has no definable input domains, such as pure UI layout checks or state-machine behavior driven by event sequences. Those scenarios suit state-transition or scenario-based testing instead.

How do I remove duplicate test cases from a test suite?▼

Two test cases are duplicates when both their Input and Expected Output are identical. Scan the full designed set and keep only one of each such pair so the final suite contains no redundant rows.