ホワイトボックスとブラックボックス

ホワイトボックスとブラックボックス

こんにちは。大友です。

白い箱と黒い箱、あなたはどちらが好きですか?
白い箱と言ってもアニメやドラマの納品テープのことではないし、黒い箱と言っても玄人志向製のネットワークストレージのことではありません。

ホワイトボックスとブラックボックスとはソフトウェアのテスト工程において用いられる用語で、ホワイトボックスは「内部処理一つ一つを明らかにしてテストすること」、ブラックボックスは「内部処理に関わらず外部仕様を満たすかどうかをテストすること」を示す言葉です。

「じゃあ白がいいのかな?情報の風通しは良い方が良いんじゃないの?」と思う方もいることでしょう。

しかし、話はそう簡単ではないのです。

今回はこの2つのテスト形態のメリット・デメリットを考察していきます。

まずは両方のメリットから。

ホワイトボックステストのメリット

・ソースコードのレビューにもなるので、最終的にコードを綺麗に整え易くプログラマーの熟練度が上がる
・ソースコードのカバレッジ(網羅率)が計測できるので抜け漏れが発生し難い
・詳細設計書等の開発者用ドキュメント作成に役立つ
・予期しないエラーの原因調査時などに切り分けが楽になるため工数が圧縮し易い
…etc

つまりホワイトボックスは、
・細かい単純ミスがないか検査したり
・開発を引き継ぎ易いように設計情報を書面に纏めたり
といった「細かい抜け漏れを防ぐ・全機能を網羅する」というメリットがあります。

ブラックボックステストのメリット

・UI・UX(見た目・使い易さ)の確認ができる
・単純にソフトウェアの利用シナリオを作り、その通りにテストすれば仕様通りに動くようにできる
・シナリオの立て方によっては工数を圧縮できる
・ソフトウェアの外部仕様は基本的に、読込・入力・出力・演算・保存の5種類しかないので、内部が難しい作りのソフトウェアであってもテスト難易度は低く抑えられる
・シナリオが操作手順書(マニュアル)等の作成に役立つ
…etc

つまりブラックボックスは、
・ソフトウェアが外部仕様通りに動くか検査したり
・実際の動作環境での保証範囲を見極めたり
といった「限られた工数の中で実際に動くことを保証する」というメリットがあります。

さて、次は両方のデメリットです。

ホワイトボックステストのデメリット

・仕様洩れや実装洩れが検知できない
・全網羅するだけあってどうしても工数が大きくなってしまう
・基本的にモジュール(機能の最小単位)ごとにテストするので、幾らロジックが正しくてもモジュール間の競合や動作環境によっては仕様を保証できない
・どうしても細かいミスの指摘が増えるため、開発者の向上心や精神力がある程度強くないと耐えられない
・カバレッジ計測の効果はテスト設計者の理解度に大きく依存するため、学習コストをケチって生半可な知識でやろうとすると収拾が付かなくなる
…etc

結構あるんですよ、これが。
常に全網羅が最適解とは限らないわけです。人材も資金も時間も無限ではありませんからね。

ブラックボックステストのデメリット

・外部仕様だけを見るのでレアケースの検知が難しい
・シナリオの作り方や入力データの取り方などに様々なコツ・手法があり、テスト設計者の熟練度によって検出率・工数にバラつきがある
・安易に組み合わせテストを全てやろうとすると工数が大きくかさむ

こちらはまぁ言わずもがな、という感じですね。
テストに携わったことのある皆様なら誰しもがぶつかる悩みですよね。

まとめ

「じゃあ具体的にはどうすればいいのか?」という点については、簡単に言えば「両方の良いところを取り入れる」ということになります。

ですが、今回はあくまでメリット・デメリットを洗い出すのが主目的の記事なので…具体的なテスト設計の手法については次回記事をご期待ください。

併せて「時間とコストの問題を解決する」という、最近流行りの「テスト自動化」についても書きたいですが、これも一大ビジネスになっているだけあって書き出すと完全に脱線してしまうので、要望があったら別の記事で書きたいところです。

何か認識間違ってる部分や解り難い記述があれば、ご指摘頂けるとありがたいです。

ついでに「需要あるよ」ってコメントがあるとより執筆意欲が出ますのでよろしくお願い致します。(笑)

コメント