SaaSのテスト観点表テンプレート：権限・状態・非同期処理の記入例

テスト観点表に必要な項目

テスト観点は「権限」「状態遷移」のような確認の切り口です。一方、テストケースには事前条件、操作、期待結果が必要です。観点表に操作手順をすべて詰め込むと、レビューする人が設計の抜けを探しにくくなります。

このテンプレートでは次の項目を分けています。既存の表を使う場合も、不足する列だけ追加すれば構いません。

• 機能・操作：対象を限定する。例は「CSV出力の予約」。
• 観点・条件：役割、所属、データの状態、処理の時点を具体化する。
• 起きると困ること：件数や一般論ではなく、利用者や業務への影響を書く。
• 根拠と未確定事項：合意した仕様と、まだ決まっていない質問を分離する。
• 判断と関連ケース：採用・対象外・要確認を区別し、ケースIDへつなぐ。

「対象外」は省略の言い換えではありません。例えば外部APIが存在しないなら対象外にできますが、理由を残すことで次の仕様変更時に見直せます。

SaaS向けテスト観点の記入例：8つの切り口

以下は設計を説明するための例で、特定の顧客や障害の事例ではありません。自社に存在する機能だけを選び、仕様に合わせて条件を書き換えてください。すべての行を採用しても網羅性は証明できません。

性能、アクセシビリティ、可用性などの品質要件は、この表だけでは扱い切れません。利用者、利用環境、契約上の要件を確認し、必要な専門的テストへつないでください。テナント分離の行もセキュリティ評価の代替ではありません。

権限 × 処理の状態を組み合わせて考える

「閲覧者は出力できない」と「出力に成功する」を別々に確認しても、出力を予約した人の権限が途中で変わった場合の扱いは決まりません。観点を増やすより、重要な操作の途中で何が変わるかを問い直します。

組み合わせを無限に作る必要はありません。まず情報露出、データ消失、業務停止など影響が大きいリスクを選びます。次に、その結果を変えそうな役割・状態・時点だけを組み合わせ、採用理由を説明できるようにします。

観点表からテストケースへ進む4つの手順

1. 仕様の版を固定する。機能の説明だけでなく、決定済みのルールと対象外を記録します。手元の推測を仕様として扱いません。
2. 対象機能に観点を当てる。8つの切り口を出発点に、製品固有の業務状態や過去の不具合から追加します。同じ意味の候補はまとめます。
3. 要確認を解消する。回答者と期限を決めます。回答待ちの行を「テスト実行可能」と数えず、決まらないことによる影響を伝えます。
4. 採用した条件をケース化する。期待結果を具体化し、仕様・観点・ケースの対応を残します。拒否の確認では画面だけでなく、取得できないことやデータが変わらないことも確認対象にします。

上限変更など、既存データとの関係を深掘りする場合は、仕様変更時のテスト観点を見直す5つの手順に7行のレビュー例を掲載しています。

コピーして使えるテスト観点表テンプレート

まずは次のリリースで変更する機能をひとつ選び、VP-01を複製して使ってください。本書式はKanten作成のオリジナルで、自社の設計作業にコピー・編集して利用できます。

# SaaSのテスト観点表テンプレート

Kanten作成。自社のテスト設計にコピー・編集して利用できます。
Markdown形式（ExcelファイルやKantenへのインポートファイルではありません）。
一般的な設計用の書式であり、網羅性やセキュリティを保証しません。

## 対象と根拠
- 対象機能：
- 仕様版・チケットID：
- 利用者・役割：
- 対象テナントと契約：
- 対象の入口（画面／API／ジョブなど）：
- 対象外と理由：

## 観点表（必要な数だけ行を複製）
### VP-01
- 機能／操作：
- 観点（確認の切り口）：
- 条件（役割・所属・状態・タイミング）：
- 起きると困ること：
- 仕様の根拠・期待する振る舞い：
- 未確定事項／確認先／期限：
- 判断（採用／対象外と理由／要確認）：
- 関連ケースID：

## ケース化する前のレビュー
- [ ] 観点と具体的な操作手順が混在していない
- [ ] 権限、所属、処理の状態を必要に応じて組み合わせた
- [ ] 未確定の期待結果を勝手に補っていない
- [ ] 優先するリスクと対象外の理由を説明できる
- [ ] 仕様版、観点ID、ケースIDを対応付けた

## テストケースへの展開
- ケースID／観点ID：
- 根拠となる仕様・回答：
- 事前条件とテストデータ：
- 操作：
- 期待結果（確認する内容と証拠）：
- 実行可能か／回答待ちか：

よくある質問

Excelの観点表でも使えますか？

考え方や項目は使えます。本稿のダウンロードはMarkdownであり、Excelのブックではありません。既存の表に必要な項目を追加するか、見出しを転記して使ってください。

テスト観点表とテストケースは別に必要ですか？

必ず別ファイルにする必要はありません。観点とケースの目的・粒度を区別して追えることが重要です。小さな変更なら同じ資料でも、観点IDと関連ケースIDを対応付けられます。

AIに観点を出してもらえば完成ですか？

完成ではありません。仕様に存在しない前提、重複、未確定の期待結果を人が見直します。AIの候補を全部採用した数ではなく、重要なリスクに対して根拠のある確認が設計できたかをレビューします。