基礎から学ぶソフトウエア・テスト
基礎から学ぶソフトウエア・テスト（5）テストのマネージメントとレポート
（前回からの続き） たいていの場合，ソフトウエア・テストというと，どうやってテストをするのかといったテストの実施部分だけを思い浮かべるのではないでしょうか。しかし，テストを実施面だけでとらえていると，効果的なテストはできません。 そこで，米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を紹介しましょう（図2[拡大表示]）。このモデルでは，開発とテストは最初から並行して進んでいくプロセスとして表現しています。先ほど，「テストは同時並行的に進めるライフサイクルプロセスである」という定義を引用しましたが，まさにそのイメージがWモデルになるわけです。 この考え方をベースに，さらにソフトウエア・テストの作業（アクティビティ）を細かいプロセスに分けたのが図3[拡大表示]です。これを見ると「テスト実施」というのが，ソフトウエア・テストの全体の中で，ほんの一部でしかないことがわかりますね。つまり，図3に挙げたそれぞれの作業を確実にこなすことで，テストをマネージメントすることができるのです＊4。では，図3の各プロセスで行う作業（アクティビティ）をそれぞれ詳しく見ていきましょう。 効率のよいテストは優れたテスト戦略/設計からまず開発プロジェクトにおけるテストの位置付けとして，最初に考えることが「テスト戦略」です。 テスト戦略「ユーザーの使用頻度が高い部分を中心にテストする」「変更部分を中心にテストする」「すべてのテスト要件を確実にテストする」「イテレィティブな開発に合わせて繰り返しテストを行う」などのように，目指すべき品質に対するテストの方向性を決めます。 テスト分析（テスト対象，品質リスク）続いて重要なのが「テスト分析」です。作業は大きく分けて二つあります。一つは「テスト対象の分析」です。テストするシステムやソフトウエアの要件や設計を理解して，テストの対象になるテスト要件を洗い出す作業を指します。 もう一つが「品質リスクの分析」です。これはテスト分析でわかったテスト対象の全体から，テストをどの程度行うか強弱を付ける作業です。本来ならテストすべき部分をすべて完璧にテストすることが理想ですが，現実には，時間的/経済的な制約からすべてをテストすることはできないでしょう。そんなときに，限られた時間と費用で最も価値のあるテストを実施できるように，力を入れてテストする部分と力を抜く部分を選別するわけです。これは医療における「トリアージ＊5」と同じ考え方です。では，テストに力を入れるべきか入れないかを判断する基準はどうすればいいのでしょうか。その基準が「品質リスク」になります。 品質リスクとは，「その機能が正しく動かないことによって受ける（かもしれない）損害」のことを指します。品質リスクを考える場合は，重要な機能が動かないほどユーザーの損害が大きくなるため，ユーザーが重要視している度合いと，ソフトウエアの修正コストが大きくなるため技術的に困難な度合いの二つの面からとらえるのが良いでしょう。 このように，テストを品質リスクの軽減策の一つだと位置付け，テストの仕方を決めていくことをリスク・ベース・テストと呼びます。ここでいう“リスク”は，プロジェクト・マネジメントの文献などに出てくる「プロジェクト計画上のリスク」とは少し考え方が異なるので，混乱しないようにしてください。 テスト計画「テスト計画」では，図3のテスト計画の矢印より後の作業をどう行うかを決めていきます。肝になることは二つあります。 まず一つ目が，「テスト戦略」と「テスト分析」を元にアプローチの方法を考えることです。どのようなテスト・レベル（単体，結合，システムなど）を誰が行うのか，また，どのようなテストのタイプ（ホワイトボックス・テスト，機能テスト，パフォーマンス・テスト，構成テストなど）をどのテスト・レベルで適用するのかを決めます。どんな技法で設計して，「テスト実施」を自動化するかどうか，また設計レビューやコード・レビューなどの方法も決めていきます（表1[拡大表示]）。もう一つは，日程計画の中で「テスト・サイクル」をどう回していくかを決めることです。それには， ・いかにして効率よくテストを進めることができるか テスト・サイクルは，テスト設計で作ったたくさんのテスト・ケースをどういう順番でテストしていけば，早く多くテストしていけるかを組み立てる作業です。品質目標が違えばテスト・サイクル数は変わりますし，テスト担当のスキル，テスト環境の充実具合，開発チームの体制（修正リリースがどの程度のスパンで行えるのか）によっても変わってきます＊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/）などのバグ・トラッキング・ツールを使い，テストで見つけたバグがどうなったのかを一目瞭然にしておくことも必要でしょう。また，テスト結果の分析（後述）のため，メトリクス用データ収集の仕組みをこれらのインフラに埋め込んでおくと，データ収集の効率が向上します。 これらの作業をきちんと全部やろうとすると，とても面倒に感じられるかもしれません。しかし，だからこそツールをうまく活用してインフラを準備しておくことが重要なのです。 テスト結果の適切なレポートが
|
 |
| 湯本 剛(ゆもと つよし) 株式会社豆蔵 ES事業部 |
リリース（納品）のための判断材料の提供とは，言い換えると「テストを終了してよいかどうかの判断材料の提供」です。計画したテストをどの程度実施したか，仕様変更が入った部分のテストを実施しているか，バグの発見件数は減ってきているか（バグの収束状況），バグの対応はどこまで済んでいるか，制限事項にしたバグについて課題はないかなどの様々な判断条件を使って，テストを終了してよいかを判断します。この判断はマネージャや経営者が行いますが，誤った判断をしないためにもテスト結果を元にした判断材料が重要になってきます。
今後の改善のための材料の提供は，開発にかかわったメンバーで行う事後レビューの場で行います。バグを分析してレポートすることで，バグの傾向がノウハウとして蓄積していくようになり，開発チームはノウハウを元に“間違えないように作る”ようになれるでしょう。また，テスト担当は“間違えそうなところを先にテストする”ようにもなれます。テストをなくすことはできませんが，バグを予防するためのノウハウを共有することで，バグによる手戻りの工数が減り，“狙った工数以内に収める”ことが可能になるわけです。
