試験工程の管理

伊東 輝

ウォーターフォールのプロジェクトを円滑に進めるには、工程管理が欠かせない。
工程管理を適切に行うことで、各工程で作られる成果物の品質を高めることができ、品質問題が発生したとしてもいち早くそれに気付き対処することができる。

この記事では、工程の中から、試験工程に該当する単体テスト・結合テスト・システムテストについて工程管理の概要を説明する。

なお、製造とほぼ同時に行うコードレビューについては、前回の記事で取り上げた開発工程のレビューと同じような方法で管理を行ったり、静的解析ツールのようなもので自動的に品質を担保したりする手法が取られるため、当記事では割愛する。
また、単体テスト・結合テスト・システムテストの工程では計画書や報告書のようなドキュメントを作成し、それらのドキュメントに対するレビューも行われるが、それらのドキュメントは関係者間の情報伝達の色が強く、それらのドキュメントやレビューに対する品質管理が行われることも少ないため、当記事では詳しく取り上げない。


(1)試験の作業の流れ

単体テストは詳細設計の内容が正しく実装されているかを保証する工程、結合テストは基本設計の内容を保証する工程、システムテストは要件定義の内容を保証する工程であることは、以前の記事でV字モデルを用いて説明した通りである。

それぞれの試験工程では、以下の流れで作業を行うことで、実装内容を保証する。

  • テスト計画の策定
    どの箇所・機能に対して、どのような目的で、どのような観点のテストを行うのかを計画する。
    単体テストではこれが自明であることが多いため省略されることが多いが、結合テストやシステムテストでは具体的な作業に入る前に全体的な方針を計画することが重要となる。

  • テスト項目の策定
    テスト計画に基づいて、テスト項目を策定する。
    単体テストや結合テストでは主にホワイトボックステスト（プログラムが開発者の意図通りに動くか確認するテスト）の観点で、結合テストやシステムテストでは主にブラックボックステスト（ユーザー目線でシステム自体の仕様を満たしているかどうかを確認するテスト）の観点でテスト項目を作成する。
    テストパターンが複雑な場合は、デシジョンテーブルのようなテストパターン表を別途作成し、パターンを整理する。

  • テストの準備の実施
    テスト計画に基づいて、テスト環境やテスト用のプログラムの作成を行う。
    また、洗い出されたテスト項目に基づいたテストデータの作成も行う。

  • テストの実施とバグ対応
    洗い出されたテスト項目を順次検証し、バグが発見された場合はそれを修正してテストを再開するという、テストの実作業に相当する作業である。
    不測の事態が最も発生しやすい作業であり、必要に応じて、上長へのスカレーション、及びテストの一部再実施や品質強化といった追加作業を行う必要がある。

  • 上長へのテスト結果の報告
    全てのテスト項目が消化されたタイミングで上長へテスト結果の報告を行う。
    一連の作業が正しく行われているのかを上長の目で確認し、テスト工程の終了を承認する。
    承認を妨げる何かしらの問題を指摘された場合は、その指摘対応のための追加テスト実施や品質強化策の実施が必要になる。

(2)バグの管理

テストを実施していく中でバグが発見されることがある。
そのバグを抜け漏れなく管理するため、Excelやスプレッドシートのような形式で表を作ることもあれば、BacklogやJiraのようなチケット管理ツールを用いることもある。

