筆者が講師を務めるテストの基本を学ぶためのトレーニングでテストの主目的としているのは次の3つです。

・不具合の摘出:できるだけたくさんの故障や欠陥を摘出する。

・動作の確認/品質の保証:要求や仕様などの検証/評価をテストで網羅することで品質を保証する。

・欠陥の予防:テスト設計や実施の知見を開発の早期から生かし、欠陥の作り込みを予防する。

上記それぞれの目的をすべて満たすことができるテスト手法や技法があれば理想的と思われるかもしれませんが、ソフトウェア開発の課題を一度に解決できる「銀の弾丸」がないように、テストでもそのような万能なものは存在しません。

手法や技法には得手、不得手があり、それぞれ特徴を持つため、テストを計画/設計する時は目的に応じてうまく使い分けたり、組み合わせたりする必要があります。次に紹介するリスクベースドテストは新たなアプローチと言えるでしょうし、グレーボックステストは改良されたものと言えるでしょう。

リスクベースドテスト

リスクは一般的に「悪い結果になってしまう可能性のこと」を指します。 ISTQBによると、テストの領域でのリスクは大きく2つに分けられています。

1つはプロジェクトリスクで、マネジメント全般へ悪影響を及ぼし得るリスクを指します。もう1つはプロダクトリスクで、テスト対象の製品やサービスの品質に悪影響を及ぼし得るリスクです。

リスクベースドテストの考え方では、テスト対象のプロダクトリスクを把握するとともに、リスクが現実となる可能性が高い機能や領域(コンポーネント、サブシステム、モジュールなど)を明らかにしていきます。その上で、プロダクトリスクごとに発生確率や影響度、リスクが現実となった時の損失額などを用いて優先度を割り当てます。

欧米的アプローチでは、「優先度の低いリスクに対するテスト設計/実施を行わない」という取捨選択を行います。日本では、リスクを明らかにした上で「テストで手を抜くと具体的にどんな"痛い目"に合いそうなのか」を明確にするというアプローチでこの考えを取り入れるべきだと思います。つまり、テストに対するリソース(技術者、予算やテスト環境など)を確保するためにリスクベースドテストのアプローチを利用しよう、という考え方です。

グレーボックステスト

ホワイトボックステストとブラックボックステストの説明は今さら必要ないかもしれませんが、グレーボックステストは聞き慣れない用語かもしれません(図1)。

図1 グレーボックステスト

グレーボックステストは、「内部仕様すべてをガラス張りで知る必要はないが、ブラックボックスのように内部仕様をまったく見ないわけではないテスト」のことです(ISTQBでは定義されていないのですが、テストの世界では一般的に使われている用語です)。

グレーボックステストのアプローチを取り入れる上で大切なことは、ホワイトボックス/ブラックボックステストでどのようなことが検証できていて、どのようなことが検証できない(難しい)のかを整理/理解しておくことです。その上で、モジュール間の処理の流れを検証したり、アーキテクチャ全体の整合性を確認したりする時などに適用すれば効果が上がります。

今回説明できなかった「全体」に関わるアプローチは次回以降で説明します。

執筆者プロフィール

大西建児 (Kenji Onishi)
株式会社豆蔵 シニアコンサルタント。国内電機メーカー、外資系通信機器ベンダーで培ったテストや品質保証などの経験を生かし、テスト手法や技術の普及、発展に取り組む。NPO法人ソフトウェアテスト技術振興協会(ASTER)副理事長。JaSST’08東京 共同実行委員長。著書に「ステップアップのためのソフトウェアテスト実践ガイド」(日経BP社)などがある。

『出典:システム開発ジャーナル Vol.3(2008年3月発刊)
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。