「ブラックボックステスト」とはソフトウェアテストの1つで、開発されたソフトウェアが正しく動作するかを確認します。ソフトウェア開発と聞くとプログラミングを行うエンジニアが注目されがちですが、不具合の有無を確認するテストは、ソフトウェアの品質を左右するために欠かせない作業です。
この記事では、ブラックボックスとホワイトボックスの違いが分からないという方に、ブラックボックステストの概要やホワイトボックステストとの違いなどを解説しています。ソフトウェア開発に携わりたいという方は、ブラックボックスの概要やよく使用されている手法を理解して、今後のキャリア形成に役立ててください。
ブラックボックステストとは
ブラックボックステストとは、入力と出力に注目しシステムが正しく動作するか確認するテスト方法です。
例えば、レジシステムの開発を行っているとしましょう。仕様書通りに「会計」ボタンを入力して（押して）、正しく出力（会計）されるかどうかをユーザー目線で操作しながら、動作確認していきます。
仕様書通りに入力し、仕様書通りに動作すれば問題ないため、内部システムの動きなどは確認しません。このように、ブラックボックステストは入力と出力に注目し、内部構造は考慮せずにテストを行います。
ブラックボックステストにはどのような特徴がある？
システムのソースコードを考慮せずにテストを実施するブラックボックステストの特徴について気になる方も多いでしょう。ブラックボックステストの特徴は、下記の2つです。
- 対応できるテストレベルが広範囲
- 高い費用対効果
ブラックボックスの特徴について詳しく解説します。
対応できるテストレベルが広範囲
ブラックボックステストは対応できるテストレベルが広範囲です。テストレベルは段階が上がるほど、テストしなければならない機能が増えます。
テストしなければならない機能が増えるということは、それだけ機能同士の組み合わせが複雑になるため、システムの内部構造を把握することが難しくなり、テストをスムーズに実施できません。
しかし、ブラックボックスであれば、システムの内部構造を考慮する必要がないため、テストレベルが上がって内部構造が複雑になっても、仕様書があれば問題なくテストの実施が可能です。
高い費用対効果
費用対効果が高いのもブラックボックステストの特徴です。ブラックボックステストはシステムの内部構造をすべて把握していなくても、仕様書があれば問題なくテストの実施が行えます。
つまり、仕様書さえ準備されていれば、システムの開発担当者以外のメンバーでもソフトウェアテストを行えるということです。技術や知識を保有しているエンジニアなどはシステム開発に専念してもらい、開発に携わることができないメンバーがテストを行えば、時間や人件費などで高い費用対効果を期待できます。
ただ、メンバーのスキルによっては進捗にばらつきが発生し、不具合の発見漏れを起こす可能性もあります。また、不具合の発見漏れが発生した場合は動作の再確認などの作業が発生し、期待していたほどの費用対効果を得られない場合もあるため、注意が必要です。
ブラックボックステストでできること
ブラックボックステストで確認できることは、下記の2つです。
- 動作確認
- UI・UXの確認
ブラックボックステストを実施することで、動作確認をすることができます。
前述の通り、レジシステム「会計」ボタンを押すと仕様書どおりに正しく会計されるかどうか検証することができるのがブラックボックステストです。このように、ブラックボックステストを行えば入力した通りに正しく動作するかどうか確認を行うことができます。
また、UI・UXの確認を行うことが可能です。UI（ユーザーインターフェイス）は見た目や使いやすさ、UX（ユーザーエクスペリエンス）は商品を介して利用者が得られる体験のことをいいます。ブラックボックステストは実際に画面操作を行いながら、動作確認していくテストです。
そのため、利用しやすいシステム・デザインなのか、画面のレイアウトは崩れないかなど、ユーザーの視点でUI・UXの確認を行えます。
ホワイトボックステストとの違いとは？
ホワイトボックステストとは、すべてのプログラムが開発者の想定通りに動作しているかを確認するテストです。
ブラックボックステストとホワイトボックステストの違いとしては、「システム構造の把握有無」「ユーザビリティの確認有無」の2つが挙げられます。
ホワイトボックステストはシステムが想定通りに動作しているか検証する必要があるため、システム構造を正しく把握しておかなければなりません。そのため、主に開発者がテストを行います。
ブラックボックステストは仕様書に沿って操作し正しく動作するかどうか確認するテストのため、システム構造を理解しておく必要がありません。実際に操作を行う分、ユーザーに近い視点でテストを行えるため、使いやすさなどのユーザビリティを確認することも可能です。
ブラックボックステストを実施する2つのメリット
ブラックボックステストを実施する上で、次の2つのメリットが挙げられます。
- 費用対効果が高くなりやすい
- ユーザーの立場に立った検証ができる
メリット1.費用対効果が高くなりやすい
ブラックボックステストは、開発担当者でなくても実行することが可能です。そのため、開発担当者の負担が減り費用対効果が高くなりやすい特徴があります。
メリット2.ユーザーの立場に立った検証ができる
ブラックボックステストは、ユーザビリティを上げることが目的であり入出力のみに対してテストをおこないます。そのため、ユーザーが使いやすいかどうかを重要視しており、顧客満足度の向上につながります。
ブラックボックステストを実施するデメリット
ブラックボックステストは、ユーザビリティを上げるため入出力のみの確認が対象であるため、不具合を検出できない可能性があります。そこで、ホワイトボックステストを併用することをおすすめします。
ホワイトボックステストは、内部構造を確認するテストであるためブラックボックステストでは見つけられない不具合を発見できるのです。ブラックボックステストとホワイトボックステストを両方おこなうことで、不具合を把握できユーザビリティの向上にもつながります。
ブラックボックステストでよく使用される手法（参考）
ブラックボックステストでよく使用されている手法は、下記の5つです。
- 同値分割法
- 境界値分析
- 状態遷移テスト
- デシジョンテーブル（決定表）
- ユースケーステスト
ここでは、それぞれの手法について詳しく解説します。
同値分割法
同値分割法とは、有効同値と無効同値を使用して想定どおりに動作するか確認する手法です。有効同値は正常に処理される値、無効同値はエラーの値を意味します。
例えば、充電が50％を切ったら充電ゲージがオレンジ色に変化するシステム仕様でスマホを設計したとしましょう。充電が50％を切ったら充電ゲージがオレンジ色になるかどうか動作確認するのに適しているのが、同値分割法です。
充電が40％になった時、ゲージの色がオレンジになれば有効値、60％でゲージの色がオレンジになる場合や40％になってもオレンジにゲージの色が変化しないという場合は無効同値となります。
境界値分析
境界値分析とは、限界値分析ともいわれ、同値の境界を意識した手法です。
先ほどのスマホ例に当てはめてみましょう。充電ゲージがオレンジ色に変化するかしないかの境界値は49％と50％のため、49％と50％の境界値に絞って充電ゲージ色の変化有無を確認するのが境界値分析です。
ソフトウェア開発では、境界値の不具合が最も多く発生しているといわれています。そのため、境界値に絞ってテストを行う境界値分析は重要です。
状態遷移テスト
状態遷移テストとは、通常ではない状態いわゆるイベントが発生した時にソフトウェアが設計通りに動作するか確認するテストです。
ゲームで例えると、毒攻撃やまひ攻撃など状態異常を起こす攻撃を受けた際、プレイヤーの状態異常が起こるか、適切なアイテムを使用したら状態異常が回復するかを確認します。仕様を整理するために、一連の動作は状態遷移表などにまとめられることが一般的です。
デシジョンテーブル（決定表）
デシジョンテーブルとは、決定表ともいわれ、条件や動作の組み合わせをまとめた表のことです。ソフトウェアは「会計」ボタンを押したら、会計されるような1つの条件で動作するものだけではありません。
「65歳以上の高齢者であれば25％オフ」や「毎週月曜日は5％オフ」などのように、複数の条件が合わさることで動作するプログラムもあります。条件と、起こると予測される動作を整理しまとめたものが、デシジョンテーブルです。
ユースケーステスト
ユースケーステストとは、ソフトウェアの使用ユーザーや対象システムとは別のシステム目線で動作をまとめたものです。ユーザー視点に立って、ソフトウェアができることを表現することで、どんなソフトウェアなのかイメージを掴む手法をユースケースということから、ユースケーステストと名付けられました。
例えば、敵と遭遇すると「攻撃」「逃げる」「道具を使う」などの選択肢がユーザーにあるゲームのソフトウェアを開発していたとしましょう。ユースケーステストでは、ユーザーが選択できる動作をユースケース図にまとめて、設計通りに動作するかを確認します。
ブラックボックステストでは検出されにくい不具合とは？
ブラックボックステストは入力と出力に注目しているテストです。システムの内部構造は考慮しないため、下記の不具合は検出しにくいといわれています。
- 仕様で洗い出していない潜在的な不具合
- 入力の選択方法が原因で見逃す内部構造の大きな不具合
ブラックボックステストは入力に対して仕様書通りに出力されているか確認するテストです。そのため、内部プログラムの処理や制御に異常があるにもかかわらず、エラーによって正しい動作になっていた場合は問題なしと判断され、不具合を検出することができません
内部構造を考慮しないままテスト条件をこなしていくため、ソースコードの記述次第では重要な入力テストを見逃してしまう可能性があります。また、本来なら不具合になるはずが、複数の条件が重なった結果、たまたま仕様書通りの動作をした場合も、不具合として検出されない場合もあるため注意が必要です。
バランスの良いテストを行うための2つの方法
ブラックボックステストだけでなくホワイトボックステストもおこなうことが一般的です。
目的がそれぞれ異なりより効率的なテストが可能になります。それではバランスの良いテストをおこなうためにはどのような方法があるのでしょうか。ここでは、2つの方法を紹介します。
- グレーボックステストを実施する
- 双方のメリットを織り交ぜる
1.グレーボックステストを実施する
ホワイトボックステストとブラックボックステストのバランスをよくするためには、グレーボックステストをすると効果的です。グレーボックステストとは、内部構造を把握した状態で外部からの仕様を確認します。
つまり、ホワイトボックステストの要素をブラックボックステストに加えることです。そのため、グレーボックステストをおこなうためには内部の構造を把握していることがテスト実行者に求められます。
2.双方のメリットを織り交ぜる
ホワイトボックステストとブラックボックステストではそれぞれメリットが異なります。バランスをよくするためには、両方のテストの良さをおりまぜることが重要です。
ホワイトボックステストの目的である内部構造について、ブラック部ボックステストによる使いやすさなど外部からの確認を両方しましょう。しかし、プロセス数や工期などを意識しながら双方のバランスを考える必要があります。
【まとめ】ブラックボックスを理解・活用しよう
ブラックボックスは仕様書さえ準備してしまえば、システムの内部構造を理解していない開発者以外の方でも問題なくソフトウェア開発を行うことができます。
対応できるテストレベルが広範囲なため、チーム内でテストできるのはもちろん、人員が足りない場合はテスト専任スタッフを外注することで効率よく開発を進められるでしょう。本記事のポイントは、下記のとおりです。
- 内部構造は考慮せず仕様書通りに入力し出力されるかどうか確認するテスト
- 仕様書を準備すれば開発担当者でなくてもテストすることができ開発を効率よく進められる
- 正しく出力されてしまうと内部構造に不具合があったとしても検出できない
ソフトウェア開発に携わりたいという方は、ブラックボックステストの概要とホワイトボックステストの違いを最低限覚えておきましょう。
