Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

doc-testing

Étoiles6

Forks4

Mis à jour24 juillet 2026 à 00:50

Phase 5 (Testing). Use to build the test-case registry that verifies requirements - derive test cases from each FR's Given/When/Then acceptance criteria by asking the SWE about happy/boundary/failure paths and test data, then write Testing/TestCases.md and back-reference the FRs. Trigger on "write test cases", "define test coverage", "TC registry", "verify these requirements".

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

arousi

arousi/awesome-metho-docs

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	doc-testing
description	Phase 5 (Testing). Use to build the test-case registry that verifies requirements - derive test cases from each FR's Given/When/Then acceptance criteria by asking the SWE about happy/boundary/failure paths and test data, then write Testing/TestCases.md and back-reference the FRs. Trigger on "write test cases", "define test coverage", "TC registry", "verify these requirements".

Doc: Testing (Phase 5)

Produce the test-case registry that ties verification back to requirements. Owns Phase 5 only (QUALITY-GUIDE.md, SCHEMA.md). Consumes Approved FR/UC (and their acceptance criteria); closes the traceability spine.

Inputs

Approved FR/UC IDs and their Given/When/Then acceptance criteria.
Area grouping for TC IDs; any known test data / preconditions.

Process (elicitation loop)

Read the FRs' acceptance criteria and any existing Testing/TestCases.md.
Ask the batch from the bank; derive candidate test cases from each FR's criteria.
Write TC rows (TC-<Area>-NNN) citing the FR/UC each verifies, tagged Happy/Boundary/Failure; back-reference TC IDs in the FR Traceability section.
Re-read; find Must FRs with no test, and criteria with no boundary/failure case; ask follow-ups.
Repeat until DoD.

Questions to ask (bank)

Coverage: For FR X, what are the concrete test cases? (start from its Given/When/Then)
Paths: What is the happy path? The boundary cases? The failure cases?
Data: What test data or preconditions are needed?
Area: Which area/grouping should the TC IDs use?
Priority: Is this FR a Must? (Must FRs require >= 1 TC)

Outputs (creates / updates)

Testing/TestCases.md: TC-<Area>-NNN rows (Area, Title, Verifies FR/UC, Type, Status).
Back-references: TC IDs added to the Traceability section of each verified FR.

Definition of Done (gate)

Every Must FR has >= 1 TC; each TC cites its FR/UC; happy/boundary/failure covered; TC IDs back-referenced in FRs. (LIFECYCLE.md Phase 5.)

Handoff

Coverage complete -> the phase loop closes. New gaps found while testing become candidates for doc-analysis.

Guardrails

TC IDs append-only; canonical Status; ASCII; derive tests from documented acceptance criteria - do not invent behavior. See QUALITY-GUIDE.md.

Plus depuis ce dépôt

même dépôt

doc-analysis

arousi/awesome-metho-docs

Phase 1 (Analysis). Use to analyze a module, feature, or requirement source - ask the SWE questions to understand as-is/to-be, actors, and capabilities, then normalize into atomic candidates classified FR/UC/NFR/Gap/Entity in Analysis/Analysis.md. Trigger on "analyze this feature/module", "break this down", "what are the requirements here", "normalize these notes".

2026-07-246

doc-design

arousi/awesome-metho-docs

Phase 3 (Design and Modeling). Use to model the data and behavior behind approved requirements - ask the SWE about entities, attributes, keys, relationships, and which flows need diagrams, then write the DDT + PlantUML and register entities. Trigger on "model the entities", "design the schema/ERD", "add a sequence/architecture diagram", "data dictionary".

2026-07-246

doc-implementation

arousi/awesome-metho-docs

Phase 4 (Implementation traceability). Use to record how approved requirements map to the build - ask the SWE which design components, modules, and code/PRs implement each FR, and link test IDs. Documents traceability only; no code lives here. Trigger on "link requirements to code", "update traceability", "which FRs did this PR implement", "record design components".

2026-07-246

doc-planning

arousi/awesome-metho-docs

Phase 0 (Planning). Use to start documenting a software project or a major initiative - elicit the project charter by asking the SWE about goals, stakeholders, scope, constraints, risks, and success criteria, then generate or update the PM/ planning files. Trigger on "plan a project", "write a charter", "brainstorm scope", "who are the stakeholders", "define scope/risks".

2026-07-246

doc-requirements

arousi/awesome-metho-docs

Phase 2 (Requirements). Use to turn analysis candidates into Functional Requirements, Use Cases, and NFR references - ask the SWE for exact behavior, acceptance criteria, actors, flows, priorities, and NFR targets, then write the registry rows and per-package FR/UC files. Trigger on "write the FRs", "draft use cases", "define acceptance criteria", "specify NFRs".

2026-07-246

document-software-project

arousi/awesome-metho-docs

Umbrella skill to document a software project in this repo across the full lifecycle - planning, analysis, requirements (FR/UC/NFR), design/diagrams, implementation traceability, and testing. Routes to the phase skills doc-planning / doc-analysis / doc-requirements / doc-design / doc-implementation / doc-testing. Trigger when asked to document a project end-to-end, set one up, or when the phase is unclear.

2026-07-246

name	doc-testing
description	Phase 5 (Testing). Use to build the test-case registry that verifies requirements - derive test cases from each FR's Given/When/Then acceptance criteria by asking the SWE about happy/boundary/failure paths and test data, then write Testing/TestCases.md and back-reference the FRs. Trigger on "write test cases", "define test coverage", "TC registry", "verify these requirements".

Doc: Testing (Phase 5)

Inputs

Approved FR/UC IDs and their Given/When/Then acceptance criteria.
Area grouping for TC IDs; any known test data / preconditions.

Process (elicitation loop)

Read the FRs' acceptance criteria and any existing Testing/TestCases.md.
Ask the batch from the bank; derive candidate test cases from each FR's criteria.
Write TC rows (TC-<Area>-NNN) citing the FR/UC each verifies, tagged Happy/Boundary/Failure; back-reference TC IDs in the FR Traceability section.
Re-read; find Must FRs with no test, and criteria with no boundary/failure case; ask follow-ups.
Repeat until DoD.

Questions to ask (bank)

Coverage: For FR X, what are the concrete test cases? (start from its Given/When/Then)
Paths: What is the happy path? The boundary cases? The failure cases?
Data: What test data or preconditions are needed?
Area: Which area/grouping should the TC IDs use?
Priority: Is this FR a Must? (Must FRs require >= 1 TC)

Outputs (creates / updates)

Testing/TestCases.md: TC-<Area>-NNN rows (Area, Title, Verifies FR/UC, Type, Status).
Back-references: TC IDs added to the Traceability section of each verified FR.

Definition of Done (gate)

Every Must FR has >= 1 TC; each TC cites its FR/UC; happy/boundary/failure covered; TC IDs back-referenced in FRs. (LIFECYCLE.md Phase 5.)

Handoff

Coverage complete -> the phase loop closes. New gaps found while testing become candidates for doc-analysis.

Guardrails

TC IDs append-only; canonical Status; ASCII; derive tests from documented acceptance criteria - do not invent behavior. See QUALITY-GUIDE.md.