はじめに
現在のソフトウェア開発において、開発とQAは密接な関係にあります。
それこそ、手を取り合ってプロジェクトを進めていくのが基本となりつつあります。
しかし、開発の専門性が高いようにQAも専門性が高く、用語や意図がわからない場面は多々あるでしょう。
そんな方のため、用語の解説を行っていくシリーズです。
また、本記事は私の独断と解釈によるまとめですので、一部事実と違う点があるかもしれませんが、その際はご指摘ください。
「ブラックボックステスト」のざっくりとした解説
「ブラックボックステスト」の概要
機能を表現したドキュメントや機能そのものに基づいて設計、実装されたテストを指します。
物理的に例えると、ストップウォッチを分解したりリバースエンジニアリングせず、そのままを元に作ったテストです。
「ブラックボックステスト」の主なメリット
内部処理に基かないため、ソフトウェアであればコーディング技法に当たるような、製作技法に対する知識がなくともテストを実行できます。
また、コードや実物が無い状態でも、仕様書などをテストすることができます。
「ブラックボックステスト」の詳細な解説
品質関連書籍からの引用
まずは私自身の言葉で説明するよりも正確性を大事に、世に出ている公的な書籍から引用しようと思います。
今回は「ソフトウェアテスト教科書JSTQBFoundation第5版シラバス2023対応」より引用します。
ブラックボックステストは仕様に基づくもので、テスト対象の外観を示す文書からテストを導出するテストタイプです。システムの動作を、その仕様に照らしてチェックすることが目的となります。
「ブラックボックステスト」の概要
機能テストや非機能テスト全般を指します。
「どのように動作するのか」ではなく「何をするのか」をテストするため、
- 要求仕様書
- ユースケース（仕様書）
- 機能仕様書
- ユーザーストーリー（シナリオ）
といったドキュメントが元になります。
テストレベルとしては、テストコード以外すべてのレベルで実施することができます。
「ブラックボックステスト」の詳細なメリット
仕様書があればテストを実施できるため、開発の開始前から実施することができます。
開発は、仕様に誤りがあると大きな手戻り要因となりますが、それを防ぐことができます。
また、ブラックボックステストに必要なのはコードではなく仕様を記したドキュメント類のため、ブラックボックステストを促進することで、ドキュメンテーション文化を醸成することができるかもしれません。
「ブラックボックステスト」に纏わる小噺
「ホワイトボックステスト」と同様に、「ブラックボックステスト技法」と呼ばれることがありますが、同様に「技法」ではなく「分類」の方がよいでしょう。
「ブラックボックステスト」に連なるテスト技法は、聞き馴染みがあるかもしれません。
- 同値分割法
- 境界値分析
- デシジョンテーブル
このあたりが「ブラックボックステスト」のテスト技法にあたります。