概要・テスト品質を良くするにはテスト計画書に目的と体制と管理と環境とトラッキングを書く
テスト計画書には目的と体制と担当と環境とトラッキングを必ず書いて置く
テスト計画はテスト計画書に書き出しますが、テスト計画書にはどんな項目を書けば良いのでしょうか？ テスト計画書といっても一般的な様式が決まっている訳ではありませんが、グータラ親父の経験からはテスト計画書には以下の様な項目が必要と考えています。
- テストの目標：今回のテストはどんな目的や方針で実施するのか、何を確認するのが最重要なのか。
- テストの体制：テストはどんな分担や体制で実施するのか、開発チームとテストチームの分担は明確
- テストの管理：テストの管理の仕方は具体的に書いてあるか、誰がどんなタイミングで何を監視して修正するのか
- テストの環境：テストの環境とその準備について具体的に書いてあるか、何が・どれだけ・何時必要なのか
- トラッキング：テストで見つけた問題点のトラッキング方法が明確か、誰が・何処に・どんな内容を記録するのか
1. ソフトのテストも方針や目標を定めた計画と実施の管理が大切
ソフトのテストに限らないのですが、何かを始める時には目的を確認し、その目的を達成するための方針や目標を決めて、その目標に辿り着くための計画を立てて計画の進み具合を管理する事が大切です。ソフトはハードと違って目に見えないので管理が難しいのですが、ソフトのテストはさらに見えにくので、注意して管理しないとうまく進みません。管理の最初の一歩が計画なので、まずはしかりとテスト計画を作りましょう
テスト計画ではテストの方針を冒頭に書く
ソフトテストの目的は、ソフトの品質保証（バグが無い事の確認）かソフトの品質改善（バグの検出）のどちらかなので、これは改めて書かなくてもいでしょう。ですので、テスト計画書の最初に書くのは、今回のテスト作業におけるテストの方針です。
テストの方針とは、テストの実施において重点を置く項目、の事です。例えば、新規に開発したソフトのテストならば機能や性能の確認の網羅性に重点を置くでしょう、バグ修正版のソフトのテストなら修正による効果確認と二次不具合の確認に重点を置くでしょう、開発リリース日を守る事が大切なソフトのテストならばテスト日程の遵守に重点を置くでしょう。リリースするソフトのリリース目的によって、そのソフトのテストも何に重点を置くのかというテスト方針が変わるので、テスト計画書にはテストの方針を冒頭に書いておくのが良いです。
テストの目標はできるだけ定量的に書く
テスト方針が決まったら次は今回のテストの目標を書き出します。ソフトのテストの目標には、進捗管理の目標とかバグ検出の目標とか、バグ修正の目標とか、目標の立て方には色々あります。その中で今回のテスト作業の方針に沿った目標を１つか２つ、それ以外の目標をあと１つ、合わせて２つか３つの目標を立てておくと、テストを終えた後での振り返りで役に立ちます。
ここで立てる目標は、できるだけ定量化の方法を考えて数値化による目標の設定と達成状況の確認ができるようにすると管理に使いやすくなります。テスト進捗を目標にするならマイルストーンの達成率（計画日までに達成できたマイルストーンの数の比率）で数値化するとか、バグの検出量を目標にするなら新規開発コード量に対するバグ検出率で数値化するとか、それぞれの目標で少し工夫する事で何等かの数値化ができます。
2. テストの分担と体制はテストの開始前に決めておく
ソフトのテストが行われている時のソフト開発作業をテストを主体にして書き出す、大まかには以下のようになります。
- テスト設計（テスト項目やテスト環境やテストの手順を具体化する）
- テストの実施（テスト設計の内容に従って実際にテストを実施する）
- 不具合の記録（テストで発見した不具合の内容や発生条件を記録する）
- 不具合の再現（テストで発見した不具合の再現状況を確認する）
- 不具合の切り分け（不具合がソフトのバグかどうかを判定する）
- バグの修正（バグの原因を調査してソースコードを修正する）
- 修正効果の確認（修正されたソフトでバグが修正された事を確認する）
- 修正内容の登録（修正版のソースコードをマスターツリーに反映する）
- 修正完了の確認（マスターツリーからバグが除去された事を確認する）
これらの作業のどれをテストチームやテスト担当者が担当し、どれを設計チームやコーディング担当者が担当するのかは、テストの開始前に分担決めてテスト計画書に書いておく必要があります。１～３はテストチームやテスト担当者が実施し５～7は設計チームがコーディング担当者が実施する事が多いと思います。しかし、４、５や８については、テストチームか設計チームのどちらが担当するのか、プロジェクトの状況によって変わる事が多いので、始めに確認して計画書に書いておきましょう。
同時に、テストチームの中で各々の作業をどのように分担するのかを決め、場合によってはテストチームの中をさらにいくつかのサブチーム（再現担当とか修正完了担当とか）に分けて、テスト体制を作っておく事も、大規模なソフト開発の場合には必要になってきます。これも、テストの計画として検討し計画書に書いておきましょう。
3. テストの管理は計画と実績収集と計画修正の方法を明確に
ソフトのテスト作業は、設計・実施・結果の利用（バグの記録とトラキング）と進んでいきます。これらの作業の日程や機材や人員の計画がテスト計画書に書き出されているはずです。
そして、テスト計画書にそって実際のテスト設計やテスト実施が開始されてからは、計画どおりに進んでいるのかを監視し、計画からのズレがあれば修正するように、テスト管理をする必要があります。
テスト設計の段階なら設計されたテスト項目の数、テスト実施の段階なら実施を終えたテスト項目の数、などのテスト成果物を元にテストの進捗状況を監視したり、発見したバグの数や修正されたバグの数などのテスト成果物を元にテストの効果を監視したりと、監視の方法には色々な方法があります。
どの監視の方法をとるにしても、どんな情報を集めるかを最初に決めておいかないと必要な情報が集まりません。ですので、テスト計画書ではテスト管理として何を行うのか、そのためにどんな情報を集めるのか、お具体的に書いておく必要があります。
同時に、監視した結果テスト計画からのズレが発見さらたらどうするのか、も書いてあるほうが良いです。計画からのズレがテストチーム内での回復ができればいいですが、テストチーム内だけでは回復が無理な場合には、早めに問題点を上位組織にエスカレーションして、ソフトの全体開発計画との調整を進める事も必要になります。計画からのズレがどの程度発生したら、どんな方法・ルートで問題をエスカレーションするのか、についてもテスト計画書に書いてあるのが良いですね。
4. テストの環境とその準備は具体的に書いてあるか
テストの計画ではテスト環境の準備についての検討もとても重要です。テスト環境と言ってもいろいろありますが、以下のような項目について何時までのどの程度の量を準備して、何時まで使うのか、についてテスト計画書に書かれている事が必要です。
- テスト対象のソフトを実行するターゲットハード（何時から何台使うのか）
- テスト対象のソフト（どのバージョンが何時テストチームに渡るのか）
- ターゲットハードを接続する上位/下位の装置や機器（サーバや下位端末など）
- ターゲットハードと上位/下位の装置や機器を繋ぐ通信路（本番回線など）
- テストの実施に必要なテスト機器（ノイズジェネレータや各種のシミュレータ）
- テストの実施に必要な場所と電源（テストの作業場とテスト結果を整理する机）
- テストを実施するテスト人員（テスト設計者とテスト実施者）
新製品の開発の場合には、特に１のターゲットハードの製造計画には注意が必要です。ハードの設計や製造が計画どおりに進めば何も問題ないのですが、ハードの設計や製造が遅れると予定していた日時にターゲットが手に入らなかったり、手に入っても台数が少なかったりします。そうなると、テストの日程計画を修正する必要があるのですが、リリース日は動かない事が多いので、奈にをどうやって辻褄をあわせるのか、なかなか苦しい状況になってしまいます。
5. テストで見つけた不具合やバグの管理方法は具体的に決めておく
テストをすれば何等かの不具合やバグが見つかります。不具合とバグは混同し易いのですが、この記事では不具合とは装置や機器を使う時の問題点を指しバグは不具合の原因になるソフトの間違いを指す事とします。具体的には、ソフトのバグやテスト手順の間違いなどが原因でおきる問題点が不具合で、ソフト設計のミスやコーディングのミスが原因でおきるソフトの動作の間違いがバグですね。バグは不具合の中の具体的な１項目です。
テストの目的が品質保証（バグが残っていない事の確認）ならば、バグは見つからないほうが良いのですが、普通はテストの初期段階ではテストの目的は品質改善なので、見つけたバグに対する修正作業が始まります。テストで発見された不具合とバグの管理方法は、テスト計画で具体的に決めておく必要があります。不具合やバグの管理方法には色々ありますが、少なくとも次のような事を決めておくと良いでしょう。
- 不具合の分類（バグ、仕様間違い、テスト手順間違い、環境不備 など不具合をどう分類するのか）
- 不具合の記録方法（何かのシステムに入力するのか EXCEL 表に書くのか）
- 再現方法の記録（不具合の再現条件や方法はどこに書いておくのか）
- 状態遷移（個々の不具合やバグはどんな状態を遷移して最終的に終了状態に行きつくのか）
- 終了判断（誰がどんな基準で不具合の対応が終了したと判断するのか）
- 担当者割り当て（調査や対策の担当者は誰が何時の時点で割り振るのか）
- 優先度付け（不具合やバグの調査や対策の優先度は誰がどうやって決めるのか）
- トレース（個々の不具合の状態遷移は誰がどうやって監視して遅れの対策をするのか）
複数のソフトエンジニアとテストエンジニアが参加する開プロジェクトでは、テストで見つかったバグの情報共有と管理のためにバグトラッキングシステムやテスト支援ツールを使う事が多いです。これらのシステムやツールは、あくまでも道具なのでそれをうまく使うためには、上記のような項目を決めてシステムやツールに設定しないといけません。
ここが最初にしっかりと決まっていないと、テストが始まって不具合が見つかりだしてから、不具合修正の作業が混乱してしまうので、テスト計画書に具体的に書いておくのが良いでしょう。
ソフトのテスト計画の良し悪しがテスト効率を左右し開発効率も左右する
ソフトの規模が大きくなると、全てのソフトを内作していては間に合わなくなり、購入ソフトやオープンソースソフトの比率が高くなっていきます。ソフトのテストは内作か購入かオープンソースかに関係なく、自社で品質を保証する領域については全てテストが必要です。
そのためにソフト開発に占めるテストの比率が高くなりテストの規模も大きくなります。規模が大きくなったテストを効率よく進めるには、良いテスト計画が必須ですので、テスト計画の作成には十分な時間をとって良い計画を練りましょう。そうする事が最終的にはソフト開発の効率化に結びつきます。
以下の記事では、テスト計画の各々の項目についてグータラ親父の経験した事を元にして、もう少し具体的に紹介していきまので、興味のある方はご覧ください。