메뉴
テストの粒度選択のうち、システム全体を外から見る広域確認の層(システムテスト、 E2Eテスト、受け入れテスト/UAT)を扱う。 test-catalog の手法カタログの一部。複数サービス・DB・設定が組み合わさった本番に 近い構成での機能/性能/セキュリティ要件の検証、実ブラウザでの主要ユーザーフロー の通し確認、ビジネス側と合意した受け入れ基準へのトレーサビリティを検証したい、 または割り当てたいときに使う。通常は test-catalog スキルの索引経由で手法が選定 された後にこのスキルを直接参照する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。
テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。
Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.
test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
| name | levels-system |
| description | テストの粒度選択のうち、システム全体を外から見る広域確認の層(システムテスト、 E2Eテスト、受け入れテスト/UAT)を扱う。 test-catalog の手法カタログの一部。複数サービス・DB・設定が組み合わさった本番に 近い構成での機能/性能/セキュリティ要件の検証、実ブラウザでの主要ユーザーフロー の通し確認、ビジネス側と合意した受け入れ基準へのトレーサビリティを検証したい、 または割り当てたいときに使う。通常は test-catalog スキルの索引経由で手法が選定 された後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
システム全体を外から見るレベルのうち、利用者や発注者の視点で振る舞いを確かめる「広域確認」の層を集める。 複数のサービスや UI、DB、設定が組み合わさった状態で、本物の環境に近い構成で代表シナリオを通す。 いずれも個別ロジックのデバッグには向かず、要件・利用フロー・受け入れ基準を代表シナリオで踏むことに集中する。
各レベルは「概要」「目的/いつ使う」「example」「落とし穴」「網羅の定義」「遂行手順(着手→完了)」「完了チェック(もれ確認)」で示す。 遂行手順は「要件/基準/フローを洗い出す → 代表を選ぶ → 完了を判定する」を番号付きの手順に落とし、完了チェックは漏れを実際に検出する確認項目を並べる。
統合された全体を本番に近い構成で立ち上げ、外部から見た機能、性能、セキュリティを検証する。
複数サービス、DB、設定が組み合わさった状態で要件を満たすかを、リリース前に確かめたいときに使う。 個別ロジックのデバッグには向かない(遅く、失敗箇所の切り分けが難しい)。
import { describe, it, expect } from "vitest";
// 起動済みの全システムに HTTP で外から触る。内部実装には一切触れない
const BASE = process.env.SYSTEM_URL ?? "http://localhost:8080";
describe("注文フロー(システム)", () => {
it("注文を作成すると 201 と ID を返す", async () => {
const res = await fetch(`${BASE}/orders`, {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ sku: "A1", qty: 1 }),
});
expect(res.status).toBe(201);
const body = await res.json();
expect(body.id).toBeTypeOf("string");
});
});
環境差(設定、データ、依存サービスのバージョン)で落ちると、原因究明にコードより時間を食う。 あらゆる分岐をここで網羅しようとすると遅さで破綻する。網羅は下層に任せ、ここは代表経路に絞る。
このレベルは「統合された全体での要件(機能、性能、セキュリティ)」を網羅対象に取る層。 分岐の網羅は下層に委ね、ここはエンドツーエンドの代表経路に絞る。
システムテストの本体は「リリース判定に要る要件を機能と非機能の両面で漏れなく洗い出し、各要件カテゴリに代表シナリオを1本ずつ当てる」ことだ。要件の洗い出しが空疎だと、緑でも「何を確かめたか」が言えない。次の順で進める。
実ブラウザを使い、ユーザーの操作と同じ経路で UI から裏側まで通しで検証する。
ログインから購入完了までの主要な利用シナリオが壊れていないことを保証したいときに使う。 細かい表示条件やバリデーションの全パターンには使わない(遅く脆い。単体/コンポーネントへ寄せる)。
import { test, expect } from "@playwright/test";
test("ログインしてダッシュボードに到達する", async ({ page }) => {
await page.goto("/login");
await page.getByLabel("メールアドレス").fill("alice@example.com");
await page.getByLabel("パスワード").fill("secret");
await page.getByRole("button", { name: "ログイン" }).click();
// URL とロールで到達を確認。実装詳細ではなく見える状態を assert する
await expect(page).toHaveURL(/\/dashboard/);
await expect(page.getByRole("heading", { name: "ダッシュボード" })).toBeVisible();
});
waitForTimeout の固定待ちや CSS セレクタ依存は、flaky と保守コストの主因。
ロールやラベルで要素を取り、自動待機(expect(...).toBeVisible())に任せる。
シナリオを増やしすぎると CI が肥大する。E2E はピラミッドの頂点、本数を絞る。
このレベルは「主要な利用シナリオの最小集合」を網羅対象に取る層。 ピラミッドの頂点として本数を絞り、重要フローだけを通す。
E2E の本体は「主要ユーザーフローを列挙し、事業インパクト順に最小本数だけ通しシナリオへ落とす」ことだ。フローの列挙が曖昧だと、重要フローを取りこぼしたまま枝葉の表示確認を積み上げてしまう。次の順で進める。
expect(...).toBeVisible())に任せる。フローの開始点から「ゴールに到達した観察可能な状態」までを1本で通す。waitForTimeout の固定待ちや CSS セレクタ依存が残っていないか(grep -n "waitForTimeout" <test> がヒットしないこと)。ロール/ラベル取得と自動待機に統一されているか。発注者やユーザー視点で、要件と受け入れ基準を満たすかを判定する。自動化する場合は Gherkin など業務語彙で書く。
「作ったもの」ではなく「望まれたもの」になっているかを、ビジネス側と合意した基準で確認したいときに使う。 技術的な内部品質の検証には使わない(それは開発側のテストの責務)。
import { describe, it, expect } from "vitest";
import { checkout } from "./checkout";
// 受け入れ基準を業務の言葉でテスト名にし、外から見た結果だけを判定する
describe("受け入れ: クーポン適用", () => {
it("有効なクーポンを使うと合計が割引額だけ下がる", () => {
const before = checkout({ items: [{ price: 1000 }] });
const after = checkout({ items: [{ price: 1000 }], coupon: "OFF200" });
expect(before.total - after.total).toBe(200);
});
});
受け入れ基準が曖昧なまま自動化すると、何を合意したのか後から誰も言えなくなる。 開発者だけで書いた UAT は「自分が作った仕様の再確認」になりがち。基準はビジネス側と先に固める。
このレベルは「ビジネスと合意した受け入れ基準の全項目」を網羅対象に取る層。 技術的な内部品質ではなく、合意済みの基準そのものを網羅する。
UAT の本体は「合意済みの受け入れ基準を1つずつ取得し、基準とテストを1対1で紐づけ、全基準がテストで覆われたことをトレーサビリティで示す」ことだ。基準とテストの対応が見えないと、何を合意し何を確かめたかが後から誰も言えなくなる。次の順で進める。
AC-注文-01 のような ID を付け、基準文を一覧化する。ID が無いと対応の取りようがない。基準ID | 基準文 | テスト名 | 状態(緑/赤/未着手) の表を用意し、基準を行として全部並べる。これがカバレッジの台帳になる。レベルを選んだあとの配分(ピラミッド/トロフィー)と階層化(関心事による分割)は strategy-allocation.md を読む(levels.md 末尾と同じ)。
運用確認の層(スモーク/サニティ/回帰)は levels-operational.md を読む。