バグの管理に際しては、テストを実施している担当者からバグを修正する開発者への情報伝達、バグが漏れなく対応されていることの確認、及びバグの発生数や発生傾向に着目した品質評価のため、それぞれのバグに対して以下のような項目を管理することが望ましい。

  • 通番、タイトル
    見つかったバグを一意に特定するための情報。
    報告書上や会議の場で報告する際に、連番や簡潔なタイトルがあると意思疎通がスムーズになる。

  • 発生日
    バグが発見された日を記入する。
    詳しくは後述するが、試験工程の進捗を確認する一つの方法として、バグが何件発見されたのかを日毎に確認する、というものがあり、その際に必要となる情報である。

  • ステータス
    それぞれのバグについて、対応が現在どの段階にあるのかを記入する。
    順番に書くと、「起票」「原因調査中」「バグ修正中」「修正確認中」「対応完了」といった段階に分ける必要がある。
    試験工程が予定通りに進んでいない場合、ステータスからどこがボトルネックになっているのかを掴める場合がある。
    例えば、「起票」「原因調査中」「バグ修正中」で止まっているバグが多ければ、バグが多すぎて開発者の手が回っていないことが予想され、「修正確認中」で止まっているバグが多ければ試験担当者の手が回っていないことが予想される。
    バグではない事象が書き込まれたり、一つのバグが複数個所に重複されて起票されたりする場合もあるので、それを示すためのステータス（「バグではない」「重複起票」等）も必要であり、バグ数カウントでカウント不要なバグを除外する際に当該のステータスを利用する。

  • バグ内容
    バグの内容やバグを発生させる手順を記入する。
    この項目を参照するのは基本的にバグを修正する開発者であるが、品質強化策を考えるヒントを得るための情報の一つにもなり得る。
    （ただし、この項目からヒントを得るためには、開発に関する知見が必要になる場合がある）

  • 原因、修正方法、対象プログラム
    バグの原因や修正方法、修正する必要があるプログラム名、といった、バグ修正に必要な情報を記入する。
    単純なバグであれば試験担当者が記入できる場合もあるが、基本的にはバグを修正する開発者が記入する項目であり、開発者のための項目でもある。
    この項目も、品質強化策を考えるヒントを得るための情報の一つになり得る。
    特に、対象プログラムについては、開発に関する知見が無くとも機械的に数を集計できる項目であるため、品質強化が必要なプログラムを特定する上で有用な項目となる。

  • バグ修正予定日、完了予定日
    開発者によるバグの修正が完了する予定日、及び試験担当者による修正確認が完了する予定日を記入する。
    この項目は進捗管理に使用することができ、上がってきたバグの対応が試験期間内に終わる見込みかどうかを確認することができる。

  • 発見するべき工程
    そのバグがどの工程で発見するべきだったのか、ということを記入する項目である。
    例えば、現在が総合試験工程である場合、システム内の修正対象外のプログラムとの連関で発生したバグなら「システムテスト工程で見つけるべきバグ」となるが、プログラム内の単純なロジックのミス（製造ミス、修正ミス）で発生したバグであれば「単体テスト工程で見つけるべきバグ」となる。
    これは、品質強化策を考える上で重要な項目となる。
    ウォーターフォールでは「前工程が完全に終わってから次工程に進む」というのが前提となっており、この前提が崩れている場合、現工程の作業が前工程の問題により進めることができなくなり、予定通りに作業を完了させることができなくなる。もし、前工程で発見するべきバグが多ければ、この前提が崩れているということになるため、この前提が崩れているプログラムについては品質強化が必要となる。
    これは私見であるが、目安として、前工程で発見するべきバグが全体の20～30%程度であれば品質強化を検討、50%を超えたら品質強化が必須、と考えて良いだろう。現場によっては、品質強化を行うべきラインが計測・策定されている場合もあるので、そのような数字が現場あればその数字に従うべきである。

(3)バグの発生数と進捗の関係

一般的には、一定のペースでバグが発生し続けるということはなく、試験実施の初期はバグが発生しにくく、中期にバグが多量発生し、後期にバグの発生が少なくなる、という経緯を辿る。
そのような経緯を辿る背景を説明すると、以下のようになる。

  • 試験初期；試験手順が確立していないため、バグがなかなか見つからない

  • 試験中期：試験手順が確立したため、順調にバグが見つかる

  • 試験後期：品質が向上し残りの試験項目もレアケースのみとなるため、バグが見つかりにくくなる

このような経緯を説明したグラフが、ゴンベルツ曲線（信頼度成長曲線）である。

図1-1：ゴンペルツ曲線（信頼度成長曲線）

具体的なバグ数については、現場ごとに統計を取るか、実務経験を通して直感でイメージするかする必要があるが、上記の曲線通りの経過を辿らない場合は、何かしらの品質問題が発生していると考えられ、品質強化やテスト項目の見直しが必要になる。

もし、バグが大量に見つかる（aの経過を辿る）ようであれば、テスト開始時点の品質が悪い疑いがある。
この場合、バグの原因を確認し、前工程で見つけるべきバグが大量に見つかっていないかどうかを見る必要がある。
前工程で見つけるべきバグが大量に発見された場合は、バグの対応でテストの進捗が悪くなることを防ぐために、もう一度前工程に戻って品質強化を行う必要がある。

また、発見されるバグが少ない（bの経過を辿る）ようであれば、テストケースの作り込みが甘い疑いがある。
この場合、テスト項目を確認し、テストの目的に照らし合わせてテスト項目の網羅性が十分かを見る必要があります。
テスト項目の網羅性が不十分な場合は、現在のテスト工程で見つけるべきバグが見つからないことにより次工程やリリース後に悪影響を及ぼすのを防ぐため、テスト項目を修正する必要がある。

この記事が気に入ったらサポートをしてみませんか？