Best for
- This skill provides testing pyramid standards and best practices for systematic testing, supporting both ISTQB and Industry Pyramid frameworks.
AsiaOstrich/universal-dev-standards/skills/testing-guide/SKILL.md
Testing pyramid and test writing standards for UT/IT/ST/E2E. Supports ISTQB and Industry Pyramid frameworks. Use when: writing tests, discussing test coverage, test strategy, or test naming. Not for: driving a Red-Green-Refactor cycle — use /tdd; measuring achieved coverage — use /coverage. Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT.
Decision brief
Language: English | 繁體中文
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/AsiaOstrich/universal-dev-standards --skill "skills/testing-guide"Inspect the Agent Skill "testing-guide" from https://github.com/AsiaOstrich/universal-dev-standards/blob/a61aabdb5bffea6179ef28b804a16cdf9b77a164/skills/testing-guide/SKILL.md at commit a61aabdb5bffea6179ef28b804a16cdf9b77a164. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
If no configuration found and context is unclear:
This skill provides testing pyramid standards and best practices for systematic testing, supporting both ISTQB and Industry Pyramid frameworks.
UDS provides 6 testing-related skills. Use this decision tree to find the right one:
Note on Integration Testing abbreviation: - IT (Integration Testing): Agile/DevOps communities - SIT (System Integration Testing): Enterprise/ISTQB contexts - Both refer to the same testing level
Review the “Quick Reference” section in the pinned source before continuing.
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 71 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Language: English | 繁體中文
Version: 1.2.0 Last Updated: 2026-01-29 Applicability: Claude Code Skills
This skill provides testing pyramid standards and best practices for systematic testing, supporting both ISTQB and Industry Pyramid frameworks.
UDS provides 6 testing-related skills. Use this decision tree to find the right one:
What do you want to do? | 你想做什麼?
├── Measure code coverage (lines/branches/functions) → /coverage
├── Track which requirements have tests (AC traceability) → /ac-coverage
├── Develop with Test-Driven Development (Red-Green-Refactor) → /tdd
├── Write BDD scenarios (Given-When-Then) → /bdd
├── Define acceptance tests with stakeholders → /atdd
└── Learn testing standards and best practices → /testing (this skill)
| Skill | Focus | 焦點 |
|---|---|---|
/testing | Standards and best practices reference | 測試標準與最佳實踐參考 |
/coverage | Code-level coverage analysis | 程式碼層級覆蓋率分析 |
/ac-coverage | Requirement-level AC traceability | 需求層級 AC 可追蹤性 |
/tdd | Red-Green-Refactor development cycle | 紅-綠-重構開發循環 |
/bdd | Behavior scenarios with Given-When-Then | Given-When-Then 行為場景 |
/atdd | Acceptance criteria with stakeholders | 與利害關係人定義驗收條件 |
| Framework | Levels | Best For |
|---|---|---|
| ISTQB | UT → IT/SIT → ST → AT/UAT | Enterprise, compliance, formal QA |
| Industry Pyramid | UT (70%) → IT (20%) → E2E (10%) | Agile, DevOps, CI/CD |
Note on Integration Testing abbreviation:
┌─────────┐
│ E2E │ ← 10% (Fewer, slower)
─┴─────────┴─
┌─────────────┐
│ IT/SIT │ ← 20% (Integration)
─┴─────────────┴─
┌─────────────────┐
│ UT │ ← 70% (Unit)
└─────────────────┘
| Level | Scope | Speed | Dependencies |
|---|---|---|---|
| UT | Single function/class | < 100ms | Mocked |
| IT/SIT | Component interaction | 1-10s | Real DB (containerized) |
| ST | Full system (ISTQB) | Minutes | Production-like |
| E2E | User journeys | 30s+ | Everything real |
| AT/UAT | Business validation (ISTQB) | Varies | Everything real |
| Metric | Minimum | Recommended |
|---|---|---|
| Line | 70% | 85% |
| Branch | 60% | 80% |
| Function | 80% | 90% |
For complete standards, see:
For AI assistants, use the YAML format files for reduced token usage:
ai/standards/testing.ai.yamlai/options/testing/istqb-framework.ai.yamlai/options/testing/industry-pyramid.ai.yamlai/options/testing/unit-testing.ai.yamlai/options/testing/integration-testing.ai.yamlai/options/testing/system-testing.ai.yamlai/options/testing/e2e-testing.ai.yamlai/options/testing/security-testing.ai.yamlai/options/testing/performance-testing.ai.yamlai/options/testing/contract-testing.ai.yaml[ClassName]Tests.cs # C#
[ClassName].test.ts # TypeScript
[class_name]_test.py # Python
[class_name]_test.go # Go
[MethodName]_[Scenario]_[ExpectedResult]()
should_[behavior]_when_[condition]()
test_[method]_[scenario]_[expected]()
| Type | Purpose | When to Use |
|---|---|---|
| Stub | Returns predefined values | Fixed API responses |
| Mock | Verifies interactions | Check method called |
| Fake | Simplified implementation | In-memory database |
| Spy | Records calls, delegates | Partial mocking |
test('method_scenario_expected', () => {
// Arrange - Setup test data
const input = createTestInput();
const sut = new SystemUnderTest();
// Act - Execute behavior
const result = sut.execute(input);
// Assert - Verify result
expect(result).toBe(expected);
});
# === ISTQB FUNDAMENTALS ===
terminology:
error: "Human mistake in thinking"
defect: "Bug in code (caused by error)"
failure: "System behaves incorrectly (caused by defect)"
chain: "Error → Defect → Failure"
oracle_problem:
definition: "How do we know the expected result is correct?"
approaches:
- specification_oracle: "Compare against spec"
- reference_oracle: "Compare against reference impl"
- consistency_oracle: "Same input → same output"
- heuristic_oracle: "Reasonable approximation"
# === STATIC vs DYNAMIC ===
static_testing:
definition: "Examine without executing"
techniques: [reviews, walkthroughs, inspections, static_analysis]
finds: "Defects before runtime"
examples: [ESLint, SonarQube, code_review]
dynamic_testing:
definition: "Execute and observe behavior"
techniques: [unit, integration, system, acceptance]
finds: "Failures during execution"
# === TEST DESIGN TECHNIQUES ===
black_box:
equivalence_partitioning:
principle: "Divide inputs into equivalent classes"
example: "Age: [<0 invalid], [0-17 minor], [18-64 adult], [65+ senior]"
boundary_value:
principle: "Test at boundaries of partitions"
example: "Age: test -1, 0, 17, 18, 64, 65"
decision_table:
principle: "Combinations of conditions → actions"
use: "Complex business rules"
state_transition:
principle: "Valid sequences of states"
use: "Workflow, state machines"
white_box:
statement_coverage: "Every statement executed once"
branch_coverage: "Every decision branch taken"
condition_coverage: "Every condition T/F"
path_coverage: "Every possible path (often impractical)"
# === RISK-BASED TESTING ===
risk_assessment:
likelihood: "How likely to fail?"
impact: "How bad if fails?"
priority: "likelihood × impact"
risk_matrix:
high_high: "Test extensively, first priority"
high_low: "Good coverage"
low_high: "Good coverage"
low_low: "Basic coverage"
# === DEFECT MANAGEMENT ===
defect_lifecycle:
states: [new, assigned, in_progress, fixed, verified, closed]
reopen_trigger: "Verification fails"
severity_vs_priority:
severity: "Technical impact (critical/major/minor/trivial)"
priority: "Business urgency (high/medium/low)"
example: "Typo on login page: low severity, high priority (brand)"
# === TEST ENVIRONMENT ===
isolation_levels:
unit: "In-memory, mocked deps"
integration: "Containerized DB (Docker)"
staging: "Production-like, isolated"
production: "Real, feature flags for testing"
test_data_strategies:
fixtures: "Static predefined data"
factories: "Dynamic generation (faker)"
snapshots: "Sanitized production copy"
synthetic: "Algorithm-generated edge cases"
This skill supports project-specific configuration.
CONTRIBUTING.md for "Disabled Skills" section
CONTRIBUTING.md for "Testing Standards" sectionIf no configuration found and context is unclear:
CONTRIBUTING.md:## Testing Standards
### Coverage Targets
| Metric | Target |
|--------|--------|
| Line | 80% |
| Branch | 70% |
| Function | 85% |
In project's CONTRIBUTING.md:
## Testing Standards
### Coverage Targets
| Metric | Target |
|--------|--------|
| Line | 80% |
| Branch | 70% |
| Function | 85% |
### Testing Framework
- Unit Tests: Jest
- Integration Tests: Supertest
- E2E Tests: Playwright
After /testing completes, the AI assistant should suggest:
測試標準與最佳實踐已掌握。建議下一步 / Testing standards and best practices understood. Suggested next steps:
- 執行
/tdd開始測試驅動開發(紅-綠-重構循環) ⭐ Recommended / 推薦 — 將測試知識立即轉化為實踐 / Turn testing knowledge into practice immediately- 執行
/coverage分析目前程式碼覆蓋率 — 找出測試缺口 / Identify testing gaps- 執行
/bdd撰寫行為驅動的 Given-When-Then 場景 — 從使用者角度定義測試 / Define tests from user perspective
| Version | Date | Changes |
|---|---|---|
| 1.2.0 | 2026-01-29 | Added links to new testing-theory.md knowledge base |
| 1.1.0 | 2025-12-29 | Added Testing Theory Essentials YAML section |
| 1.0.0 | 2025-12-24 | Initial: Standard sections (Purpose, Related Standards, Version History, License) |
This skill is released under CC BY 4.0.
Source: universal-dev-standards
Frequently asked questions
Language: English | 繁體中文
The source record exposes this install command: npx skills add https://github.com/AsiaOstrich/universal-dev-standards --skill "skills/testing-guide". Inspect the command and pinned source before running it.
Alternatives
coreyhaines31/marketingskills
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program
garrytan/gbrain
End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.
alirezarezvani/claude-skills
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
dotnet/skills
Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing