testability-analysis

Testability Analysis (Chinese version)

When to use

A requirement or system needs to be assessed for test readiness in terms of controllability, observability, isolability, and reproducibility.
An existing solution, result, or evidence needs a risk review, and actionable improvement items need to be produced.
The input is incomplete, but a usable first version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required items.

First read and follow prompts/testability-analysis.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that genuinely affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and open questions.
When the task requires architecture-testability-review or architecture mode, first analyze architecture artifacts, dependency topology, asynchronous boundaries, test seams, test double strategy, fault injection entry points, and environment reproducibility, then retain the general testability dimensions.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a constrained first version and explain which conclusions cannot currently hold.

Each execution must read prompts/testability-analysis.md; it is the complete execution specification of this Skill.
When this Skill needs to be evaluated or regressed, read evals/eval.yaml and the matching evals/cases/ cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.
When regression of architecture-testability-review is needed, use architecture-* Eval and local trigger data; still reuse this Skill's physical directory and do not create alias directories.

Do not mistake test framework selection for testability itself
Explain the value and cost of each improvement
Avoid exposing insecure backdoors for testing
architecture mode must support seam, test double, isolation, and fault injection judgments with architecture-level sources; do not treat framework names as testability evidence.
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide a verification method.
Priority must explain the basis in terms of business impact, likelihood of occurrence, or detectability.

Covered: observability, controllability, isolation, determinism, data preparation, fault injection, environment consistency, automation interfaces.
Facts, assumptions, gaps, and recommendations have been distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output contains verifiable judgment criteria, rather than vague generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without specifying input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of prioritization.
Replacing domain judgment with tool names or generic theory.
Rejecting outright when input is incomplete, or conversely pretending the conclusion is already certain.

Start with the paths most likely to cause business loss, security issues, or release blockers.
Reduce uncertainty with the smallest verifiable experiment, and record the conditions for reproduction.
Make the output something another engineer can directly execute and review.