連載
» 2008年05月15日 12時00分 UPDATE

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

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

[高田,株式会社オープントーン]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここまでのキーワード

【ホワイトボックステスト(White Box Test)】  ここでの「White」は、「白い」ではなく「透明な」の訳でとらえるとイメージしやすい。システムを「箱」と置き換えたときに、画面操作や画面表示など、ユーザーとして確認できる部分(箱でいえば、外側の「面」)ではなく、まさしく箱の中身に当たる内部的な処理内容を検証するようなテスト。システムを時計に例えると、短針・長針の動きなど文字盤で見える部分ではなく、文字盤を開くと見える歯車の動きや電池との接続回路をテストしようという意図で実施する。

 

 さらには内部的な処理内容の確認方法として、「命令網羅」(プログラム内のすべての処理手続きを必ず1回以上実施)、「条件網羅」(条件によって処理内容が変わる場合に、そのそれぞれの条件を必ず実施)などのように細かい技術的な技法がある。

 

 システム開発を委託する側としては、ホワイトボックステストの内容そのものにかかわることは少ないと思われる(内容検証には、プログラム技術についての知識が必要のため)。

 

【ブラックボックステスト(Black Box Test)】 ホワイトボックステストとは反対概念のテストで、内部的な処理内容については関知せず、ユーザーの入力内容や操作などに応じて、意図した通りの機能実行や出力が行われることを確認するテスト。前と同じ時計に例えるなら、「0時ちょうどになると日付表示が1日進む」とか、「長針が1回転すると、短針は1時間分進む」とか時計としての機能面に着目してテスト内容を考えていくことになる。

 

 内部的な構造は関知しないために、複合的な条件が重なったときだけ発生するようなプログラム不具合は見つけにくい場合がある。通常はホワイトボックステスト/ブラックボックステストのいずれか一方だけを実施するということはなく、機能の重要性や事象発生の頻度を判断材料としながら、両方を組み合わせてテストを行うことがほとんどである。



       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

ピックアップコンテンツ

- PR -

注目のテーマ