システム開発の基礎｜要件から確認条件を作る

この分野で身に付けること

• 要件、設計、実装、テストの成果物と目的を区別できる。
• 境界値を、仕様で許される範囲の内外から選べる。
• 変更後に回帰テストが必要な理由を説明できる。

1. 要件は、利用者が確認できる条件へ言い換える

「高速にする」「使いやすくする」のような言葉だけでは、完成を判断しにくいことがあります。誰が、どの操作をし、どの結果を得るかを具体化し、確認可能な条件にします。機能要件は何をできるようにするか、非機能要件は性能・安全性・運用性などの条件を表すことがあります。

テストは実装の細部を当てる作業ではなく、仕様が満たされるかを確かめる作業です。問題文に「1以上100以下」のような制約があれば、正常な代表値だけでなく、1、100、その外側の0、101が重要な確認候補になります。

2. テストは、何を検証するかで選ぶ

単体テストは小さな部品の動作を確かめ、結合テストは部品どうしの連携を確かめます。システムテストや受入テストでは、利用者の目的や業務の流れに照らすことがあります。名称だけを丸暗記せず、どの範囲を対象にしているかで選びます。

境界値分析は、範囲の端で起こりやすい誤りを見つける考え方です。値を少しずつ全部試す代わりに、境界の内側と外側を代表として選びます。等価分割と組み合わせる場合も、問題が何を代表値としているかを読んで判断します。

3. 変更は、追加した部分以外にも影響する

一つの機能を変更すると、その機能を呼び出す画面や、共通のデータ形式、例外処理などへ影響することがあります。回帰テストは、以前は正しく動いていた部分が変更で壊れていないかを確認するためのテストです。新機能の確認だけで終わらせない理由を理解しましょう。

変更要求には、内容だけでなく影響範囲、優先度、費用や納期への影響、確認方法を整理します。実装を急ぐことが常に正しいわけではありません。合意された要件と、実際に検証できる条件を保つことが品質につながります。

用語・考え方の比較

例：年齢を1〜100で受け付ける入力欄

仕様が「1以上100以下の整数」と定めている場合の確認を考えます。

1. 範囲内の代表値として50を選び、受け付けられることを確認する。
2. 下限と上限の1、100を選び、どちらも受け付けられることを確認する。
3. 境界の外側0、101と、整数ではない値を選び、仕様どおり扱われることを確認する。

ここで確認：端の内側と外側を対にすると、境界値の狙いを説明できます。

確認してから、演習へ進む

間違えやすいポイント

• 正常な代表値だけを試して、範囲の端を確認しない。
• 新機能が動けば、既存機能の確認は不要だと考えない。
• テスト段階の名前だけで、対象範囲を判断しない。

自分で確かめる三つの手順

1. 仕様中の数値範囲に、内側・端・外側の候補を書き込む。
2. 各テストケースに「何を確認するためか」を一文で添える。
3. 変更した部品から影響を受ける画面やデータを矢印で結ぶ。