仕様変更時のテスト観点：影響範囲を見直す5つの手順

1. 仕様の差分を「適用条件」まで書く

あるSaaSで、プランの保存上限を100件から50件に変更するとします。すでに80件を保存している利用者がいる、という条件を置きます。

数値の差は明確ですが、それだけでは期待結果を決められません。既存の80件を保持できるのか、編集も止めるのか、いつから新ルールを適用するのかは別の判断です。

• 対象：新規契約だけか、既存契約も含むか。
• 数える範囲：契約単位か、ワークスペース単位か。下書きや削除済みデータを含むか。
• 発効条件：日時、契約更新、プラン変更など、何を境に切り替わるか。
• 既存データ：上限を超えた分は保持、削除、読み取り専用など、どの扱いか。

不明な項目は、テスターやAIがもっともらしいルールで補完しません。「決まっていない」と分かる状態でレビューに持ち込みます。

2. 変更の影響を受ける状態を並べる

次に、変更を受ける対象を三つの軸で整理します。すべての組み合わせを機械的にケース化するのではなく、リスクのある組み合わせを選ぶための下準備です。

1. データの状態：上限未満、上限ちょうど、旧ルールでは有効だった上限超過。
2. 操作の時点：発効後に開始、発効前に開始して発効後に確定、すでに完了。
3. 操作の入口と権限：画面、API、インポートなどの入口と、追加・編集を許可された役割。

存在しないAPIや使っていないバッチまで対象にする必要はありません。自分の製品にある入口だけを残します。たとえば閲覧者が追加できない仕様なら、上限の前に権限で拒否される条件も区別します。

3. 観点をマトリクスで照合する

以下は、今回の変更で確認候補にする観点です。「要確認」は不合格でも対象外でもなく、期待結果を決めるための仕様判断が残っていることを示します。

この表は網羅表ではありません。たとえば、復元したデータを件数に含める仕様なら復元操作を追加します。件数制限ではなく容量制限なら、対象となるデータや境界の設定も変わります。自分の仕様に照らして行を足したり、理由を付けて除外したりしてください。

4. 未確定事項とテストケースを分ける

「80件を保存している利用者は、新しい50件上限でも既存データを編集できる」を、そのまま期待結果にしてしまうと、それが合意済みの仕様なのか提案なのかが分からなくなります。

先に確認事項として、質問・影響・確認先を一組で残します。

回答待ちのままでも、入力条件やテストデータは準備できます。ただし期待結果が未確定のケースを「準備完了」「実行可能」と同じ扱いにしません。期限までに決まらない場合は、何が判断できないかをリリース判断者へ伝えます。

5. 期待結果の根拠を残す

ここからは、仕様決定者が「上限超過の既存契約でも閲覧と件数を増やさない編集は許可し、新規追加は拒否する」と回答した、と仮定します。これは例のために置いた判断であり、一般的な正解ではありません。

既存ケースは、維持・変更・追加・廃止候補に分けてレビューします。単純な文字列置換で「100」を「50」に変えると、旧ルールで作られたデータを扱う条件まで失うおそれがあります。

仕様とテスト条件・ケースを結び付ける考え方は、ISTQBのFoundation Levelシラバス1.4.4でも説明されています。トレーサビリティは変更の影響を判断する手掛かりになります。本稿の具体例、手順、チェックリストはKanten独自の解説です。

持ち帰れるチェックリスト

次の書式をコピーして、ひとつの仕様変更から試してください。システムや契約に固有のルールは、担当者の判断に合わせて書き換えます。

# 仕様変更のテスト観点レビュー

変更ID：
参照する仕様と版：
変更前のルール：
変更後のルール：
適用開始の条件（日時・タイムゾーン・契約状態など）：

## 影響を受ける対象
- 新規のデータ／既存のデータ：
- 開始前／処理中／完了済みの操作：
- 画面／API／インポート／バッチなどの入口：
- 所有者／編集者／閲覧者などの役割：

## 観点ごとの判断
機能・操作：
観点（確認したいリスク）：
条件と既存データの状態：
期待する振る舞い：
根拠となる仕様の箇所：
判断：対象／対象外／要確認
判断の理由：
確認先と回答期限：
関連する既存ケース：維持／変更／追加／廃止候補
実行時に確認する証拠：

## レビューの終了条件
- 仕様で確定した内容と、提案・推測を分けた
- 既存データと処理中の操作に適用するルールを確認した
- 高リスクな未確定事項に確認先と期限を設定した
- ケースと仕様のつながりを辿れるようにした
- 未解決事項と残存リスクをリリース判断者に伝えた

この書式はKanten独自のレビュー補助です。網羅性や不具合の不在を保証しません。
Kantenの画面項目や自動ワークフローそのものではありません。