開発するシステムの品質を担保するために開発工程に応じてシステムのテストを行う必要があります。
開発工程ごとに行うテストではどのようなものがあるのか、そこではどのようなことを行うのかを説明します。
「ウォータフォール型開発」と「アジャイル型開発」の開発手法がありますが、ここでは「ウォータフォール型開発」の手法に絞って説明します。
システム開発で行うテスト工程と概要のまとめ
1. 開発工程とテストの種類
ウォータフォール型開発におけるシステム開発は、開発工程を複数に分割して各工程を順次行っていく開発手法になります。
ウォータフォール型開発では、ひとつの工程が完了後に次の工程へ移ります。
次の工程へ移行後は前の工程へ戻ることは想定していないため、手戻りが発生した場合には、システム開発全体へ大きく影響します。
ウォータフォール型開発では、ひとつの工程が完了後に次の工程へ移ります。
次の工程へ移行後は前の工程へ戻ることは想定していないため、手戻りが発生した場合には、システム開発全体へ大きく影響します。
・ウォータフォール型開発のイメージ
ウォータフォール型開発の手法にもとづいて開発工程とテスト工程の関係を表したものに「V字モデル」があります。
同じ高さの開発工程とテスト工程が紐づいており、各工程におけるテストの範囲や進捗管理などが行いやすくなります。
・V字モデルのイメージ
V字モデルの各工程を行うテストとしては、次の3つがあります。
それぞれの詳細については、各項で説明を行います。
■単体テスト・・・システムの最小単位（クラスやモジュール）ごとにテストを実施
■結合テスト・・・複数のシステムを組み合わせてテストを実施
■総合テスト・・・システム全体の機能や性能面でのテストを実施
2. 単体テスト
作成したシステムの最小単位（クラスやモジュール）ごとに行うテストになり、業務では、「ユニットテスト」や「UT」などと呼ばれたりします。
実装後すぐに行うテストであり、小規模に実施するため、不具合発見時の戻り対応が少なく済みます。
各テストで境界値分析や分岐網羅などのテストを行うため、テスト項目が多くなりテスト実施に時間がかかる場合があります。
2-1. ポイント
・システム構造の理解不足
作成した最小単位のシステムにどのような機能があるのか理解が不足している場合、テスト項目が不足し正しくテストが行えない可能性があります。
テスト項目を作成する際に、対象の機能がどのようなものなのかを理解したうえでテスト項目を作成する必要があります。
・テスト観点の洗い出し不足
最小単位でシステムを実行した場合に処理が正常終了する場合だけでなく、条件によって処理が異なる場合にその点を網羅できているかなどテスト観点を洗い出す必要があります。
ここでの洗い出しが曖昧だと後続のテストで不具合が発生したり、テストが正しく行えているか確認する必要が生じてしまいスケジュールの遅延に繋がります。
・不具合発生時の管理
単体テスト実施中に発生した不具合の管理が必要になります。
どの機能をテスト中に発生したのか不具合の詳細や再現手順を明確に記載して関係者間で共有します。
これにより「どこで」「何が起きているのか」を把握でき原因調査も行いやすくなります。
不具合の報告は、開発しているシステムの関係者のみに行い、別システムを開発している関係者には報告を行いません。
・作業スケジュールの管理
結合テストや総合テストなどの工程に比べテスト項目が多くなるため、テスト品質やスケジュールを考慮してテストを行う必要があります。
テスト品質を重視した場合、スケジュールに遅延が発生する可能性を考慮する必要があり、スケジュールを重視した場合、テスト品質が低下する可能性もあります。
そのため、テスト品質とスケジュールを考慮してテストを実施する必要があります。
2-2. 主な成果物
・単体テスト仕様書
実施手順やテストデータ、エビデンスなどを記載した資料になります。
単体テスト仕様書に記載されている内容に沿ってテストを行うため、誰が実施しても同じ結果になるように曖昧な表現を避けて作成する必要があります。
また、不具合修正後の回帰テストで同様の結果になることを確認する必要もあるため、単体テスト仕様書の作成は重要になってきます。
・単体テスト実施報告書
単体テストで発生した不具合の件数やテスト結果の評価などを記載した資料になります。
テスト結果から品質に問題がないかなどを報告する際に単体テスト実施報告書の内容に沿って報告を行います。
開発チーム内だけでなくシステム利用者（ユーザー）側も内容を確認します。
3. 結合テスト
単体テスト完了後に複数の機能を組み合わせて行うテストであり、業務では「インテグレーションテスト」や「IT」などと呼ばれたりします。
複数のシステムを組み合わせて実施するため、処理が正しく連携され期待通りに動作するか、モジュール間のデータのやり取りが正しく行われているかなどのテストを行います。
3-1. ポイント
・本番環境に近づけたテスト実施
結合テスト工程で本番環境に近づけた環境でテストを行うことで実際の運用を想定したテストを行うことができ、システムだけでなく環境に応じたテストを行うことも可能になります。
・テストシナリオごとにテストデータを準備
何かしらの原因でテストデータが変更、削除された場合に正しいテストが行えず品質の担保が行えなくなります。
そのため、テストを行うテストシナリオごとにテストデータを準備しテストを行うことでテスト品質の担保にも繋がります。
・不具合発生時の管理
結合テスト実施中に発生した不具合の管理が必要になります。
どの機能のテスト中に発生したのか不具合の詳細や再現手順を明確に記載して関係者間で共有します。
これにより「どこで」「何が起きているのか」を把握でき原因調査も行いやすくなります。
複数の開発者で行っている場合、不具合の内容からどこで問題が発生しているのか切り分けを行い、該当の機能を開発している開発者へ問い合わせを行います。
・スケジュールを意識した実施
複数のシステムを組み合わせてテストを実施するため、実施方法やテストデータに誤りがあった場合に想定と異なる動作になる場合があります。
その際に原因調査や修正などが発生し想定以上の時間がかかる可能性もあるため、スケジュールを意識してテストの作成や実施を行う必要があります。
3-2. 成果物
・テストシナリオ一覧
業務の一連の流れ、必要になるデータなどを記載した資料になります。
業務の一連の流れに応じてどのようなテストを行うか、そこで必要になるデータは何かなどを洗い出しヌケモレなく結合テストを進めるために作成します。
・結合テスト仕様書
実施手順やテストデータ、エビデンスなどを記載した資料になります。
テストシナリオ一覧をもとに対象となるシナリオごとにテスト項目を作成する必要があります。
テスト実施者は、結合テスト仕様書の内容をもとにテストを行うため、誰が見ても同様に実施できるように曖昧な表現を避けて具体的に記載する必要があります。
・結合テスト実施報告書
結合テストで発生した不具合の件数やテスト結果の評価などを記載した資料になります。
テスト結果から品質に問題がないかなどを報告する際に結合テスト実施報告書の内容に沿って報告を行います。
開発チーム内だけでなくシステム利用者（ユーザー）側も内容を確認します。
4. 総合テスト
結合テスト完了後に行うテストであり、業務では「システムテスト」や「ST」などと呼ばれたりします。
システム利用者が実際に使用する本番環境やそれに準ずる環境でシステムが全体的に想定した通りに動作するかテストを行います。
機能要件に応じたテストだけでなく、性能テストや負荷テストなど非機能要件に該当する部分のテストも行います。
4-1. ポイント
・機能要件に応じたテスト実施
要件定義の工程でシステム利用者が求めている要件が正しく実装されているか、不具合や実装漏れがないか確認を行います。また、結合テスト実施前にテストシナリオを作成して、シナリオに沿ったテストを行い実際の運用で障害が発生しないかを確認します。
・非機能要件に応じたテスト実施
システム利用者が求めている機能以外の要件が想定通りの動作になっているか確認を行います。性能テストでは、システムの応答速度や処理速度、リソースの消費量などを基準値の値と比較します。
負荷テストでは、システム利用時に高い負荷をかけて、その影響や動作を確認します。
その他にも「ロングランテスト」や「セキュリティテスト」などのテストも行い非機能の部分で問題が生じないか確認します。
・不具合発生時の管理
総合テスト実施中に発生した不具合の管理が必要になります。どの工程でテスト中に発生したのか不具合の詳細や再現手順を明確に記載して関係者間で共有します。
これにより「どこで」「何が起きているのか」を把握でき原因調査も行いやすくなります。
結合テストと同様になりますが、複数の開発者で行っている場合、不具合の内容からどこで問題が発生しているのか切り分けを行い、該当の機能を開発している開発者へ問い合わせを行います。
4-2. 成果物
・テストシナリオ一覧
業務の一連の流れ、必要になるデータなどを記載した資料になります。
業務の一連の流れに応じてどのようなテストを行うか、そこで必要になるデータは何かなどを洗い出しヌケモレなく総合テストを進めるために作成します。
・総合テスト仕様書
実施手順やテストデータ、エビデンスなどを記載した資料になります。
テストシナリオ一覧をもとに対象となるシナリオごとにテスト項目を作成する必要があります。
テスト実施者は、総合テスト仕様書の内容をもとにテストを行うため、誰が見ても同様に実施できるように曖昧な表現を避けて具体的に記載する必要があります。
・総合テスト実施報告書
総合テストで発生した不具合の件数やテスト結果の評価などを記載した資料になります。
テスト結果から品質に問題がないかなどを報告する際に総合テスト実施報告書の内容に沿って報告を行います。
開発チーム内だけでなくシステム利用者（ユーザー）側も内容を確認します。
5. まとめ
ここでは、ウォータフォール型開発におけるテスト工程について記載しました。
各工程ごとに責務や実施方法などは異なってきますが、テストの流れはテスト設計書の作成からテスト実施、テスト実施報告書の作成と同じような流れになっています。
機能要件やシステム要件を把握して各テスト工程でどのようなテストを行うのかを理解したうえで、テスト仕様書に落とし込んでいけば作成から実施が可能になります。
また、単にテストを消化するだけでなく、システムに対する品質を保証する作業になるため、各テスト工程の効果的な進め方を理解してテスト実施に繋げていければと考えています。