テスト計画時に必ずやるべきこと
0. はじめに
テスト計画ではテスト対象の決定、テスト方法の決定が非常に重要となります。
これらを決めないと、根拠が曖昧なスケジュールしか作れないし、次プロセスのテスト設計に必要な情報が不足してしまいます。
1. テスト対象の決定
1-1. テスト対象の候補を洗い出す
テスト対象の候補を洗い出すにあたり、インプットとなるのは要件定義や仕様書、設計書といったドキュメントです。
新規開発の場合は開発対象とテスト対象がほぼイコールになりますが、機能追加やバグ修正の場合、変更していない箇所も当然テスト対象として検討しなければならなりません。
具体的には、改修した機能と関連する機能を洗い出すことです。例としては以下があります。
- 改修した機能と同じデータを参照している機能
- 改修した機能と同じ業務フローに含まれる機能
1-2. テスト対象の優先順位を決める
テスト対象を広げすぎると、期間内にテストが終わらないといった問題が発生します。
そのため、テスト対象の優先順位を決めることが重要です。優先順位を決めるにあたり、代表例として以下のような考え方があります。
- 開発規模に着目する・・・開発規模が大きい機能は、それだけ開発時にバグが混在するリスクが高い。
- 業務重要度に着目する・・・該当の機能がどのくらい重要なのかを評価する。（競合者に対抗する機能、ユーザーが必須とする機能など）
- 障害発生時のインパクトに着目する・・・障害発生時のインパクトがどの程度かを表かする。（不具合が発生するとビジネスが止まる機能など）
- 過去の障害に着目する・・・過去の開発時にバグが多く検出された機能は、今回も障害発生リスクが高いと判断できる。
2. テスト方法の決定
2-1. テストレベルを決める
テストレベルとはテスト対象を区切る粒度のことです。
テスト対象やテストの目的、インプットする情報をもとに、どのレベルのテストを行うか（例：単体テスト / 結合テスト / システムテスト / 受け入れテスト）を決定します。
2-2. テストタイプを決める
テストタイプとはテスト観点を目的別に分類したものとなります。一般的には以下のようなものがあります。
- 機能テスト・・・ソフトウェアの機能が、設計書で規定した通りに動作するかを確認するテスト。
- 性能テスト・・・プロジェクトで規定したシステム性能が出ているかを検証するテスト。
- 回帰テスト・・・システム改修を行っていない部分が、規定通りの結果を返すかを検証するテスト。
- ユーザビリティテスト・・・ユーザの使用性に着目したテスト。
- 疎通テスト・・・システム間でデータが通るがどうかを検証するテスト。
- セキュリティテスト・・・システムのセキュリティに着目したテスト。(Webサイトの脆弱性確認など)
2-3. テストのやり方を決める
テストレベルとテストタイプの組み合わせごとに、どのようなテストの実施方法を採用するのかを検討します。
検討が不十分だと、テスト実施段階で「環境制約で実施できない」「ツールを使わないとテストできない」といったことが判明したりします。
3. さいごに
テストをするにあたり、今までの経験のみに頼ってしまうと、テスト粒度や観点が担当者によって異なったりしてしまうことが起こります。
プロジェクトによってベストなテスト方法は違ってくるので、テスト計画にてテストレベルやテストタイプをしっかり決めるべきかと思います。