怪しいテストってどんなテストだ......?)青木室長は今日もまた、技術的な話の内容についていけずに困っているようです。テストの目的は、テストを実施することでシステムの不具合個所をあぶり出すことにあります。ユーザーへのリリース前に不具合を検出・修正(修理)しておくことにより、リリース後の安定稼働につながります。リリース後に実際に起こるすべての項目を何度も何度も繰り返して慎重にテストしておけたら、不具合の発生確率をより低くすることができそうです。現実にはなかなかそうはいきません。銀行ATMでは日本中のあらゆる場所で、何百人(もっと多いと思いますが)ものATM利用者が、同じ瞬間に預金や引き出しを行いますが、それとそっくり同じ状況を再現したテストを実施することは現実には非常に困難です。別の例として、個人で利用するパソコンには、各利用者が思い思いにソフトウェアをインストールしたり、インターネット接続環境を設定していることが多いでしょう。このような場合、個々人のパソコンの利用・設定内容によって、特定のソフトウェアが意図した通りに動かなくなってしまうかもしれません。したことを事前に検証するために、ソフトウェア開発ベンダがあらゆる利用・設定の組み合わせを想定してテストを行うとしても限界があります。仮に、すべてを網羅するようなテストの実施準備が可能であっても、納期や予算による制約から実現が困難という場合も実際の現場では少なくありません。そこで、高品質達成という目標の下、いかに効率よくテストを実施するかという視点でのテスト戦略が重要となってきます。今回は、何種類もあるテストから比較的頻繁に目にするものについて説明してみたいと思います。ホワイトボックステストとブラックボックステストとは?まず初めに、「どういった視点(利用者的な視点、開発者的な視点など)でテストするか?」という分類という範疇(はんちゅう)のホワイトボックステストとブラックボックステストについて紹介します。身近な例として、「自動車」を取り上げてイメージを説明してみましょう。ほとんどの人は、利用者としての立場で自動車という機械に接しています。そのような皆さんにとって「自動車が正しく動くかどうか?」とは、「ハンドルを回した方向にきちんと曲がる」「スピードメーターが実際の速度を表している」のように、自身が行った操作の通りに動くかどうかということを意味します。自動車というものが何万個もの部品で構成されていることは知っていますが、だからといって、部品の1つ1つまでに及ぶ動作の確認をするわけではありません。これが「ブラックボックステスト」のイメージです。自動車の開発にかかわるエンジニアは、十分な品質の自動車を製造するための前提として、すべての部品が想定した通りに配置・動作していることを確認する必要があります。利用者が自動車を購入するときに、「この部品の耐用年数は10年ですよ」といわれても現実にそれを確認することはできません。エンジニアはこのような耐性試験や強度検査など、細部にわたって確認を行っていきます。これが「ホワイトボックステスト」のイメージです。「ホワイトボックステスト」の方が内容が細かいので、「ホワイトボックステスト」合格であれば「ブラックボックステスト」も問題ないのでは......という部分もあります。「ハンドルの遊びは適当か」「サスペンションの硬さは適当か」など、中には利用者の主観にも頼る評価項目がありますから、それらは「ブラックボックステスト」で行うのが適当な試験項目になりますね。実際のシステム開発では、「ソフトウェアは障害なく正常に操作できるんだけど、これだと業務には合っていないなぁ」みたいなことが「ブラックボックステスト」で判明するわけです。ここでの「White」は、「白い」ではなく「透明な」の訳でとらえるとイメージしやすい。システムを「箱」と置き換えたときに、画面操作や画面表示など、ユーザーとして確認できる部分(箱でいえば、外側の「面」)ではなく、まさしく箱の中身に当たる内部的な処理内容を検証するようなテスト。システムを時計に例えると、短針・長針の動きなど文字盤で見える部分ではなく、文字盤を開くと見える歯車の動きや電池との接続回路をテストしようという意図で実施する。内部的な処理内容の確認方法として、「命令網羅」(プログラム内のすべての処理手続きを必ず1回以上実施)、「条件網羅」(条件によって処理内容が変わる場合に、そのそれぞれの条件を必ず実施)などのように細かい技術的な技法がある。システム開発を委託する側としては、ホワイトボックステストの内容そのものにかかわることは少ないと思われる(内容検証には、プログラム技術についての知識が必要のため)。ホワイトボックステストとは反対概念のテストで、内部的な処理内容については関知せず、ユーザーの入力内容や操作などに応じて、意図した通りの機能実行や出力が行われることを確認するテスト。前と同じ時計に例えるなら、「0時ちょうどになると日付表示が1日進む」とか、「長針が1回転すると、短針は1時間分進む」とか時計としての機能面に着目してテスト内容を考えていくことになる。内部的な構造は関知しないために、複合的な条件が重なったときだけ発生するようなプログラム不具合は見つけにくい場合がある。通常はホワイトボックステスト/ブラックボックステストのいずれか一方だけを実施するということはなく、機能の重要性や事象発生の頻度を判断材料としながら、両方を組み合わせてテストを行うことがほとんどである。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。