test-effectiveness-analysis

Test Effectiveness Analysis

When to Use

Use this skill when you need evidence-bounded analysis, design, or validation preparation for the relationship between test signals and defects or risks, missed-detection limits, false signals, and validation plans.
Use it to review a plan, result, or metric and turn the review into executable improvements.
Use it when input is incomplete but a bounded first pass with assumptions, gaps, and human-decision boundaries is still useful.

Default to Markdown organized by domain risk, evidence state, priority, and boundary.
When the user requests tables, CSV, JSON, or ticket fields, preserve the same finding fields, evidence, and decision boundaries.
Before machine consumption, confirm the schema, enums, required fields, and evidence sources.

Read and follow prompts/test-effectiveness-analysis.md, including its input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with attention to test signal, risk coverage, missed-detection limit, false signal, validation plan.
Separate confirmed facts, evidence-backed inferences, candidate recommendations, and Human decisions before ranking by risk and evidence strength.
Turn high-risk items into preconditions, steps, expected behavior or decision criteria, required evidence, and a validation method.
When input is incomplete, deliver a bounded first pass, state unsupported conclusions, and never present static material as execution evidence.

When calibrating domain outcomes, valid controls, or evidence gaps, read references/domain-decision-example.md for sanitized input, per-item oracles, and reproducible calculations.
Always read prompts/test-effectiveness-analysis.md; it is the complete execution specification for this skill.
For evaluation, read evals/eval.yaml and the matching cases under evals/cases/.
Load references/, examples/, scripts/, or output-formats.md only when those directories exist and the task needs them.

Map obligation/fault class→test ID→real production behavior→effective assertion→escaping defect. Pass/coverage rates are signals, not fault-detection proof.
Historical escapes retain observation window, exposure, detection/misses, and sources. Controlled fault injections use separate denominators, controls, environment, and mutation identity; do not pool them into production-defect rates.
Verify failures came from the intended business assertion; environment errors/timeouts are not automatically valid detections. Give candidate causes/minimal independent checks without claiming causation from correlation.
Report detected/missed/unexecuted faults by class with residual uncertainty, prioritizing critical oracles. Without fault/escape data deliver an evaluation plan, not effectiveness proof.

Keep the analysis focused on the relationship between test signals and defects or risks, missed-detection limits, false signals, and validation plans; do not replace business owners or Human risk acceptance, exception approval, or release decisions.
Never invent system behavior, fields, metrics, thresholds, data, root causes, execution records, or pass claims.
Static design, plans, file presence, or a dry run retain their evidence state and cannot become proof of real execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED and give the smallest validation method.
For production, privacy, or security work, use least privilege, masked data, mocks, dry runs, or isolation.

Covered test signal, risk coverage, missed-detection limit, false signal, validation plan, with source, evidence state, and validation method for each.
Separated facts, inferences, candidate recommendations, gaps, and Human decisions.
Gave high-risk items P0/P1/P2/P3 or an equivalent priority, owner role, and close condition.
Did not turn plans, static checks, or dry runs into test execution, all-passed, or release-approved claims.
Stated residual risk, stop/escalation conditions, and next actions.

Listing checks without triggers, expected concerns, owner roles, close conditions, and evidence.
Treating adjacent metrics or tool names as a complete test effectiveness judgment.
Using unexplained numbers for false precision or writing correlation as causation.
Refusing incomplete input, or pretending that incomplete evidence is conclusive.

Start with paths most likely to cause business loss, quality regression, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty and record conditions, versions, sources, and evidence.
Make the Skill independently installable, executable, and reviewable by another engineer.