はじめに
現在のソフトウェア開発において、開発とQAは密接な関係にあります。
それこそ、手を取り合ってプロジェクトを進めていくのが基本となりつつあります。
しかし、開発の専門性が高いようにQAも専門性が高く、用語や意図がわからない場面は多々あるでしょう。
そんな方のため、用語の解説を行っていくシリーズです。
また、本記事は私の独断と解釈によるまとめですので、一部事実と違う点があるかもしれませんが、その際はご指摘ください。
「ホワイトボックステスト」のざっくりとした解説
「ホワイトボックステスト」の概要
コードなどの内部処理を確認し、それに基づいて設計、実装されたテストを指します。
テストコードは基本的にホワイトボックステストになります。
物理的に例えると、機械の基盤を見ながら、歯車を確認しながら作ったテストです。
「ホワイトボックステスト」の主なメリット
内部処理を直接参照するため、実装の問題を検出しやすいです。
また、静的テスト（レビュー等）でもありますので、実行可能でないコードに対しても実施できるテストです。
「ホワイトボックステスト」の詳細な解説
品質関連書籍からの引用
まずは私自身の言葉で説明するよりも正確性を大事に、世に出ている公的な書籍から引用しようと思います。
今回は「ソフトウェアテスト教科書JSTQBFoundation第5版シラバス2023対応」より引用します。
ホワイトボックステストは、システムの内部構造や実装に基いてテストケースを導出するテストタイプです。コンポーネントまたはシステムの、構造またはアーキテクチャが正しく完全であることを確認し、構造を受け入れ可能なレベルまでカバーすることが目的となります。
「ホワイトボックステスト」の概要
内部構造を理解した上で行うテスト全般を指します。
そのため、直接参照できる、
- コード
- アーキテクチャ
- ワークフロー
- システム内のデータフロー
だけでなく、構造を視覚化したドキュメントである、
- 制御フローグラフ
- コールフローダイアグラム
- 画面遷移図
- コンポーネントやシステム間のインターフェースがわかるアーキテクチャ図
を元として作成されたものが対象です。
テストレベルとしては、テストコードから受入テストまで、どのレベルでも実施することができます。
「ホワイトボックステスト」の詳細なメリット
静的テストの側面を持つため、コードが動作する前から実施することができ、バグの早期発見に寄与します。
また、コードそのものがあればよいので、仕様書が固まっていない場合や古い場合であっても（その状態が良くないのは一旦置いといて）テストが実施できます。
内部処理を確認して実施するために、カバレッジを取得することができます。
これによって、テスト網羅性についてある程度定量的な評価が可能となります。
「ホワイトボックステスト」に纏わる小噺
「ホワイトボックステスト技法」と呼ばれることがありますが、個人的には「技法」ではなく「分類」と言った方がしっくりときます。
何故ならば、「ホワイトボックステスト技法」とは他のテスト技法の総称に当たるためです。
「ホワイトボックステスト技法のテスト技法はhogeです」は、言葉として受け取りづらいです。
「ホワイトボックステスト分類のテスト技法はhogeです」の方が、わかりやすいです。
「テスト技法」と言った時にどの粒度の話をしているのか分かりづらくなるのも避けることができます。
ですので、「ホワイトボックステスト技法」とはあまり言いたくありません。