ブラックボックステストとは
ブラックボックステストとは、仕様書などからテストすべき項目を洗い出し、システムの内部構造を考慮せずに実施するテスト技法です。
ソフトウェアテストを行う際、テスト対象やテスト観点、テスト条件などのテストケースを事前に作成します。ブラックボックステストでは、テストケースを作成する際にシステムの内部構造であるソースコードがどのように構築されているのかは考慮せず、テストケースの作成を行い、テストを実行します。そのため、開発に関係した人物ではない第三者がテストを行うことも可能です。
ブラックボックステストとホワイトボックステストの違い
ブラックボックステストと類似した言葉に、「ホワイトボックステスト」があります。両者ともにソフトウェアテストの技法のひとつですが、違いは着目点です。
ブラックボックステストが、内部構造を考慮せずに行うテストであるのに対し、ホワイトボックステストは、システムの内部構造が正しいかを確認するテスト技法です。そのため内部構造を理解することができないと実施が困難になるため、多くの場合、開発者自身が行います。また実施の際、ソースコード内の条件が分岐する箇所においては不具合が発生しやすいので、注意する必要があります。
言い換えれば、ブラックボックステストは実際のユーザー視点からの確認に近く、ホワイトボックステストは、プログラム構造に問題がないかの開発者側の視点で行われるテストなのです。両者はそれぞれできることや着眼点が異なるため、両方実施することが求められます。
あわせて読みたい
＞＞ホワイトボックステストとは？ブラックボックステストとの違いやその手順、よく使われる手法を解説のページへ
ブラックボックステストの特徴
対応できるテストレベルが広い
テストレベルの段階が進めば進むほどテストすべき機能の組み合わせがより複雑になるため、すべてのシステムの内部構造を把握した状態でのテストは難しくなります。
ブラックボックステストは内部構造を理解していない場合でも、仕様書があればテストを実施することが可能で、テストレベルのどこでも利用ができます。
テスト仕様書に関してはこちらもご覧ください。
＞＞テスト仕様書の書き方～テストケース作成のポイント～のページへ
費用対効果が高い
ブラックボックステストは、費用対効果が高いという特徴もあります。プロジェクトの予算や仕様などの状況に合わせたテスト全体の最適化を行い、高品質で効率的なテストを実施することで、コストを抑えつつ、ソフトウェアの品質を高めることもできます。
＞＞「品質」は誰が決めるもの？～改めて「品質」を考えてみる～のページへ
ソフトウェアの開発者は、開発に関する技術や知識を用いて業務を行いますが、ブラックボックステストの実施には専門的な開発の技術や知識はそれほど多く必要ありません。そのため、開発者以外が担当することができ、外部に委託することも可能です。結果、開発者と比較して人件費を低く抑えることができるでしょう。
特に、仕様書などを参考にして行うテストの場合、仕様書が読めればある程度までテストの設計や実施が可能です。加えて、開発した人ではない第三者がテストすることによって、思い込みなどにとらわれず、客観的なテストを行うことにもつながります。
しかし、スキルや経験のばらつきなどが要因で、不具合の検出結果が属人的になる、漏れが生じてしまうなどの可能性もあるでしょう。もし、手戻りが発生するなど非効率的なテストになってしまうと、必要以上の経費がかさんでしまう事態も考えられます。
そのような事態を防ぐために、プロジェクトの予算や仕様などの状況に合わせたテスト全体の最適化を行い、高品質で効率的なテストを行うソフトウェアテストの代行をする会社に委託するのがよいでしょう。それにより結果的にコストを抑えることができ、かつソフトウェアの品質を高めることもできます。
さらにソフトウェアテストを代行する会社には、ECサイトや業務システムをはじめとするさまざまなサービス形態に対して、不具合が起きやすい箇所に対する知見があります。数多くのテスト実施によって得た知識やノウハウが発揮されるため、テストの精度が高く、このような点も依頼を行うメリットのひとつとなります。
ソフトウェアテストを代行する会社をお探しでしたら、まずはSHIFTにお問い合わせください。
＞＞お問い合わせページへ
料金についてはこちらから
＞＞料金についてページへ
SHIFTのサービスについてや導入事例に関してはこちら
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
ブラックボックステストにおいてよく使用される技法
ブラックボックステストにおいて、よく使用されるテスト技法があります。代表的なものは以下です。
・同値分割法
・境界値分析
・デシジョンテーブルテスト
・状態遷移テスト
・組み合わせテスト
それぞれどのようなテストなのか、詳細を確認していきましょう。
同値分割法
同値分割法とは、ブラックボックステストの技法のひとつで、同値領域から代表値を実行するテストケ－スを設計するものです。
有効または無効のような同様の結果をもたらす値を、それぞれ「同値クラス」として分類し、最低1回各同値クラスのグループから実行するように設計するのが原則となります。代表値の結果が、同値クラスのほかの値にも同様の結果をもたらすと考えます。
これによりテストケースを限りなく少なくし、効率よく不具合を発見するための技法です。
境界値分析
境界値分析とは、同値クラスの両端にあたる境界値を基にしてテストを行う技法です。境界値分析もブラックボックステストの技法のひとつで、仕様に定められている条件の境界値を基にして行うテスト技法です。境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端にあたる値を指します。
具体的には「未満」や「以下」などが該当します。こういった境界部分は、ソフトウェア開発において間違いを引き起こしやすく、不具合につながりやすいため、境界値分析で検証する必要があるのです。
＞＞境界値分析とは？流れやおさえておきたいポイントをわかりやすく解説のページへ
デシジョンテーブルテスト
デシジョンテーブルテストとは、対象が取り得るステータスや動作・入力値といった条件を組み合わせ、どのような結果となるのかを表で整理したデシジョンテーブルを使用して行うテスト技法です。使用上の条件を漏れや重複なく洗い出し、論理的に発生しうる組み合わせでテストを行うため、網羅性が高いという特徴があります。
複雑な条件や組み合わせを要するシステムの場合は、テストケースが増え、デシジョンテーブルの作成に時間がかかることがあります。反面、条件や結果の複雑な組み合わせを整理することで、網羅性の高いテストを実施することができます。
＞＞デシジョンテーブル（決定表）とは？メリットや書き方をわかりやすく解説のページへ
状態遷移テスト
組み合わせテスト
組合せテストとは、ある入力条件（因子）と値（水準）を組み合わせてチェックするテスト技法です。
ただ、もしそのシステムにおけるすべての入力条件と値を組み合わせてテストを実施しようとすると膨大な数になることもあり、実施すること自体が難しい場合もあります。そのため、オールペア法（n因子間網羅）や直交法などの技法を活用し、テストケースを削減して実施することが一般的です。
＞＞テスト設計基礎(機能テスト編)テスト設計手法の適切な使い方～2因子間網羅～のページへ
ブラックボックステストで発見されづらい不具合
ブラックボックステストだけでは、不具合の発見が難しいケースも存在します。具体的には以下のようなケースです。
・仕様自体が矛盾している、もしくは間違っているケース
・仕様変更の際に記載されなかった条件
・非機能的な要件（同時アクセスが起きたときに発生する要件、サーバーやデータベースの状態によって発生する要件などがあります）
仕様自体が矛盾している、もしくは間違っているケース
ブラックボックステストだけでは、仕様が矛盾していたり間違っていたりしてもわからない場合があります。ブラックボックステストは、仕様書に記載されている入出力が正しいかどうかを確認するテストです。そのため、仕様書そのものに問題があっても発見しにくく、矛盾や間違いに気が付かない可能性があります。
ブラックボックステストでは見えないこういった部分を明確にするには、仕様書のレビューやインスペクションを行うといいでしょう。レビューやインスペクションで仕様書間のトレーサビリティを確認することで、仕様の矛盾や間違いを検出できます。
仕様変更の際に記載されなかった条件
仕様変更があった場合、本来は仕様書がメンテナンスされていくべきなのですが、諸事情で仕様書への変更の記載が漏れてしまうケースがあります。仕様変更が起こった際に記載されなかった条件は、仕様書通りかどうかを確認するブラックボックステストでは見抜けない可能性があります。ブラックボックステストではその条件を見ることはないため、新たに変更や追加があったものでも正常に動作してしまえば見過ごされてしまうケースもあるのです。
こちらは、ホワイトボックステストを用いたテストが必要になるでしょう。ソースコードの差分を確認することで、仕様書に書かれていない変更があってもすぐに発見することができます。基本的には、ブラックボックステストとホワイトボックステストは組み合わせて行うのがベストです。
非機能的な要件
非機能的な要件とは、同時アクセスやサーバーの可用性など、機能に対する要件とは異なる要件のことです。ブラックボックステストはあくまでも該当するソフトウェアが正しく動作するかを確認するテストであり、環境面などの非機能的な要件は考慮しません。そのため、実践環境で非機能的な要件が発生したと仮定しての動作確認ができないのです。
対策としては、以下のテストを同時に行うことが求められます。
・負荷テスト
・キャパシティテスト
・ロングランテスト など
このようなテストを実施することで、ブラックボックステストだけではわからない非機能的な要件の確認もできます。手間はかかりますが、品質の高いソフトウェアを完成させるためには必須の工程といえるでしょう。
関連サービスについて
まとめ
ブラックボックステストは、よりユーザーの目線に近い形で行われるテスト技法です。品質の高いソフトウェアを提供するために欠かせないテストである一方、ブラックボックステストだけでソフトウェアの品質を保てるわけではありません。ホワイトボックステストやそのほかのテストと組み合わせて行うことで、より高い品質を維持したソフトウェアを提供できるのです。
SHIFTでは、ソフトウェアテストのみのご依頼も可能です。ブラックボックステストを第三者に依頼するメリットも記事中でお伝えしましたが、開発者とは異なる人物がテストを実施することで、先入観にとらわれない結果を得られるでしょう。今まで積み重ねたテスト実績と蓄積した事例をもとに、質の高いソフトウェアテストが可能です。
ソフトウェアテストでお困りの方、ソフトウェアの品質を向上させたい方は、ぜひSHIFTまでご相談ください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
監修
株式会社SHIFT
「ヒンシツ大学」クオリティ エヴァンジェリスト 永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
ダウンロード
