図2●開発とテストのWモデル。Andreas Spillner氏のモデルをもとに筆者が修正した(オリジナルは,http://www.stickyminds.com/sitewide.asp?ObjectId=3572&Function=DETAILBROWSE&ObjectType=ARTを参照)
[画像のクリックで拡大表示]

図3●ソフトウエア・テストの全体像
[画像のクリックで拡大表示]

表1●テスト計画の例
[画像のクリックで拡大表示]

図4●筆者がMicrosoft Accessで自作した障害レポートの入力フォーム
[画像のクリックで拡大表示]

前回からの続き)

 たいていの場合,ソフトウエア・テストというと,どうやってテストをするのかといったテストの実施部分だけを思い浮かべるのではないでしょうか。しかし,テストを実施面だけでとらえていると,効果的なテストはできません。

 そこで,米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を紹介しましょう(図2[拡大表示])。このモデルでは,開発とテストは最初から並行して進んでいくプロセスとして表現しています。先ほど,「テストは同時並行的に進めるライフサイクルプロセスである」という定義を引用しましたが,まさにそのイメージがWモデルになるわけです。

 この考え方をベースに,さらにソフトウエア・テストの作業(アクティビティ)を細かいプロセスに分けたのが図3[拡大表示]です。これを見ると「テスト実施」というのが,ソフトウエア・テストの全体の中で,ほんの一部でしかないことがわかりますね。つまり,図3に挙げたそれぞれの作業を確実にこなすことで,テストをマネージメントすることができるのです*4。では,図3の各プロセスで行う作業(アクティビティ)をそれぞれ詳しく見ていきましょう。

効率のよいテストは優れたテスト戦略/設計から

 まず開発プロジェクトにおけるテストの位置付けとして,最初に考えることが「テスト戦略」です。

テスト戦略

 「ユーザーの使用頻度が高い部分を中心にテストする」「変更部分を中心にテストする」「すべてのテスト要件を確実にテストする」「イテレィティブな開発に合わせて繰り返しテストを行う」などのように,目指すべき品質に対するテストの方向性を決めます。

テスト分析(テスト対象,品質リスク)

 続いて重要なのが「テスト分析」です。作業は大きく分けて二つあります。一つは「テスト対象の分析」です。テストするシステムやソフトウエアの要件や設計を理解して,テストの対象になるテスト要件を洗い出す作業を指します。

 もう一つが「品質リスクの分析」です。これはテスト分析でわかったテスト対象の全体から,テストをどの程度行うか強弱を付ける作業です。本来ならテストすべき部分をすべて完璧にテストすることが理想ですが,現実には,時間的/経済的な制約からすべてをテストすることはできないでしょう。そんなときに,限られた時間と費用で最も価値のあるテストを実施できるように,力を入れてテストする部分と力を抜く部分を選別するわけです。これは医療における「トリアージ*5」と同じ考え方です。では,テストに力を入れるべきか入れないかを判断する基準はどうすればいいのでしょうか。その基準が「品質リスク」になります。

 品質リスクとは,「その機能が正しく動かないことによって受ける(かもしれない)損害」のことを指します。品質リスクを考える場合は,重要な機能が動かないほどユーザーの損害が大きくなるため,ユーザーが重要視している度合いと,ソフトウエアの修正コストが大きくなるため技術的に困難な度合いの二つの面からとらえるのが良いでしょう。

 このように,テストを品質リスクの軽減策の一つだと位置付け,テストの仕方を決めていくことをリスク・ベース・テストと呼びます。ここでいう“リスク”は,プロジェクト・マネジメントの文献などに出てくる「プロジェクト計画上のリスク」とは少し考え方が異なるので,混乱しないようにしてください。

テスト計画

 「テスト計画」では,図3のテスト計画の矢印より後の作業をどう行うかを決めていきます。肝になることは二つあります。

 まず一つ目が,「テスト戦略」と「テスト分析」を元にアプローチの方法を考えることです。どのようなテスト・レベル(単体,結合,システムなど)を誰が行うのか,また,どのようなテストのタイプ(ホワイトボックス・テスト,機能テスト,パフォーマンス・テスト,構成テストなど)をどのテスト・レベルで適用するのかを決めます。どんな技法で設計して,「テスト実施」を自動化するかどうか,また設計レビューやコード・レビューなどの方法も決めていきます(表1[拡大表示])。

 もう一つは,日程計画の中で「テスト・サイクル」をどう回していくかを決めることです。それには,

・いかにして効率よくテストを進めることができるか
・いかにして早く不具合を見つけることができるか
の2点を念頭においておくべきでしょう。

 テスト・サイクルは,テスト設計で作ったたくさんのテスト・ケースをどういう順番でテストしていけば,早く多くテストしていけるかを組み立てる作業です。品質目標が違えばテスト・サイクル数は変わりますし,テスト担当のスキル,テスト環境の充実具合,開発チームの体制(修正リリースがどの程度のスパンで行えるのか)によっても変わってきます*6

テスト設計

 テスト設計は,「どうやってテストするか」を考える作業です。テスト戦略,テスト分析,テストのアプローチを元にテスト・ケースを作成していきます。具体的なテスト設計の方法は,前回解説したので割愛します。

テスト・ベース・レビュー

 テスト・ベース・レビューについても前回触れていますので細かくは書きませんが,テスト実施前にテスト・ベース・レビューを行い,開発へフィードバックしてバグを予防することが,テストを効率的に行うためにとても大切な作業になります。

