Skip to content

問題28:機能適合性をテストする最適なレベル

あなたは、ユーザーの通貨取引を支援するソフトウェアを開発した企業で働いていると仮定する。そのソフトウェアの新しいバージョンが開発されている。このバージョンの主な機能は、取引量に応じて異なる金額のコミッション(手数料)を計算する機能である。さらに、ユーザーの異なるカテゴリ(初心者、中級者、エキスパート)が定義されており、そのカテゴリに応じて異なる機能が提供される。

あなたは、機能適合性のテストを作成する責任を持つテストアナリストである。

ソフトウェア開発ライフサイクルにおいて、機能適合性のテストを「最も早い段階」で実行すべきレベルを正しく定義している記述はどれか? (※2つ選択してください)

  • a) 少量の取引に対するコミッションが正しく計算されたかのテストは、コンポーネントテストで実行すべきである。
  • b) 異なるユーザーカテゴリに割り当てられた機能の適切性のテストは、受け入れテストで実行すべきである。
  • c) 新しい機能と他の取引システムとの相互運用性のテストは、システムテストで実施すべきである。
  • d) 大量の取引に対するコミッションが正しく計算されたかのテストは、システムテストで実行すべきである。
  • e) ハイレベルなビジネスプロセスに必要なカバレッジは、システム統合テストのために決定すべきである。

a) 少量の取引に対するコミッションが正しく計算されたかのテストは、コンポーネントテストで実行すべきである。

e) ハイレベルなビジネスプロセスに必要なカバレッジは、システム統合テストのために決定すべきである。


この問題は、機能適合性の3つの副特性(正確性、完全性、適切性)を、ソフトウェア開発ライフサイクル(SDLC)の「どのテストレベルで(できるだけ早く)実施すべきか」を問うています。

  • a) 正解。 計算のロジック(コミッションの計算など)に関する「機能正確性(Functional correctness)」のテストはどのテストレベルでも実施できますが、 コンポーネントテスト(単体テスト) がその「最も早い」段階となります。
  • b) 不正解。 「機能適切性(Functional appropriateness)」のテストは通常システムテストで実施されますが、統合テストの後期段階で実施されることもあります。受け入れテスト(UAT)で適切性をテストするのは、バグ修正のコストを考えると遅すぎます(最も早い段階とは言えません)
  • c) 不正解。 設問は「機能適合性(Functional suitability)」のテストについて尋ねていますが、「相互運用性(Interoperability)」はISO/IEC 25010において独立した別の品質特性であり、機能適合性の副特性ではありません。
  • d) 不正解。 選択肢(a)と同様に、大量の取引であっても計算の「機能正確性」テストはコンポーネントテストレベルで実施可能です。したがって、システムテストは「最も早い段階」ではありません。
  • e) 正解。 これは「機能完全性(Functional completeness)」に関するシラバスの記述に基づいています。システム統合テストレベルにおける機能完全性のテストは、連携されたシステム全体を通じた「ハイレベルなビジネスプロセスのカバレッジ(網羅率)」に焦点を当てることがあります。

JSTQB AL TA試験において、品質特性とテストレベルのマッピングは頻出テーマです。「シフトレフト(テストをできるだけ早期に行う)」の原則に基づいて考えましょう。

  1. 機能正確性はコンポーネントレベルから: 計算ロジックや分岐などの正確性は、コードを書いた直後(コンポーネントテスト)に検証するのが最も早く、コストも低く済みます。「システムテストまで待つ必要はない」という点が重要です。
  2. 機能適切性のテストタイミング: ユーザーにとって「使いものになるか(適切か)」は、プロトタイプやシステムテストの段階でビジネスの専門家(前回の問題26のようなケース)を交えて確認すべきです。リリース直前の受け入れテストで「やっぱり目的に合っていない」と発覚するのは、プロジェクトにとって致命的です。
  3. ISO/IEC 25010の罠(機能性と相互運用性): 旧規格(ISO/IEC 9126)では、相互運用性は「機能性」の一部でした。しかし、現行の ISO/IEC 25010 では「相互運用性(互換性の一部)」は「機能適合性」とは完全に別の主特性として独立しています。選択肢(c)は、この規格の改訂ポイントを突いた典型的な引っかけ問題です。

ビジネスプロセスのカバレッジ(選択肢e)について コンポーネントテストでの「完全性」は関数やモジュールの網羅に過ぎませんが、システム同士を繋ぐ「システム統合テスト」レベルになると、完全性の焦点は「一連の業務プロセス(ハイレベルなビジネスプロセス)が最後まで通るか(網羅されているか)」にシフトします。