テスト計画は設計と同時に決める
テスト計画を「製造が終わってから考えるもの」だと思っていると、終盤で必ず苦しくなります。
テストは設計の裏返しです。設計で決めたことを、決めた順番どおりに確かめていく作業です。だから、設計と同時に決められます。むしろ、同時に決めないと設計の抜けに気づけません。
■ V字モデルで対応を確認する
各工程には、対になるテストがあります。
要件定義 ↔ 受入テスト 業務が回るかどうかを、使う人が確かめる
基本設計 ↔ 総合テスト 業務シナリオが最初から最後まで通るか
詳細設計 ↔ 結合テスト 機能と機能の受け渡しが合っているか
製造 ↔ 単体テスト 1本ずつ仕様どおりに動くか
ここで大事なのは、設計工程を終えるときに、対になるテストの合格条件を書いておくことです。設計レビューの場で「これはどうやってテストしますか」と必ず聞きます。
答えられない設計は、たいてい書き方が曖昧です。テストできない仕様は、そもそも決まっていないと考えてよいでしょう。
■ 着工前に決めておく5つ
① 何を確かめるか
層ごとに目的を分けます。単体テストで業務シナリオを確認しても意味がありませんし、受入テストでバグ出しをしていては遅すぎます。それぞれの層で何を担保するのかを、先に書き分けます。
② 誰がやるか
とくに受入テストは、業務側の人にやってもらう必要があります。ところが業務側は通常業務を抱えています。「テストの時期になったらお願いします」では、人が出てきません。
いつ、何日間、何人必要かを早い段階で伝える
その期間の通常業務をどうするか、上長と相談してもらう
テストのやり方を事前に説明する時間も工程に入れる
ここを計画に入れていないプロジェクトは、終盤で「人が出せない」と言われて止まります。
③ 合格基準
「テストが終わった」と言える条件を、数字で決めます。
予定したテストケースの消化率が100％であること
重大バグが0件、中程度のバグが◯件以下であること
未解決のバグについては、回避策と対応時期が合意されていること
基準がないと、「まだ不安だからもう少し」と延々に続きます。逆に、基準があれば「ここまでやったら出す」と判断できます。
④ データと環境
見落とされやすいのがここです。
テスト用のデータを、いつ、誰が、どう用意するか（本番データを使うなら、個人情報の扱いも決める）
テスト環境をいつまでに構築するか。本番と同じ構成にできるか
他システムとの接続テストができる環境と時期はいつか
とくに本番相当データの準備は、想像より時間がかかります。工程表にタスクとして入れます。
⑤ バグの扱い
テストが始まってから決めると、混乱します。最初に決めておきます。
重要度の区分（業務が止まる／回避策がある／表示の不備、など）
重要度ごとの修正期限
修正後の再テストを誰がやるか
直さないと決めたバグを、どう記録し、誰が承認するか
■ テスト工程は削られやすい
前工程が遅れると、しわ寄せはテストに来ます。稼働日が動かせないからです。しかし、テストを削ると、問題が稼働後に出ます。
削らざるを得ないときは、全体を薄くするのではなく、対象を絞ります。
使用頻度が高い業務、金額に関わる処理、止まると影響が大きい機能を優先する
優先度の低い機能は、テストを後ろに回して稼働後に実施する（合意のうえで）
削った範囲と、そのリスクを文書に残す
■ まとめ
テスト計画は、テストの直前に作るものではなく設計と同時に決めるものです。設計レビューで「これはどうテストするか」を確認し、合格基準・担当・データ・環境・バグの扱いを着工前に決めておく。
とくに業務側の要員確保は早めに動きます。ここが間に合わないと、どれだけ良いシステムを作っても稼働できません。