テスト環境/テスト・データ準備

 テスト設計が終わると,テスト環境の構築,自動テスト・スクリプトの用意,テスト・データの用意,日程計画の作成,テストを実施するメンバーへの事前教育など,テストを実施する前に多くの準備があります。また,テストを効率良く行うためのインフラになる部分の準備をして,テスト実施中の“つまらない”手戻りを少なくすることも重要です。

 例えば,テスト・ケースの実施状況を把握し,見直すべきテスト・ケースを検索できるように,テスト・ケースを管理する必要があります。そうでないと,テストの状況が見えなくなって,テストを確実に実施できなくなってしまうからです。テスト・ケースの管理には専用のツールを使うと効率的です。代表的な支援ツールとして,Test Case Manager(http://www.pb-sys.com/),e-Manager Enterprise(エンピレックス,http://www.empirix.co.jp/),Mercury Quality Center(マーキュリー・インタラクティブ・ジャパン,http://www.mercury.com/jp/)などが挙げられるでしょう。

 どのビルドでどこまでテストしたのかバージョンを管理する構成管理も必要です。構成管理を支援するツールとしては,CVS(https://www.cvshome.org/)が有名ですね。

 また,コードができてからテスト開始までの作業を効率化させる仕組みも重要です*7。Bugzilla(http://bugzilla.mozilla.gr.jp/)などのバグ・トラッキング・ツールを使い,テストで見つけたバグがどうなったのかを一目瞭然にしておくことも必要でしょう。また,テスト結果の分析(後述)のため,メトリクス用データ収集の仕組みをこれらのインフラに埋め込んでおくと,データ収集の効率が向上します。

 これらの作業をきちんと全部やろうとすると,とても面倒に感じられるかもしれません。しかし,だからこそツールをうまく活用してインフラを準備しておくことが重要なのです。

テスト結果の適切なレポートが
品質向上のカギを握る

 テスト対象のプログラムがそろって,それらをテスト環境にインストールすると,テストの開始となります。

テスト実施

 「テスト実施」のプロセスでは,テスト・ケースを日程計画に沿って実施して,結果(OK/NG)を記載していきます。NGの場合は不具合レポートを記載し,修正要求を出します。テストを行ったログ(結果)は,確実に残していかなければいけません。テスト結果こそがテストの成果物だからです。どのようなデータを使ったのか,どのようなテスト環境で動作させているのか,どのような手順で行ったかなどの情報は,もう一度同じテストを再現できるように十分な内容を残すようにします。不具合が出たときに再現できないと,開発者が修正するのが困難になりますし,テスト担当としても修正されたプログラムを再度確認する手段がなくなってしまい,手戻り工数がどんどん増えていきます。結果を確実に残すことが,無駄な手戻り工数を増やさないコツだということです。

 また,テスト・ケースを追加,修正することもあるでしょう。テストをしているとテスト対象のシステムへの理解が深まってくるので,テスト・ケースを追加したくなるものです。その場合も,追加したテストが実施結果として必ず残るようにしておきましょう。

バグの追跡

 「バグの追跡」は,ソフトウエア・テストが情報サービスとして有益な情報を流すために最も大事なアクティビティです。バグ追跡は,バグの検出からバグ・レポート(図4[拡大表示])の起票とプログラム修正結果の確認までを指します。

 前述したようにバグ・レポートはテストの成果物です。開発にバグ・レポートを提出することで,バグを取り除くことができるのです。問題になった現象を正しく再現できるように調査したうえで,開発担当がわかりやすいように記載するようにしましょう。バグの対応が適切か,バグの修正が怠っていないかなどを確認するのもテストの重要な仕事です。また,バグ・レポートの件数は品質を測定する指標として使うことができますし,バグの内容を分析し,その傾向をフィードバックすれば,長期的なバグの予防にもつながります。

 つまり,バグ・レポートをうまく使う仕組みを確立して運用できるようにすることは,テストの命だといっても過言ではありません*8

テスト結果評価・報告

 「テスト結果評価・報告」は,テストの本来の目的“ソフトウエアの品質を測定して改善する”ための情報を,開発メンバー,マネージャ,経営層に流すための作業です。大きく分けると,

・リリース(納品)のための判断材料の提供
・今後の改善のための材料の提供

の二つがあります。

湯本 剛(ゆもと つよし)
株式会社豆蔵 ES事業部

 リリース(納品)のための判断材料の提供とは,言い換えると「テストを終了してよいかどうかの判断材料の提供」です。計画したテストをどの程度実施したか,仕様変更が入った部分のテストを実施しているか,バグの発見件数は減ってきているか(バグの収束状況),バグの対応はどこまで済んでいるか,制限事項にしたバグについて課題はないかなどの様々な判断条件を使って,テストを終了してよいかを判断します。この判断はマネージャや経営者が行いますが,誤った判断をしないためにもテスト結果を元にした判断材料が重要になってきます。

 今後の改善のための材料の提供は,開発にかかわったメンバーで行う事後レビューの場で行います。バグを分析してレポートすることで,バグの傾向がノウハウとして蓄積していくようになり,開発チームはノウハウを元に“間違えないように作る”ようになれるでしょう。また,テスト担当は“間違えそうなところを先にテストする”ようにもなれます。テストをなくすことはできませんが,バグを予防するためのノウハウを共有することで,バグによる手戻りの工数が減り,“狙った工数以内に収める”ことが可能になるわけです。

次回に続く)