 表7●テスト管理で知っておくべき項目（■は本記事で解説する項目） [画像のクリックで拡大表示] |
 図8●進ちょくをつかみ対策を立てる テストの進ちょくを把握するには，テストの消化率と網羅率の2つに注目する。消化率とは，テストの総項目数に対する進ちょくを表す。一方の網羅率は，サブシステムなどの機能ごとにテストの進ちょくを計測し，合計した値を機能の数で割る。網羅率の方が，消化率よりもテストの完成度を細かく把握できる [画像のクリックで拡大表示] |
 図9●バグの発生と解決のバランス・グラフ例 テスト日数が進むにつれ，バグの解決時間が短くなり，発生件数も減っている。システムの品質が安定してきたと判断できる [画像のクリックで拡大表示] |
 図10●仕様を固め，テストを着実に積み上げる バグの発生件数をプロットした信頼度曲線は，曲線が水平に近づくと品質が安定してきたと判断できる。あるシステム・テストでは，以下の2つの問題を抱えていたため，本来のテスト期間（2カ月間）ではバグが収束しなかった。まず，(1)システム・テストの前に実施した結合テストの結果が不十分だった。また，(2)仕様策定に問題があり，仕様追加が2回発生した。システムの品質を向上する作業は，上流工程における仕様策定から始まっている [画像のクリックで拡大表示] |
 表8●テスト設計やバージョン管理を支援する主なツール [画像のクリックで拡大表示] |
テスト作業は，よく「地雷の撤去作業」に例えられる。計画時点ではどこにどれだけの地雷（バグ）が存在しているか分からない点でよく似ているためだ。このような「計画に不確実な点が多い作業」では，実績や問題点を随時把握して，計画を見直しながら作業を進める管理方法が有効になる。テスト管理では，テスト作業を3つの側面でとらえている（表7[拡大表示]）。
V-(1)：進ちょく管理
テストを「予定したテスト・ケースの消化作業」と考えて，より早く，より広い範囲を効率よくテストすることを目的にする。最も基本的な管理だけに品質水準を大きく左右する。
管理方法は，テスト実施者が日々のテスト進ちょく結果を報告する「日報」，テスト項目の一覧表である「項目表」や「網羅表」などに基づき，テスト・ケースの消化率や網羅率をグラフ化して傾向を把握する。テストが順調に進まない場合には，原因を分析，特定して，テストの実施順を変更するなどの対策を講じる。
また，テストの実質的な進ちょくを示す「網羅率」とテスト・ケースの単純な「消化率」は，1つの対策では両方を向上できない場合もある。「今どちらを優先すべきか」の判断を迫られるのだ。例えば図8[拡大表示]では，消化率よりも網羅率の遅れが著しいので，テスト未着手の機能を翌日に重点実施することに決めた。判断には，テスト対象のシステムに対する洞察力や，日々変化する状況データの分析力など，テストの経験に支えられた技術が必要となる。
V-(2)：バグ管理
テストを「バグを生産する作業」と考えて，より多くのバグを効率よく発見することを目的にする。管理方法は，検出したバグの詳細を報告する「バグ・レポート」や日報などに基づいて，バグの発生状況をとらえる。
進ちょく管理と同様にグラフで傾向をつかむ。実行したテスト・ケースに対して何件のバグが発生したのかを管理するため，グラフの軸には「消化テスト・ケース数」や「網羅率」，「バグ発生数」などを選択する。テストに費やした「時間」とテストやバグの実行数の関係を管理することは，進ちょく管理の範囲なので，バグ管理では「時間」を軸に入れない。
例えば，網羅率が向上しているにも関わらず，バグ発生の伸びが鈍化している場合は，網羅率を上げるためにテスト対象としたエリアは，もともと品質が高いか，もしくは見当違いのテスト・ケースを実施している可能性がある。逆にあまりテスト進ちょくが進んでいないのにバグが多く発生している場合，そのテスト対象がバグの巣であるか，もしくは同じバグを複数回報告している可能性がある。
このように，数字のみの管理では，バグ発生率が鈍化している原因の特定が難しい。テスト・ケースやバグの内容まで知らなければ，管理者は適切に判断できない。もしテスト実施側に問題ありと判断できれば，テスト・ケースの内容やテストの実施順を再考する。バグ・レポートの書き方の指導も効果的だ＊20。開発側に問題ありと判断できれば，設計書やプログラムの作り直しなどの対策を促す。
V-(3)：品質水準管理
テストを「計画された品質目標を達成する作業」と考え，達成すべき品質目標を早期に実現することを目指す。品質目標はシステムにより大きく異なるが，筆者の経験上よく使用する2つの指標を紹介する。
● バランス・グラフ
図9[拡大表示]は，バグの発生と解決のバランスを分析するために，バグ発生数とバグ解決数の総量を縦軸に，作業日数を横軸にして品質水準を表したバランス・グラフだ。後半になりバグ解決時間が次第に短くなっていったので，品質が向上したと判断した。
バグが発見されてから解決されるまでの間隔が短くなってくると，システムの品質水準が高いといえる。なぜなら，軽微なバグが多ければ解決も早いが，重大なバグの解決には多くの時間が必要だからである。
● 信頼度成長曲線
信頼度成長曲線は最もよく知られたテスト管理図だろう。縦軸にバグ発生数，横軸にテスト作業時間を採り，バグ発生の状況を捉えたグラフだ。バグ発生のカーブが緩やかに水平に近づくと品質が安定してきたことを示す。過去に経験した類似規模や類似難易度のシステム開発を参考に，バグ発生数の目標曲線を導き出しておくとよい。
図10[拡大表示]は，信頼度成長曲線を使って品質水準管理を行ったが，まったく品質水準が向上しなかった失敗例だ。このプロジェクトでは，品質ではなく期間を基準にしてテスト工程の終了が宣言されたため，結合テストが不十分のままでシステム・テストが開始されてしまった。さらに，そもそもの要求定義に問題があり，仕様追加が2度発生した。テストは品質重視で進めていくものであり，上流工程から品質向上作業は始まっている＊21。
V-(4)：情報共有を推し進める
さて，管理手法を述べてきたが，筆者の経験上，テスト管理者はもう2つの重要な使命がある。
一つはコミュニケーションの中心となることだ。グラフの数字やバグ・レポートでは見えない，悩みや疲れ，焦りなどを抱えている作業員も多いだろう。期限が差し迫れば雰囲気も悪くなる。これらを積極的なコミュニケーションで解消することが重要だ。
また，テスト・チーム全体の情報共有にも気を配ろう。特にテストの進ちょくや，解決できていないバグなどの情報は必ず共有したい。テストに携わる人の数は多いが，各人の作業は分断されているものだ。進ちょくグラフを開発ルームの壁に張り出したり，開発チームでメーリング・リストや社内のイントラネットを活用したり，何らかの方法で問題意識を共有して，参画するすべての関係者に当事者意識を持たせることが大切だ。
もう一つは，テスト環境を早めに準備することだ。いくらテスト・ケースを先行して考えても，テスト環境がなければ実行に移せない。特にツールやマシンなどは早めに発注したい。また，ソースコードのバージョン管理ツールや，テスト設計や工程管理を支援するツールも活用したい（表8[拡大表示]）。バージョン管理は煩雑だが欠かせないため，ツールで自動化する価値は高い。
|
倉田 克徳 エス・キュー・シー 代表取締役 石川 和則 エス・キュー・シー 取締役 事業企画室長 |
