システム開発の必須工程「テスト」の実施方法を解説！

システム開発の工程の一つである「テスト」の実施方法を解説します。

テストの流れや、実際のテストの再現を紹介するので、ぜひ最後まで読んでみてください。

※会社によってはテストの方法は異なる可能性があります。ご了承ください。

テストを行わない開発は存在しない

システム開発にテストは不可欠です。

設計書でどれほど入念に「使いやすさ」や「セキュリティ対策」を追求しても、実際にそれが実装されていなければ意味がありません。テストは、設計書通りに作成されているかチェックする重要な工程なのです。

ウォーターフォール型やアジャイル型など様々な開発手法がありますが、テストを行わない開発は存在しません。

テストの種類

テストは、テストを実施するシステムの範囲によって3つに分けられます。

テストの流れ

基本的に、1つのテストは以下の流れで行われます。

それでは、4つの工程を解説していきます。

テスト仕様書作成

テスト実施の前に、どのようなテストを行うか記述する「テスト仕様書」を作成します。

設計書通りにシステムが作られているかを、テストケースを作成して検証するのです。設計書をもとに様々なパターンを想定して抜けもれなくテストするのです。

私が実際に使用している仕様書のレイアウトはこんな感じです（再現）⇩

青い列の項目（テスト項目、テスト区分、実施手順、予想結果）に記入します。オレンジの欄はテストの結果を記入します。

テスト仕様書のレビュー

作成した仕様書はプロジェクトの他メンバーにレビューしてもらいます。

レビューで指摘された内容を修正し、修正内容を再度レビューしてもらいこの工程は終了です。

テスト実施

テスト仕様書のテストケースに基づいてテストを実施します。テストの実施はテスト仕様書の作成者のが行うケース、他メンバーが行うケースどちらもあります。

テストを実施する際に「テスト仕様書の結果欄の記入」と「エビデンスの記入」を行います。

・テスト仕様書の記入

仕様書のオレンジ列に記入します⇩

・エビデンスの記入

その名の通り、テストを実施し得られた結果の証拠を記入します。具体的には、実施画面のスクリーンショット等を貼り付け、説明等を付け加えたりします。

テスト結果のレビュー

テスト結果を記入した仕様書や、エビデンスをもとにレビューを行います。

レビューで指摘された内容を修正し、再度レビューしてもらいOKであれば終了です。

テスト例：U－NEXTログイン機能の単体テスト

ログイン画面

テスト例として、動画配信サービスの「U-NEXT」のログイン機能の単体テストを行ってみます。

※当然ながら実物の設計書は無いので、あくまで私の想像で行っていることをご了承ください。

こちらがログイン画面です⇩

なお、今回は2つのレビュー工程はスキップします。

テスト例：テスト仕様書作成

ログイン画面の設計書に以下の記入があったとします⇩

この機能をテストするために、以下のようなテストケースを作成します⇩

テスト例：テスト実施

テストを実施し、結果を記入した仕様書はこちらです⇩

今回はテスト結果に問題はなく、備考欄の記入事項もありませんでした。

エビデンスはこちらです（テストNo2のもの）⇩

このようにレビュアーがテストの結果を認識できるようにわかりやすくエビデンスを作成します。

最後に

この記事では、システム開発のテスト工程を解説しました。

テストは成果物のクオリティを決める重要な仕事です。テストに対する理解を深めてすきのないテストが行えるようになりましょう！