Test Scenarios: test cases and a test specification from requirementsテスト仕様書・テストケースの作成(要件から Excel 出力)

Test Scenarios turns a requirements document into a test specification that you can send to a customer or hand to QA: an integration or acceptance test plan with cases written from a checklist of test viewpoints, not only the happy path. The agent reads the requirements, writes the cases, checks that every requirement is covered, and exports an Excel workbook.

Files it creates

• docs/test/test-spec-<feature>.md: the source of truth. It has the requirement list, a table of cases (ID | category | subcategory | viewpoint | precondition | steps | expected result | priority | requirement ID | automation candidate), the traceability table, the requirements that have no case, and a table of questions for anything unclear.
• docs/test/テスト仕様書_<feature>_YYYYMMDD.xlsx: the same cases for QA, with a case sheet (and empty result, date, tester and notes columns), a traceability sheet, a viewpoint sheet and an open-questions sheet (with an empty answer column for the client). The header row is frozen and cells wrap.

How the cases are designed

1. It lists the requirements with their IDs, using the IDs in your document.
2. For each one it goes through viewpoints: normal flow, boundary values (the limit and one step each side), equivalence classes, errors, permissions for every role, state transitions and concurrency.
3. A vague rule such as "when unavoidable" is not guessed. It goes into the question table with the assumption the cases use if nobody answers.
4. A small Python script checks the case IDs are unique and every requirement ID exists, then writes the workbook.

In our test sample, a reservation screen with 10 numbered requirements, all three runs gave every requirement at least one case, wrote boundary cases for 0, 1, 8 and 9 guests and for 23 hours, exactly 24 hours and 25 hours before the cancellation deadline, tested all three roles, and asked a question about the vague rule "when unavoidable". A single run without the skill missed that question and did not produce the result, date, tester and notes columns.

Limits

• It writes test documents and does not run the tests. Cases marked as automation candidates can be passed to the E2E Test skill, which writes Playwright tests.
• It does not edit your customer's own Excel template. It tells you the columns so you can copy the cases across.
• The first run downloads one Python package (openpyxl) with uv; the agent tells you before it does.

Test Scenarios は、要件定義書などの要件から、顧客に提出できるテスト仕様書を作成するスキルです。結合テスト・受入テスト向けに、正常系だけでなくテスト観点のチェックリストに沿ってケースを書き、要件の漏れを確認して Excel に出力します。

作成するファイル

• docs/test/test-spec-<機能名>.md:元になる Markdown です。要件一覧、テストケース表(ID | 大項目 | 中項目 | 観点 | 前提条件 | 手順 | 期待結果 | 優先度 | 要件ID | 自動化候補)、トレーサビリティ、ケースがない要件、曖昧な点の質問表が入ります。
• docs/test/テスト仕様書_<機能名>_YYYYMMDD.xlsx:QA が使う Excel です。テストケース、要件トレーサビリティ、観点、確認事項(回答欄つき)のシートがあり、ケースのシートには結果・実施日・実施者・備考の空欄が付きます。見出し行は固定、セルは折り返し済みです。

ケースの作り方

1. 要件書にある要件ID を使って要件を一覧にします。
2. 要件ごとに、正常系、境界値(上限・下限とその前後)、同値分割、異常系、全ロールの権限、状態遷移、同時実行の観点で確認します。
3. 「やむを得ない場合」のような曖昧な記述は推測しません。質問表に書き、回答がない場合に使う前提を添えます。
4. Python の小さなスクリプトが、ケースID の重複と存在しない要件ID を検査してから Excel を書き出します。

検証用のサンプル(10 件の要件ID を持つ予約画面)では、スキルありの 3 回とも、すべての要件に 1 件以上のケースを付け、人数 0・1・8・9 の境界値と、キャンセル期限の 23 時間前・ちょうど 24 時間・25 時間前のケース、3 つのロール全部の権限確認を書き、曖昧な「やむを得ない場合」の規定を質問として挙げました。スキルなしの 1 回では、この質問がなく、結果・実施日・実施者・備考の空欄列もありませんでした。

ご注意

• 作成するのはテストの文書で、テストの実行はしません。自動化できるケースは「自動化候補」に印を付けるので、E2E Test スキルに渡して Playwright テストにできます。
• 顧客指定の Excel テンプレートは編集しません。列の構成をお伝えするので、ケースを転記してください。
• 初回のみ uv で Python パッケージ(openpyxl)を 1 つダウンロードします。実行前にエージェントがお知らせします。