第9回　テストで重要なのは見極めること：キーワードでわかるシステム開発の流れ（1/3 ページ）

　開発青木室長と赤井君の活躍のほか、開発ベンダの若井さんのサポートなどもあり、ようやく製造工程も終了に近づきました。前回の「やってはいけない、『製造工程』の丸投げ」で、発注担当者の開発ベンダへのかかわりあい方などについて解説しました。今回はテスト工程がテーマです。テスト工程では、どんなことに気を付けるべきかなどについて説明していきたいと思います。

どのようなテストを実施すればよい？

　青木室長と赤井君の凸凹コンビによるA社初の試みとなるインターネットショップ開発プロジェクト。システム開発経験のない青木室長を、SE経験を持つ赤井君が支えながら、数カ月。開発ベンダによる製造工程が予定通りに進み完了も間近のためか、開発ベンダの責任者である若井さんにも心なしか安堵（あんど）の表情が見られます。

　プロジェクトは、いよいよ「テスト工程」です。

　そんなテスト工程に入る前の、○月△日 A社302会議室での最終デモの様子です。

若井さん　「……（省略）……といった内容で、今回開発した機能・画面の説明は終わりです」

青木室長　「いやぁ、ご苦労さまでした。若井さんがスケジュール通りに進めてくれたおかげで、私たちも胸を張って社長に報告することができますよ。な、赤井君」

赤井君　「本当ですね。途中、仕様変更などもあり大変だったと思いますが……。本当にありがとうございます。ところで、これからのテストについての詳細プランを説明してほしいのですが、どのような予定ですか？」

若井さん　「現状実施中のテストとして、製造工程ごとの機能や画面ごとの処理内容およびデータの入出力に関する一通りのテストは実施し完了しています」

赤井君　「つまり、単体テストは完了ということですね」

若井さん　「そうですね。機能や画面それぞれを単位とした場合の単体テストということになります。それより少し早く、ホワイトボックステストとして、プログラム内部の構造的なまとまりを単位とした場合の単体テストと結合テストも完了しています。画面単位の単体テストでは、テストNG項目が残存していますので、まずはそれらを修正後に、回帰テストを含めた再テストを実施して不具合を解消した後に、画面間の結合テストを実施予定です」

赤井君　「状況は分かりました。では、画面間の結合テストが終わりそうなころに、システムテストや運用テストの実施方法について調整させてください。システムテストや運用テストの後半は、操作トレーニングを兼ねて、実際の利用部門の代表者に手伝わせたいと考えています」

若井さん　「分かりました。まずは、画面間の結合テストでしっかり品質向上を図りたいと思います」

赤井君　「お願いします。……という段取りでよいですよね、青木室長？」

青木室長　「そうだなー、んー……」（「カイキテスト」って何だ？　快気テスト？ 怪奇テスト？ 怪しいテストってどんなテストだ……？）

　青木室長は今日もまた、技術的な話の内容についていけずに困っているようです。

　テストの目的は、テストを実施することでシステムの不具合個所をあぶり出すことにあります。ユーザーへのリリース前に不具合を検出・修正（修理）しておくことにより、リリース後の安定稼働につながります。ですから、リリース後に実際に起こるすべての項目を何度も何度も繰り返して慎重にテストしておけたら、不具合の発生確率をより低くすることができそうです。

　しかしながら、現実にはなかなかそうはいきません。例えば、銀行ATMでは日本中のあらゆる場所で、何百人（もっと多いと思いますが）ものATM利用者が、同じ瞬間に預金や引き出しを行いますが、それとそっくり同じ状況を再現したテストを実施することは現実には非常に困難です。別の例として、個人で利用するパソコンには、各利用者が思い思いにソフトウェアをインストールしたり、インターネット接続環境を設定していることが多いでしょう。このような場合、個々人のパソコンの利用・設定内容によって、特定のソフトウェアが意図した通りに動かなくなってしまうかもしれません。

　こうしたことを事前に検証するために、ソフトウェア開発ベンダがあらゆる利用・設定の組み合わせを想定してテストを行うとしても限界があります。仮に、すべてを網羅するようなテストの実施準備が可能であっても、納期や予算による制約から実現が困難という場合も実際の現場では少なくありません。

　そこで、高品質達成という目標の下、いかに効率よくテストを実施するかという視点でのテスト戦略が重要となってきます。

　今回は、何種類もあるテストから比較的頻繁に目にするものについて説明してみたいと思います。

ホワイトボックステストとブラックボックステストとは？

　まず初めに、「どういった視点（利用者的な視点、開発者的な視点など）でテストするか？」という分類という範疇（はんちゅう）のホワイトボックステストとブラックボックステストについて紹介します。

　身近な例として、「自動車」を取り上げてイメージを説明してみましょう。ほとんどの人は、利用者としての立場で自動車という機械に接しています。そのような皆さんにとって「自動車が正しく動くかどうか？」とは、「ハンドルを回した方向にきちんと曲がる」「スピードメーターが実際の速度を表している」のように、自身が行った操作の通りに動くかどうかということを意味します。自動車というものが何万個もの部品で構成されていることは知っていますが、だからといって、部品の1つ1つまでに及ぶ動作の確認をするわけではありません。これが「ブラックボックステスト」のイメージです。

　一方、自動車の開発にかかわるエンジニアは、十分な品質の自動車を製造するための前提として、すべての部品が想定した通りに配置・動作していることを確認する必要があります。利用者が自動車を購入するときに、「この部品の耐用年数は10年ですよ」といわれても現実にそれを確認することはできません。しかし、エンジニアはこのような耐性試験や強度検査など、細部にわたって確認を行っていきます。これが「ホワイトボックステスト」のイメージです。

　「ホワイトボックステスト」の方が内容が細かいので、「ホワイトボックステスト」合格であれば「ブラックボックステスト」も問題ないのでは……という部分もあります。

　しかし、例えば「ハンドルの遊びは適当か」「サスペンションの硬さは適当か」など、中には利用者の主観にも頼る評価項目がありますから、それらは「ブラックボックステスト」で行うのが適当な試験項目になりますね。実際のシステム開発では、「ソフトウェアは障害なく正常に操作できるんだけど、これだと業務には合っていないなぁ」みたいなことが「ブラックボックステスト」で判明するわけです。

図1　ブラックボックステストとホワイトボックステストの違いは理解しておきたい

ここまでのキーワード