システム開発の工程の一つである「テスト」の実施方法を解説します。
テストが行われているのは知ってるけど、実際どんなやり方でやってるの？
この疑問にお答えします！
実際の開発で行っているテストの方法を詳しく教えます！
テストの流れや、実際のテストの再現を紹介するので、ぜひ最後まで読んでみてください。
※会社によってはテストの方法は異なる可能性があります。ご了承ください。
テストを行わない開発は存在しない
システム開発にテストは不可欠です。
設計書でどれほど入念に「使いやすさ」や「セキュリティ対策」を追求しても、実際にそれが実装されていなければ意味がありません。テストは、設計書通りに作成されているかチェックする重要な工程なのです。
ウォーターフォール型やアジャイル型など様々な開発手法がありますが、テストを行わない開発は存在しません。
テストの種類
テストは、テストを実施するシステムの範囲によって3つに分けられます。
- 単体テスト
プログラムを構成する小さな単位の不具合を確認するテスト。通常は関数やメソッドの単位で行われる。 - 結合テスト
単体テストで扱う「小さな単位」を組み合わせて正しく動作するか確認するテスト。サブシステム内の機能連携や他システム間との連携を確認する。 - システムテスト
完成したシステム全体に対して行うテスト。システム全体が仕様書通りにできているか確認する。
テストの流れ
基本的に、1つのテストは以下の流れで行われます。
- テスト仕様書作成
- テスト仕様書のレビュー
- テスト実施
- テスト結果のレビュー
それでは、4つの工程を解説していきます。
テスト仕様書作成
テスト実施の前に、どのようなテストを行うか記述する「テスト仕様書」を作成します。
設計書通りにシステムが作られているかを、テストケースを作成して検証するのです。設計書をもとに様々なパターンを想定して抜けもれなくテストするのです。
私が実際に使用している仕様書のレイアウトはこんな感じです（再現）⇩
青い列の項目（テスト項目、テスト区分、実施手順、予想結果）に記入します。オレンジの欄はテストの結果を記入します。
テスト仕様書のレビュー
作成した仕様書はプロジェクトの他メンバーにレビューしてもらいます。
レビューの観点例
- テストケースに抜けもれはないか
- 実施手順は正しいか
- 設計書通りの予想結果になっているか etc…..
レビューで指摘された内容を修正し、修正内容を再度レビューしてもらいこの工程は終了です。
テスト実施
テスト仕様書のテストケースに基づいてテストを実施します。テストの実施はテスト仕様書の作成者のが行うケース、他メンバーが行うケースどちらもあります。
テストを実施する際に「テスト仕様書の結果欄の記入」と「エビデンスの記入」を行います。
・テスト仕様書の記入
仕様書のオレンジ列に記入します⇩
・エビデンスの記入
その名の通り、テストを実施し得られた結果の証拠を記入します。具体的には、実施画面のスクリーンショット等を貼り付け、説明等を付け加えたりします。
テスト結果のレビュー
テスト結果を記入した仕様書や、エビデンスをもとにレビューを行います。
レビューの観点
- 手順通りにテストが行われているか
- エビデンスは十分か
- 追加のテストは必要ないか etc…
レビューで指摘された内容を修正し、再度レビューしてもらいOKであれば終了です。
テスト例：U－NEXTログイン機能の単体テスト
ログイン画面
テスト例として、動画配信サービスの「U-NEXT」のログイン機能の単体テストを行ってみます。
※当然ながら実物の設計書は無いので、あくまで私の想像で行っていることをご了承ください。
こちらがログイン画面です⇩
なお、今回は2つのレビュー工程はスキップします。
テスト例：テスト仕様書作成
ログイン画面の設計書に以下の記入があったとします⇩
この機能をテストするために、以下のようなテストケースを作成します⇩
テスト例：テスト実施
テストを実施し、結果を記入した仕様書はこちらです⇩
今回はテスト結果に問題はなく、備考欄の記入事項もありませんでした。
エビデンスはこちらです（テストNo2のもの）⇩
このようにレビュアーがテストの結果を認識できるようにわかりやすくエビデンスを作成します。
最後に
この記事では、システム開発のテスト工程を解説しました。
- テスト仕様書作成
- テスト仕様書のレビュー
- テスト実施
- テスト結果のレビュー
テストは成果物のクオリティを決める重要な仕事です。テストに対する理解を深めてすきのないテストが行えるようになりましょう！
コメント