Test Gap Analysis
Use it to determine which requirements, risks, behaviors, or failure modes lack a test intent or evidence.
StatusStable
TypeAtomic Skill
DomainSoftware testing
SDLCTest design
Good forQA / BA / PM
LanguageChinese / English
EvalsEvals ✓
Synced2026-09-15
Why this Skill
It turns this Skill's method into a quality input that can be executed, reviewed, and reused.
- TG-## records a gap and an action, not a coverage claim, pass, release, or risk-acceptance evidence.
- File presence, similar test names, report summaries, or static configuration cannot alone prove execution or coverage.
- Every material conclusion needs a source and minimum evidence; inferences must state assumptions and validation.
- Treating a test file as proof that a requirement is covered.
When to use
Use this Skill
- Use it to determine which requirements, risks, behaviors, or failure modes lack a test intent or evidence.
- Use it to find orphan tests, stale evidence, unverified execution, low-value duplicates, and high-risk uncovered obligations.
- Use it when inputs are incomplete but a bounded gap register and evidence questions are still useful.
Common pitfalls
- Treating a test file as proof that a requirement is covered.
- Saying “coverage is insufficient” without identifying the missing obligation and evidence.
- Marking every gap as highest priority or turning a suggested test into an execution result.
- Hiding the actual gap judgment inside a full traceability matrix or a test-case dump.
Input
Minimum Input
- The current task scope, objective, and subject under review.
Recommended Input
- Project goal
- Test scope
- Constraints
Optional Context
- Relevant code or configuration
- Historical results
- Logs and metrics
Output
The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.
These are the Skill's expected output requirements, not evidence that it ran in a real project.
- 01Read and follow prompts/test-gap-analysis.md, beginning with the six-part input audit.
- 02Compare test obligations with test assets in both directions; never infer coverage from filenames or titles alone.
- 03Use TG-## to distinguish missing mappings, orphan tests, unverified execution, stale evidence, uncovered risks, and low-value duplicates.
- 04Preserve source, evidence state, impact/priority, proposed test intent, owner role, and close condition for every gap.
View full output structure
- 05When evidence is missing, return a bounded result and mark unassessed, unverified, or blocked boundaries.
How It Works
- 01Read and follow prompts/test-gap-analysis.md, beginning with the six-part input audit.
- 02Compare test obligations with test assets in both directions; never infer coverage from filenames or titles alone.
- 03Use TG-## to distinguish missing mappings, orphan tests, unverified execution, stale evidence, uncovered risks, and low-value duplicates.
- 04Preserve source, evidence state, impact/priority, proposed test intent, owner role, and close condition for every gap.
- 05When evidence is missing, return a bounded result and mark unassessed, unverified, or blocked boundaries.
Install & Quick Start
Install command / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-gap-analysis
-gtest-gap-analysis.prompt
@skill test-gap-analysis
Using the current project context, produce an actionable result following this Skill.
Additional context:
[Paste project context or requirement]---
name: test-gap-analysis
description: Use this skill when you need to identify missing or weak test obligations from requirements, risks, changes, defects, and test evidence; triggers include test gap analysis.
---
# Test Gap Analysis
Find test obligations that are not sufficiently protected by test intent or execution evidence across requirements, risks, changes, defects, and test assets. Produce actionable `TG-##` gaps. This is not a replacement for a traceability matrix, test-case review, or test execution.
## When to Use
- Use it to determine which requirements, risks, behaviors, or failure modes lack a test intent or evidence.
- Use it to find orphan tests, stale evidence, unverified execution, low-value duplicates, and high-risk uncovered obligations.
- Use it when inputs are incomplete but a bounded gap register and evidence questions are still useful.
Do not use it only to write test cases, build a complete `RT-##`/`TC-##` matrix, execute tests, or accept residual risk for a Human.
## Output Format Options
- Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
- Do not present a structured format or static inventory as execution, pass, approval, or release evidence.
## How to Use
1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.
## Workflow
1. Read and follow `prompts/test-gap-analysis.md`, beginning with the six-part input audit.
2. Compare test obligations with test assets in both directions; never infer coverage from filenames or titles alone.
3. Use `TG-##` to distinguish missing mappings, orphan tests, unverified execution, stale evidence, uncovered risks, and low-value duplicates.
4. Preserve source, evidence state, impact/priority, proposed test intent, owner role, and close condition for every gap.
5. When evidence is missing, return a bounded result and mark `unassessed`, `unverified`, or `blocked` boundaries.
## Core Constraints
- `TG-##` records a gap and an action, not a coverage claim, pass, release, or risk-acceptance evidence.
- File presence, similar test names, report summaries, or static configuration cannot alone prove execution or coverage.
- Every material conclusion needs a source and minimum evidence; inferences must state assumptions and validation.
- Never invent requirements, priorities, test results, defect states, owners, or closure facts.
- Do not duplicate complete traceability analysis, test-case authoring, or executable-set selection here.
## Reference Files
- Always read `prompts/test-gap-analysis.md` before producing an analysis.
- For regression, read `evals/eval.yaml` and matching `evals/cases/`; Eval configuration does not prove project results.
- For trigger checks, use `evals/trigger-prompts.csv` and `evals/local-rules.json`; missing `skill.selection` evidence is `BLOCKED`.
## Best Practices
- Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
- Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.
## Pre-delivery Check
- [ ] Recorded known facts, missing information, conflicts, stale information, out-of-scope items, and assumptions.
- [ ] Each `TG-##` has an obligation, source, gap type, evidence, impact/priority, and closure action.
- [ ] Static presence, inference, unverified execution, and actual execution evidence remain separate.
- [ ] High-risk gaps have an owner role, smallest evidence action, and validation method.
- [ ] The gap register is not presented as full coverage, pass, release, or Human risk acceptance.
## Common Pitfalls
- Treating a test file as proof that a requirement is covered.
- Saying “coverage is insufficient” without identifying the missing obligation and evidence.
- Marking every gap as highest priority or turning a suggested test into an execution result.
- Hiding the actual gap judgment inside a full traceability matrix or a test-case dump.