testing-principles

Maps the seven JSTQB/ISTQB testing principles to concrete test design techniques.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/Hakkadaikon/hymme --skill testing-principles-hakkadaikon
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing-principles
Source: https://github.com/Hakkadaikon/hymme/tree/main/skills/testing-principles
Command: npx skills add https://github.com/Hakkadaikon/hymme --skill testing-principles-hakkadaikon

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When teams are busy, test design steps get skipped because the reasoning behind each technique is unclear. This Skill consolidates the seven JSTQB/ISTQB testing principles and links each one to the specific techniques in the test-catalog, so you can justify why a technique is needed and decide which steps can safely be omitted. ## Core Features & Use Cases - Seven Principles Explained: Covers defect presence vs. absence, impossibility of exhaustive testing, early testing, defect clustering, the pesticide paradox, context dependence, and the zero-bug fallacy. - Technique Mapping: Each principle points to concrete techniques such as mutation testing, equivalence partitioning, boundary value analysis, risk-based testing, static review, exploratory testing, and acceptance testing. - Use Case: When deciding whether to skip mutation testing on a tight deadline, consult the pesticide paradox section to see that mutation testing exists precisely to verify your test suite still detects defects, then make an informed trade-off. ## Quick Start Ask the AI to explain which testing principle justifies using equivalence partitioning and risk-based test allocation for the current module.

Frequently Asked Questions about testing-principles

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

FAQPage Schema
What are the seven principles of software testing?

The seven JSTQB/ISTQB principles are: testing shows defect presence not absence, exhaustive testing is impossible, early testing saves cost, defects cluster in modules, the pesticide paradox, testing is context dependent, and the zero-bug fallacy. This Skill maps each to concrete techniques.

How do I decide which test design techniques to apply?

Start from the principle matching your concern, then follow the linked technique. For example, defect clustering and impossibility of exhaustive testing point to risk-based testing and equivalence partitioning with boundary value analysis.

Why is mutation testing needed if all tests pass?

Green tests only show detected defects, not absence of defects. Mutation testing injects artificial faults to measure whether your suite can actually catch real defects, addressing the pesticide paradox of stale tests.

When is it acceptable to skip a testing technique?

Testing is context dependent, so rigor should match domain risk, contracts, and regulations. This Skill documents the reasoning behind each technique so you can judge which steps are safe to omit for low-risk modules.

Does this Skill replace the test-catalog techniques?

No. It is a rationale reference within the test-catalog, normally consulted after the catalog index selects a technique. The actual procedures live in the individual technique references it links to.