境界値分析の進め方｜仕様から作る5つの手順

はじめに

「1件から100件まで登録できる」という仕様は、短くても解釈が分かれます。0件を送ったらどうするか。100件は受け付けるのか。101件では、一部だけ保存するのか、全件を拒否するのか。通常の10件で動いたことだけでは、この違いを確かめられません。

境界値分析は、値の範囲が切り替わる周辺に注目してテストを設計する技法です。ただし、数字を機械的に増減させる前に、入力の単位と期待結果を決める必要があります。この記事では、業務システムの入力検証を題材に、仕様からテストケースへ落とす5つの手順を説明します。以下の件数や画面は、説明用の架空の例です。

境界値分析と同値分割の違い

同値分割では、仕様上、同じ振る舞いになると期待する入力をグループに分け、代表値を選びます。境界値分析では、順序を持つグループの端に注目します。IPAの「同値分割、境界値分析手法の活用」は、代表値や境界付近の値を選ぶ考え方を、事前に明確にする重要性を示しています。

登録件数なら、「下限を下回る」「許容範囲内」「上限を超える」という分類ができます。範囲の中央を試すだけでなく、許可と拒否が切り替わる箇所を見ることで、「未満」と「以下」の取り違えなどを確認しやすくなります。

一方、部署名のように単純な大小関係がない項目へ、無理に前後の値を置く必要はありません。ISTQBの境界値分析の解説も、順序のある同値パーティションを適用対象としています。分類を作れることと、境界値分析が適用できることは別です。

仕様からケースを作る5つの手順

1. 対象と入力の単位を固定する

最初に「何の値を、どの入口で検証するか」を一文で書きます。架空の一括登録画面なら、「送信時の明細件数を、整数の件数として検証する」が出発点です。画面に表示された行数と、サーバーが受け取った有効な明細数が同じとは限らないため、空行の扱いも決めます。

• 数量：整数だけか、小数も受け付けるか
• 金額：円単位か、端数処理はいつ行うか
• 文字列：何を1文字として数えるか
• 日時：どのタイムゾーンと精度で比較するか

「文字数100以内」とだけ決めると、文字の数え方が異なる実装同士で判定がずれる可能性があります。先に数え方を合意し、その定義に沿うデータを用意します。小数や時刻も同じで、隣の値を選ぶための刻み幅を先に固定します。

仕様から決められないことは、テスト担当が推測で埋めません。「要確認」として責任者へ返すことも、テスト設計の成果です。

2. 許容範囲と範囲外の振る舞いを分ける

次に、入力をどう扱うかで分類します。今回は、画面から送信する明細の件数を0以上の整数として扱います。そのうち「1以上100以下なら登録でき、範囲外は登録前に全件拒否する」という仕様を仮定します。件数以外の必須項目は、正しい値に固定します。

空欄、文字列、小数は、この整数の分類とは別に扱います。実際の画面で負の件数を作れない場合、その入口では負の件数のケースを実行できません。存在しない画面操作を作るのではなく、下位の検証関数など、値を渡せる場所に応じて対象範囲を記録します。

特に重要なのは「エラーになる」で終わらせないことです。メッセージだけ出して一部が保存されていたら、今回の仕様では不合格です。表示、保存、後続処理のどこまで確認するかを分けて書きます。

3. 境界付近の値と選定方針を記録する

今回の画面例では、下限付近の0・1・2件、上限付近の99・100・101件を確認候補にします。さらに、通常の入力が動くことを見る10件のケースを別に置きます。この一覧は、画面から作れる値に絞った実務上の例であり、全入力や特定の網羅基準を満たしたと宣言するものではありません。

ISTQBの解説には2値・3値の分析があり、同値パーティションの各境界値を起点に、必要な値を導きます。「下限と上限の前後を試したから3値分析を完全に網羅した」とは限りません。厳密な網羅を求める案件では、入力領域、各パーティション、その境界値、採用した基準を順に列挙して確認します。

テストの件数だけで品質を説明せず、「どの切替条件を、どの基準で確認したか」を残しましょう。

4. 期待結果を観測できる形にする

ケースには、入力値だけでなく、前提条件と判定方法を書きます。たとえば101件のケースなら、「明細はすべて有効」「登録前に対象データが存在しない」「入力エラーが表示され、対象データは増えない」を一組にします。保存結果の確認には、テスト環境で許可された照会手段を使います。

実装結果をそのまま正解にすると、境界の誤りを見逃します。期待結果の根拠は、合意済みの仕様や受け入れ条件です。完成条件の置き方に迷う場合は、受け入れ条件から要件を整理する考え方とつなげて考えると、入力と合否判定を分けやすくなります。

画面の入力制御とサーバー側の検証も、確認対象を分けます。画面が101件目の追加を禁止していても、サーバーへ範囲外データが届いた際の振る舞いは別の確認です。ただし、未許可の本番操作や負荷の高いリクエストを、検証のために勝手に実行してはいけません。

5. 仕様変更とケースを一緒に更新する

上限が変わったとき、記事や仕様の数字だけ直しても、古いテストが残れば判断が食い違います。ケースに要件ID、仕様の版、選定方針、期待結果の根拠を付け、どの変更で見直すかを記録します。

実施済みと合格も分けて管理します。「データを送った」「画面を見た」だけでは、保存状態まで確認したことにはなりません。期待結果と実際の結果、証跡、未確認事項を残します。変更の追い方は、要件トレーサビリティの整理で扱う要件と検証のつながりにも通じます。

AIにケース候補を作らせる場合も、単位や上限を勝手に補わせない入力が必要です。AIは列挙の補助に使い、仕様の確定と合否判断を誰が担うかは別に決めます。

境界値分析だけで確認しきれないこと

単一の数値範囲を確認しても、複数条件の組み合わせや、操作順序の問題をすべて検証したことにはなりません。会員種別で上限が変わるなら、条件と結果の整理が必要です。登録後の取消や再申請が問題なら、状態と遷移を別に確認します。デシジョンテーブルの書き方は、条件の組み合わせを整理する際の補助になります。

境界のケースが合格しても、処理時間、権限、重複登録、文字の扱いなどは、別の観点として残ります。境界値分析を「これで全部確認できる手法」ではなく、入力仕様の一部を具体的に検証する道具として使いましょう。

まず一つの入力項目から仕様を確かめる

最初から全画面のケースを増やすより、件数や金額など一つの入力項目を選び、単位、許容範囲、範囲外の処理、確認する値、期待結果の5点を書いてみてください。数値を置けない箇所があれば、そこが関係者へ確認する論点です。

仕様が複数の文書や会議メモに散らばっている場合、先に合意内容を整理する必要があります。上流工程AIワークスペースKakusillは、要件定義から仕様管理までの文脈を整える選択肢です。テストを自動で網羅すると考えるのではなく、テスト設計へ渡す仕様を揃える用途から検討できます。

境界値分析で大切なのは、数字をたくさん並べることではありません。どこで振る舞いが変わり、その変化を何で確かめるかを、実装前にも説明できる状態にすることです。